CC BY
54
6. Михайлов Г.А., Войтишек А.В. Численное статистическое моделирование. Методы Монте-Карло — М.: Издательский центр «Академия», 2006. — 368 с.
7. Boost compute documentation [Электронный ресурс]: http://www.boost.org/doc/libs/1 62 0 /libs/compute/doc/html/index.html
УДК 004.04
ИСПОЛЬЗОВАНИЕ АРХИТЕКТУРНОГО ПОДХОДА ПРИ РАЗРАБОТКЕ ПРИЛОЖЕНИЙ К БАЗАМ ДАННЫХ
Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, Ивановский государственный химико-технологический университет, Россия, Иваново, portugaled@yandex.ru
Учебный курс «Управление данными» является одним из центральных в подготовке студентов по направлению 09.03.02 «Информационные системы и технологии». В рамках данной дисциплины основное внимание уделяется вопросам проектирования баз данных и работы с данными средствами языка запросов и современных РСУБД [1]. Другим важным моментом является разработка приложения к базам данных, которая, как показывает опыт, и вызывает самую большую сложность. Практическая часть курса по управлению данными предполагает у студента определенные знания и навык в разработке приложений и владении языками программирования высокого уровня. Однако в реальности опыт программирования оказывается небольшим, а уровень владения методами программной инженерии в целом низкий. Вместе с тем программа курса «Управление данными» не предусматривает подробное рассмотрение вопросов разработки приложений к базам данных. Если задачу разработки отдавать на откуп студентам, то это приводит к тому, что качество решения этой задача остается низким. Даже если уровень программисткой подготовки студентов в целом неплохой, мало кому удается разработать приложение в полном объеме. При этом не приходится даже говорить о какой-то более или менее целостной структуре приложения, целостном подходе к его проектированию и реализации. Причинами этого, как уже упоминалось выше, являются слабое владение методами программной инженерии, незначительный опыт проектирования подобных задач, ограниченность времени на реализацию приложения, трудность в понимании того, как следует решать эту задачу. В результате возникла потребность разработать такой подход, который бы соответствовал следующим критериям:
• обладал относительной простотой и понятностью при изучении и использовании;
• опирался на принципы объектно-ориентированного программирования;
• демонстрировал, пусть и в упрощенной форме, особенность «промышленной» разработки кода.
Этим критериям в полной мере отвечает архитектурный подход, который предполагает разработку общих принципов и решений, удовлетворяющих предъявляемым требованиям и обеспечивающих легкую адаптацию к потенциальным требованиям в определенных пределах. Таким образом, цель данной статьи заключается в том, чтобы показать опыт использования архитектурного подхода при разработке приложений к базам данных.
За основу общей конструкции приложения была взята многослойная структура приложения [2]. Многослойная структура предполагает разделение приложения на отдельные функционально обособленные слои с выраженным назначением, связанные между собой четко выделенными интерфейсами. Такая конструкция позволяет разделить приложение на части, обладающие определенной независимостью в ходе их разработки и использования. В конечном счете, каждая такая часть может разрабатываться с применением различных языков программирования и в значительной степень позволяет локализовать
вносимые изменения в приложение, потребность в которых может возникать в ходе его эксплуатации.
Количество слоев, которые может иметь приложение, определяется спецификой и сложностью решаемых задач. В случае студенческого учебного проекта, где главным является демонстрация самого принципа, достаточно разделить приложение на три традиционных слоя:
• слой представления или Presentation Layer - отвечает за взаимодействие с пользователем и работу графического пользовательского интерфейса;
• слой бизнес-логики или Business Logic Layer - отвечает за обработку данных в соответствии с потребностями пользователя;
• слой доступа к данным или Data Access Layer - отвечает за взаимодействие с внешними хранилищами данных, т.е. обеспечивает доступ к данным.
Для обеспечения физической независимости каждый слой может дополнительно разрабатываться как отдельный модуль. Поскольку для выполнения студенческой работы рекомендуется использование MS Visual Studio и языка разработки C#, то каждый слой разрабатывается как отдельный проект типа «библиотека классов». Разработка графического пользовательского интерфейса также ведется в отдельном проекте. Выбор технологии для разработки интерфейса пользователя остается за студентом, но рекомендуется использование технологии WPF, основанной на языке разметки XAML. В последнем случае создается отдельный проект типа «WPF приложение», который также играет роль запускаемого проекта. Это означает, что при компиляции решения проект типа «WPF приложение» компилируется в исполняемый файл типа .exe, а проекты типа «библиотека классов» в динамически подключаемую библиотеку .dll.
На рис.1 представлена рекомендуемая структура приложения и схема зависимости модулей в виде UML диаграммы размещения. Слой представления (Presentation Layer) на схеме явно отсутствует, в данном случае он реализован в рамках запускаемого проекта Application. При этом в качестве отдельного модуля добавлена библиотека Dto. Данная библиотека представляет коллекцию объектов, единственная задача которых состоит в передаче данных между слоями. Такое решение обусловлено широко известным шаблоном проектирования Data Transfer Object (DTO). Объекты DTO по определению не содержат поведения.
Рис. 1 - Общая структура приложения
В центре разработки приложений к базам данных обычно лежит структуру базы данных. В этом случае для каждой таблицы или представления на уровне проекта DataAccess
67
следует создать и поместить в папку Entities соответствующий объект типа Entity, структура которого полностью повторяет структуру таблицы или представления. Согласно принципу разделения ответственности, за получение списка, добавление, редактирование и удаление экземпляров сущности отвечает другой класс, назначение которого отражается в имени класса с помощью аббревиатуры DAO (Data Access Object): EntityDao. На текущий момент существует большое число самых различных СУБД, использование которых в проекте для хранения данных может быть обусловлено целым рядом причин: компактностью, быстродействием, ценой, доступностью и т.п. Чтобы обеспечить независимость от конкретной СУБД и повторное использование имеющегося кода, описанная выше функциональность обобщается в виде абстракции, декларируя операции конкретного класса EntityDao в виде интерфейса IEntityDao. При этом сторонние модули, в данном случае модуль, реализующий бизнес-логику (BusinessLogic Layer), будут знать только об интерфейсе IEntityDao. Также зададим единственное место, в котором все сторонние модули будут получать объект реализации интерфейса IEntityDao. Это место называется фабрикой классов DaoFactory.
Рис. 2 - Рекомендуемый шаблон разработки
Для передачи данных между слоями используется объект EntityDto. В результате возникает задача преобразования объектов типа Entity в объекты типа EntityDto и обратно. Чтобы не делать это каждый раз, где только потребуется, следует добавить специальный класс DtoConverter в проекте BusinessLayer и поместить его в папку Converters этого проекта. Кроме того, такой прием значительно сокращает код и облегчает его понимание.
Аналогично слою доступа к данным на уровне слоя бизнес-логики создадим интерфейс IEntityProcess, декларирующий операции обработки данных объекта типа EntityDto. Чтобы быстро заменить реализацию интерфейса IEntityProcess с нынешнего варианта на какой-либо иной, позволим сторонним модулям знать только об интерфейсе IEntityProcess и зададим фабрику классов ProcessFactory, посредством которой все сторонние модули будут получать
объект реализации интерфейса IEntityProcess. Таким образом, создание экземпляров класса, реализующих интерфейс IEntityProcess, будет в одном месте. Мы всегда с легкостью поменяем класс реализации данного интерфейса на любой иной, и сторонние модули даже не узнают об этом.
Опишем порядок разработки приложения на примере базы данных, рассмотренной в руководстве [1]. На рис. 3 представлена физическая модель данных, описывающая
предметную область небольшой художественной галереи View Ridge.
Рис. 3 - Схема базы данных View Ridge Gallery
Работники галереи желают вести учет покупателей и их художественных интересов; отслеживать приобретения галереи и покупки клиентов; вести список художников и произведений, когда-либо появлявшихся в галерее; получать отчеты деятельности галереи; отображать на веб-странице список произведений, выставленных на продажу.
Согласно описанному выше подходу реализация поставленных задач будет заключаться в последовательном использовании предложенного шаблона проектирования (рис. 2) для каждой таблицы представленной схемы базы данных. Рекомендуется начать реализацию с таблиц CUSTOMER и ARTIST, продолжить таблицами WORK и TRANS (transaction) и завершить таблицей связью CUSTOMER_ARTIST_INT, которая на практике будет заменена представлением CUSTOMER_INTERESTS.
Порядок использования шаблона разработки, схема которого была представлена выше, рассмотрим на примере реализации работы с таблицей WORK. Данная таблица отражает сущность предметной области, отвечающую за моделирование художественного произведения - основного объекта деятельности галереи View Ridge.
Схема реализации для таблицы WORK, представленной на рис. 4, будет следующей.
В проекте DataAccess:
1. в папке Entities необходимо добавить класс Work, структура которого полностью соответствует структуре таблицы WORK, а сам класс соответствует классу Entity рекомендуемого шаблона разработки (рис. 2);
добавить интерфейс для доступа к данным IWorkDao, в котором декларировать основные методы обработки объекта типа Work, в том числе и методы осуществления поиска в коллекции объектов типа Work;
4.
добавить реализацию интерфейса IWorkDao в виде класса WorkDao, который включает реализацию методов получения и обработки данных, ориентированных на конкретную СУБД (в учебном проекте использовался MS SQL Server 2008). При этом методы подключения к базе данных вынесены в отдельный класс BaseDao, общий для всей коллекции классов этого уровня. Процедура создания объектов типа Work вынесена в отдельный статический метод LoadWork(), что позволяет использовать его в других методах класса и повысить понятность разрабатываемого кода; завершает работу на этом уровне добавление в класс DaoFactory метода, отвечающего за создание объектов типа WorkDao. Напомним, что класс DaoFactory является единственной точкой доступа к модулю Data Access и связывает между собой модули Business Logic и Data Access.
Рис. 4 - Схема реализации шаблона для таблицы WORK
Далее, следует перейти в проект Dto и создать класс WorkDto. В отличие от объектов типа Entity объекты типа Dto описывают свойства (property), а не поля (field). Это позволяет в объектах Dto при объявлении свойств ссылаться на другие объекты в целом. Таким образом, каждому произведению будет привязан не просто идентификатор художника, как это отражено в сущности Work, а все сведения о художнике (объект ArtistDto): с его именем, фамилией и прочими атрибутами, что существенно облегчает получение нужных данных в ходе реализации приложения. Закончив с созданием объектов типа Dto, перейдите на уровне бизнес-логики, т.е. в проект BusinessLayer, и реализуйте логику работы с объектами класса WorkDto:
1. сначала перейдите в папку Converters и добавьте соответствующие методы к классу DtoConverter, преобразующие объекты типа Work в объекты типа WorkDto и наоборот;
2. далее создайте интерфейс IWorkProcess и реализуйте его в классе WorkProcessDb, согласно предложенной на рисунке 4 схеме. Конструктор класса WorkProcessDb отвечает за подключение к модулю Data Access через интерфейс IWorkDao и получение объектов типа Work, которые затем преобразуются при вызове
соответствующих методов класса DtoConverter в объекты типа WorkDto, которые затем используются в качестве источников данных для предоставления данных в графическом пользовательском интерфейсе;
3. для обеспечения связи модуля бизнес-логики и модуля, отвечающего за взаимодействие с пользователем, в класс ProcessFactory следует добавить метод, который будет отвечать за создания объектов класса WorkProcessDb и управления всей цепочки взаимодействия пользователя и базы данных.
На уровне представления основной задачей будет создание графического интерфейса пользователя и логики взаимодействия пользователя с приложением. Создание графического интерфейса в самых общих чертах сводится к разработке табличной формы, которая отображает записи, содержащиеся в таблице WORK, форм для добавление новых записей и изменения существующих, средств для удаления записей, поиска или отбора записей по заданным критериям, выгрузки данных для использования их в сторонних приложениях.
Более подробно с примером реализации учебного проекта на базе рассматриваемого шаблона разработки можно ознакомится в работе [3].
Предложенный в статье подход к разработке приложений к базам данных был апробирован в течение двух последних лет в ходе выполнения практических занятий и курсовых проектов по дисциплине «Управления данными» студентами кафедры Информационных технологий Ивановского государственного химико-технологического университета. Использование данного подхода показало, что студенты стали лучше понимать принципы разработки подобных приложений, стали выполнять больший объем работ и делать эту работу более качественно. Многие студенты используют данных подход в ходе разработки своих курсовых проектов, развивая и расширяя его возможности. Кроме того, практика знакомства студентов с предлагаемым подходом проектирования, позволяет им в дальнейшем лучше понимать и смелее использовать альтернативные подходы быстрой разработки приложений, например, такие, как Entity Framework.
Литература
1. Галиаскаров, Э.Г. Проектирование баз данных: лабораторный практикум / Э.Г. Галиаскаров, А.Ю. Крылов; Иван. гос. хим.-технол. ун-т.- Иваново, 2012. - 96 с.
2. Руководство Microsoft по проектированию архитектуры приложений. 2-е издание.
3. Разработка приложений баз данных: лабораторный практикум / Э.Г. Галиаскаров и др.; Иван. гос. хим.-технол. ун-т. - Иваново, 2015. - 112 с.
УДК 004.04
АВТОМАТИЗАЦИЯ СБОРА ИНФОРМАЦИИ ИЗ ОТКРЫТЫХ ИНТЕРНЕТ-
ИСТОЧНИКОВ
Гранаткин Денис Сергеевич, студент, Ивановский государственный химико-технологический университет, Россия, Иваново, dengranatkin94@mail.ru
Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, Ивановский государственный химико-технологический университет, Россия, Иваново, portugaled@yandex.ru
Введение
Интернет может рассматриваться как незаменимый источник информации. Полученные из Сети данные применяются в сфере образования, бизнеса, развлечений, отдыха, медицины и т. д. В настоящее время, в связи с постоянным ростом информации в глобальной сети Интернет, во многих практических задачах возникает потребность сбора этой информации. Цели сбора данных у каждой практической задачи свои. Например, для большей
