Инструментальное средство интегрированной среды разработки для проектирования корпоративных информационных систем Текст научной статьи по специальности «Компьютерные и информационные науки»

ИНСТРУМЕНТАЛЬНОЕ СРЕДСТВО ИНТЕГРИРОВАННОЙ СРЕДЫ РАЗРАБОТКИ ДЛЯ ПРОЕКТИРОВАНИЯ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Э. С. Воронов

Институт кибернетики Национального исследовательского Томского политехнического университета, 634034, Томск, Россия

УДК 004.4.22:004.4.242

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

Ключевые слова: объектно-реляционное отображение, шаблон "единица работы", шаблон "хранилище", инструментальные средства, информационные системы.

Key words: object-relational mapping, unit of work pattern, repository pattern, work bench, information system.

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

Неотъемлемой частью корпоративных информационных систем является база данных (БД). Традиционный способ работы с БД - использование в приложении поставщиков данных для извлечения и модификации информации [1]. На рис. 1 представлена модель приложения, реализующего традиционный доступ к БД. Модель приложения состоит из слоев View (представление), Model (модель) и Data Model (модель данных). Слой модели данных содержит методы обращения к БД, состоящие из SQL-запросов, и предоставляет результирующие наборы данных (Data Set). Слой модели определяет бизнес-логику приложения. Слой представления является отображением данных пользователю. Для каждой отдельной подзадачи выделяется отдельная цепочка модель данных - модель - представление. На рис. 1 видно, что традиционный подход имеет несколько недостатков: 1) создание всех SQL-запросов к БД вручную и как следствие

Работа выполнялась по тематике госбюджетной НИР в рамках государственного задания "Наука".

Рис. 1. Модель приложения, реализующего традиционный доступ к БД

ORM Entities

Рис. 2. Модель приложения , реализующего традиционный доступ к БД на основе ORM

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

Альтернативным подходом по отношению к традиционному является использование технологии object-relational mapping (ORM) - объектно-реляционного отображения - технологии связывания базы данных с концепциями объектно-ориентированного программирования. С точки зрения программного обеспечения ORM - механизм преобразования объектов и методов приложения в данные и запросы к БД [2]. В то же время с точки зрения разработчика ORM - инструмент для отображения модели БД в объектно-ориентированную модель языка программирования. Использование ORM избавляет от необходимости написания вручную запросов к БД на извлечение и модификацию данных, что существенно сокращает временные затраты разработки программного обеспечения, а также уменьшает вероятность ошибки. На рис. 2 приведена модель приложения, реализующая доступ к БД на основе ORM.

Слой ORM содержит определение сущностей отображения модели БД и определения data context - аккумулирующей сущности, через которую происходит обращение к БД. Следует отметить, что современные ORM выполняют генерацию этих сущностей автоматически, позволяя разработчикам настраивать их поведение непосредственно в интегрированной среде разработки.

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

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

Model

Entities^W' Model 1 I N View 1 ORM Repository^

Model Entities ••••••••

SQL ORM Entities Model Entiti^V^ Model N View N

Model Entities

Рис. 3. Модель приложения, реализующего технологию репозитория

Для повышения масштабируемости и редукции связности слоев поставлена задача разработки типовой архитектуры корпоративных информационных систем, которая удовлетворяет следующим требованиям:

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

- модульная независимость слоев модели и представления от ORM-сущностей;

- наличие инструментальных средств, автоматизирующих применение технологии.

Разработанная типовая архитектура основана на применении шаблона проектирования

"единица работы" (unit of work) [3], в рамках которого модель приложения обращается к данным или модифицирует их в рамках отдельных транзакций. Для достижения модульной независимости разработана технология репозитория (Repository), позволяющая проводить преобразование между сущностями ORM в сущности модели (Model Entities). Модель приложения с предложенной технологией репозитория представлена на рис. 3.

Слой репозитория реализует преобразование между сущностями ORM и сущностями модели. Таким образом, слой репозитория полностью обеспечивает независимость слоев модели и представления от конкретного ORM и от типа и структуры БД. В то же время сущности модели обладают набором функциональности, обеспечивающим их удобное использование при создании бизнес-логики приложения:

- наличие ссылочных значений на родительские сущности, соответствующих связям по внешним ключам модели БД;

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

Апробация технологии репозитория проводилась на платформе .Net Framework с применением интегрированной среды разработки Microsoft Visual Studio 2010 и ORM Microsoft Linq To Sql. На рис. 4 представлена диаграмма классов разработанной технологии.

Класс Entity является базовым классом для всех сущностей репозитория и реализует интерфейсы IDataErrorInfo и INotifyPropertyChanged для поддержки валидации данных и оповещения об изменениях. Класс EntityWithPK, наследующий класс Entity, обеспечивает функциональность для сущностей с суррогатным первичным ключом. Класс RepositoryDMBase, реализующий интерфейс IRepositoryDM, является точкой доступа к данным и обеспечивает подключение к источнику данных (ORM). Абстрактный класс RepositoryBase, реализующий интерфейс IRepository, обеспечивает функциональность преобразования между сущностями ORM и сущностями репозитория.

[RepoutgryDMBiise

interface

; IГ:' ГVi*

3 public ♦ Connect

©

IU pdateAf terSubrrril SI

Interface

S public < Umto taw ТГ

IRepoir

IRepositoryDMasie

RepoiitotyDMBae

apubsc

^ Connect^ 1 overload)

* Dispose

^ SubrritCNangei ■ protected

* AIIRepos ¡tones i* OataContext

V RepositwyDMBjse

1 Repository <Т> Generic Interface -MUpdateAfterSubmit s1

ь public

V Delete

GetAU

♦ Save

#ер«|Гогув№<Г, TDBT- ST,

Generic AbstrKt Cisö T

a public

♦ Delete

4 G«A!I

♦ Save

V UpdsttAII

0 protected

yV GetConvtfte

GetPrimoryKtyCortfition

Repositorytase UHOSttOiintiy

;.V upäattfntry

ilfctaErvorlnfo [Ncti^PropertyChsnged

--------------------------------- Entity © Abstract Class 7

a public Error Func EntityWithPK< T> © Generic Abstract Class -fr Entity T

IsNew ^ Order / PropertyChanged this 0 protected Entity NativeDataErorfnfo RaisePropertyChanged •-----------------------------------------------_/ a public

V Equals ♦ GetHsshCode S ID ü) IDPropertyN»me

Рис. 4. Диаграмма классов

Рис. 5. Схема инструментального средства, интегрированного в среду разработки

Для автоматизации процесса применения технологии разработано инструментальное средство на языке программирования C#, интегрируемое в среду разработки. Схема инструментального средства представлена на рис. 5.

Инструментальное средство состоит из интегрированного в среду разработки редактора (Editor), позволяющего изменять настройки отображения сущностей ORM в сущности модели. Для упрощения создания настроек использована объектная модель автоматизации Visual Studio (DTE) [4], позволяющая получить доступ к элементам среды разработки (проекты, файлы, типы) как к объектам. Настройка отображения сохраняется в файл в регулярном формате (XML).

На основе созданного файла настроек генерируется код слоя репозитория с сущностями модели. Генерацию автоматически осуществляет зарегистрированная в системе COM-сборка генератора (Code Generator). В основе генератора лежит объектная модель Code DOM [5], которая позволяет описывать модель исходного кода предоставляемыми ею типами (класс, пространство имен, свойство, метод и т. д.). Полученную модель можно преобразовывать как в исходный код, так и в скомпилированную библиотеку.

Описанные технология и инструментальное средство использованы при разработке корпоративной информационной системы "АИС склада метанола", автоматизирующей процесс отгрузки товарного метанола ООО "Сибметахим".

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

Список литературы

1. ФАУЛЕР М. Шаблоны корпоративных приложений / Пер. с англ. М.: Издат. дом "Вильямс", 2011.

2. Mapping objects to relational databases: O/R mapping in detail. 2012. [Electron. resource]. http://www.agiledata.org/essays/mappingObjects.html.

3. ФРИМЕН Э. Паттерны проектирования / Э. Фримен, К. Сьерра, Б. Бейтс. СПб.: Питер, 2012.

4. Модели объектов автоматизации. MSDN. 2012. [Electron. resource]. http://msdn.microsoft.com/ru-ru/library/za2b25t3.aspx.

5. Использование CodeDOM. MSDN. 2012. [Electron. resource]. http://msdn.microsoft.com/ru-ru/library/y2k85ax6.aspx.

Воронов Эдуард Сергеевич - асп. Института кибернетики Томского политехнического университета; тел.: (382-2) 70-17-77; e-mail: [email protected]

Дата поступления - 15.09.12 г.