CC BY
49
• Сочетание методов разработки веб-приложений с методами проектирования и генерации пользовательских интерфейсов (например, 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
систем поддержки принятия решений, реализующих также обширную учетную функциональность. Приведем краткое описание этих систем.
1. Информационная система Регионального банка цифровой геологической информации (РБЦГИ) обеспечивает накопление и сохранность геолого-геофизической информации, получаемой при проведении геологоразведочных работ на нефть и газ, разработке месторождений углеводородов в Тимано-Печорской нефтегазоносной провинции и сопредельных регионах, являясь единым банком данных предприятия, в котором хранятся данные о геологическом строении недр, содержащихся в них ресурсах углеводородов, изученности и состоянии использования этих ресурсов. К настоящему времени в состав РБЦГИ входит более десятка основных пользовательских подсистем, каждая из которых помимо реализации учетной функциональности имеет в своем составе инструменты работы с информационными моделями, предоставляя специфические отчеты, решая задачи визуализации геологогеофизических данных, а также осуществляя преобразования данных для обработки их с помощью специализированных внешних информационных систем, в частности, геоинформационных систем.
2. Три подсистемы, разрабатываемые в рамках соглашения между ОАО «Северные МН» и УГТУ: подсистема расчета объема и времени освобождения от нефти магистрального нефтепровода (ПМ РПОН), подсистема выбора допустимых режимов работы магистрального нефтепровода (МН) (ПМ ПДР) и подсистема формирования расчетных режимов работы МН (модуль ФРР МН) входят в состав программного комплекса для формирования оптимальных режимов нефтепроводов для перекачки нефтей со сложными реологическими свойствами (ПК РОПР МН). Каждая из подсистем в соответствии с постановкой задачи реализует частный аспект математической модели работы МН, осуществляя ряд расчетов и представляя их результаты в виде ряда формальных информационных моделей: таблиц, схем.
Именно предоставление возможности для работы с широким спектром информационных моделей-таблиц, схем, карт - дает возможность классифицировать обе системы как СППР - интерактивные автоматизированные системы, которые помогают лицу, принимающему решения, использовать данные и модели для идентификации и решения задач, и принятия решений. Уточняя классификацию этих систем, можно сказать, что это оперативные СППР, управляемые данными.
Необходимость сочетать в системах учетную функциональность и функции СППР позволила выявить несколько интересных проблем в области объектно-ориентированного структурирования и, в частности, объектно-реляционного отображения, решение которых позволило разработать расширяемый объектно-ориентированный каркас. Основным вопросом, который решался при проектировании и разработке, стал вопрос распределения обязанностей между частями системы - необходимо было наделить учетную систему развитыми возможностями обработки данных с целью получения информационных моделей разной степени сложности. Следует сразу сказать об ограничениях информационной среды, накладываемых на проекты в приводимых примерах: обе системы имеют клиент-серверную архитектуру с «толстым» клиентом, в качестве средства реализации обеих систем используется Delphi. Соответственно, все сказанное ниже об объектно-ориентированном структурировании систем говорится о решениях по объектно-ориентированному структурированию для клиентских частей систем.
Поскольку уже в изначальной постановке задачи системы должны были реализовывать довольно сложную бизнес-логику (и эта сложность в дальнейшем возросла), то в качестве способа организации бизнес-логики (способа структурирования системы) был выбран способ «Модель предметной области»[1] с дополнительным сервисным слоем. В структуре разрабатываемой системы выделяются следующие основные слои: слой обмена данными, слой бизнес-логики, сервисный слой, слой пользовательского интерфейса. Слой обмена данными осуществляет материализацию объектов базы данных в объекты слоя бизнес-
121
логики, а также дематериализацию соответствующих объектов. Слой классов предметной области осуществляет операции бизнес-логики, соответствующие части функциональности СППР. В сервисный слой включаются транзакционные объекты, объединяющие операции бизнес-логики в бизнес-транзакции. Связь между слоями осуществляют контроллеры слоев.
Поскольку в настоящей работе рассматриваются вопросы объектно-реляционного отображения, то остановимся на рассмотрении двух граничащих слоев: слоя обмена данными и слоя бизнес-логики. В каждом из них имеется один или несколько базовых объектов, ответственных за реализацию основных функций слоя. Для слоя обмена данными это абстрактный класс-материализатор TDataPoster, для слоя бизнес логики это базовый объект TIDObject и коллекция базовых объектов TIDObjects.
Базовый материализатор TDataPoster (рис. 1) выполнен по шаблону «стратегия» [2] с двухуровневой иерархией: первый уровень разграничивает стратегии по используемому промежуточному программному обеспечению (TADODataPoster - использует НПО ADO, TFIBDataPoster использует ППО FIB+), второй уровень относительно вида данных, конкретного материализуемого объекта бизнес-логики. В стратегию передачи данных, реализуемую материализатором, включены методы получения данных GetFromDB, записи данных PostToDB и удаления данных DeleteFromDB, конкретные материализаторы, соответствующие классам объектов бизнес-логики, переопределяют эти методы для связи с собственным источником данных.
Рис. 1 Стратегия материализации/дематериализации
Поскольку часть коллекций может содержать несколько сотен тысяч элементов, материализация выполняется по шаблону virtual proxy[3] - элемент коллекции загружается только в момент непосредственного обращения к нему.
Один и тот же экземпляр материализатора может загружать в систему и выгружать в источник данных несколько экземпляров коллекций, состоящих из различных элементов, поэтому коллекция снабжена состоянием (TDataPosterState), в котором восстанавливается материализатор перед его использованием в соответствии с паттерном «Хранитель»[2]. По этому паттерну поведения объекта взаимодействуют классы TIDObjects - базовая коллекция объектов системы - и TDataPoster. Его основное назначение в том, чтобы, не нарушая инкапсуляции, фиксировать и выносить за пределы объекта его внутреннее состояние так, чтобы позднее можно было восстановить объект в этом состоянии. Поскольку каждый
122
экземпляр класса-материализатора разделяется между несколькими коллекциями одного класса, то перед тем, как осуществить дематериализацию определенной коллекции, следует восстановить материализатор в состоянии, соответствующем этой коллекции. В качестве атрибутов состояния выделены: строка фильтра и строка сортировки, изменение которых определяет изменение содержимого коллекции. Диаграмма последовательности для паттерна «Хранитель» относительно описанного системного поведения выглядит следующим образом: (рис. 2):
Поскольку все данные, необходимые для работы обеих описываемых систем как СППР, должны учитываться в базе данных системы и персистентное поведение значимо для всех соответствующих бизнес-объектам классов, было принято решение возложить функциональность по обмену данными с БД на абстрактный класс TIDObject (см. рис. 2).
Слой бизнес-логики представлен множеством объектов, соответствующих концепциям предметной области системы. Базовые классы слоя объект бизнес-логики TIDObject и коллекция объектов TIDObjects реализованы в соответствии с шаблоном «Эксперт» [3]. Класс TIDObject в соответствии с данным шаблоном умеет быть уникально идентифицированным, «умеет» себя описывать в строку (метод List), «умеет» себя копировать (метод AssignTo), «знает», как записать себя в БД, посредством предоставленного ему материализатора. Класс TIDObjects (коллекция) реализован в соответствии со стратегиями «Эксперт» и «Итератор» [3]. Как эксперт он «знает» о своих элементах, «умеет» записать себя в БД, добавлять (метод Add), удалять (Delete), обновлять элементы синхронно с изменениями в БД (Update), как итератор «умеет» перемещаться по списку элементов. Процесс расширения слоя заключается в определении новых классов-объектов бизнес-логики (подклассов TIDObject) и классов-коллекций (наследников обобщенной коллекции TIDObjects).
Рис. 2 Диаграмма последовательности для паттерна Хранитель
В ходе анализа на последующих итерациях постепенно расширялась номенклатура второстепенных бизнес-объектов. Соответствующие классы добавлялись в модель порождением подклассов от предков-категорий (фрагмент иерархии наследования для бизнес-объектов рис. 3).
Конкретные классы предметной области наследуют от базовых классов: переопределяют виртуальные методы базового класса по шаблону «Шаблонный метод»[2] (Template Method) и добавляют свои собственные свойства и методы по шаблону «Эксперт»[3].
Нельзя не упомянуть о некоторых недостатках описываемого способа объектнореляционного отображения. Для уникально идентифицируемых объектов TIDObject ключ
123
соответствует типу ключа базы данных - целому числу. При проектировании баз данных обеих систем для идентификации объектов использовались простые суррогатные ключи, использование составного ключа потребовало бы ввести объект-ключ и изменить интерфейс объекта TIDObject, введя объект ключ в его состав. Методы получения данных, вызываемые из слоя бизнес-логики, рассчитаны на входной параметр в виде SQL-фильтра, в силу чего часть данных запроса локализована в слое бизнес-логики, в то время как остальные данные соотнесены конкретным классам, реализующим TDataPoster.
Рис. 3 Иерархия наследования для бизнес-объектов
Однако, несмотря на эти недостатки, разделение системы на слои и возможность развития каждого слоя порождением подклассов позволила соотнести функции систем по предоставлению ЛПР необходимых моделей к разным слоям системы. Так функция экспорта табличных данных в формат ГИС-системы может быть реализована в пределах слоя обмена данными, над одним из материализаторов-потомков. В то же время функции по выполнению разного рода расчетов, предоставлению данных для вышележащих слоев пользовательского интерфейса (в том числе интерфейсов визуализации данных) удобно приписывать слою бизнес-логики. Таким образом, проектирование системы в соответствии со способом организации бизнес-логики «модель предметной области» и использование описанных проектных решений по объектно-реляционному отображениию позволили не только разработать информационные системы в соответствии с техническим заданием, но создать качественную основу для дальнейшего их развития.
Литература
124
1. Фаулер М. Архитектура корпоративных программных приложений. - М.: Издательский дом «Вильямс», 2004. - C. 51-483.
2. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб: Питер, 2003. - C.183-300.
3. Ларман К. Применение UML и шаблонов проектирования. 2-е издание. - М.: Издательский дом «Вильямс», 2002. C. 100-624.
125
