CC BY
34
УДК 04.004
ОПЫТ ВЫПОЛНЕНИЯ РЕИНЖИНИРИНГА ОБЪЕКТНОЙ МОДЕЛИ НА ПРИМЕРЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ КАТАЛОГИЗИРОВАНИЯ НАУЧНЫХ СТАТЕЙ ПРИ ПРОВЕДЕНИИ МЕЖДУНАРОДНЫХ КОНФЕРЕНЦИЙ
Бородина Наталья Евгеньевна, студентка, Ивановский государственный химико-технологический университет, Россия, Иваново, [email protected] Олейник Павел Петрович, Россия, Ростов-на-Дону, [email protected] Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, доцент, Ивановский государственный химикотехнологический университет, Россия, Иваново, [email protected]
Введение
Одним из основных путей обмена научными знаниями, способом демонстрации своих научных достижений является их публикация в научных журналах и представление на научных конференциях. Наиболее доступным, динамичным и эффективным является именно участие в публичных научных конференциях. На сегодняшний день существует огромное количество научных конференций. Перед организаторами таких конференций возникает серьезная проблема эффективного управления подаваемыми на конференцию научными публикациями и большим объемом дополнительных вспомогательных данных организационного характера: данных о рецензии, оплате, отправленных сборниках и т.п. Решение этих задач требует разработки и использования автоматизированных информационных систем.
Идея создания подобных программных продуктов не нова. В каждом ВУЗе она решается по-своему, от применения простых Excel-файлов до использования сложных многоуровневых Web-приложений. Наиболее проработанной реализацией является система управления научной информацией "ИСТИНА — Наука МГУ", подробно описанная в работе [1]. Но, несмотря на наличие ряда достоинств, система, описанная в [1], не может быть использована при проведении собственных конференций, т.к. не предоставляет возможности сохранения вспомогательной информации, необходимой в этом случае. Поэтому ранее была разработана и активно использовалась собственная система, подробно описанная в работах [2-4]. Однако в ходе эксплуатации и расширения имеющегося функционала были найдены значительные архитектурные ошибки, появление которых во многом связаны с функциональными возможностями выбранного языка программирования (среды разработки) и отсутствием достаточного времени для полноценного проектирования. В результате выявленных архитектурных недостатков возникла настоятельная необходимость в серьезной переделке существующей информационной системы каталогизирования научных работ конференции «Объектные системы» (obiectsvstems.ru).
1. Критерии оптимальности разрабатываемой системы
Прежде чем приступить к разработке информационной системы, необходимо определить и четко сформулировать критерии оптимальности, отражающие требования, предъявляемые к функционалу реализуемого приложения. Для данной системы были выдвинуты следующие критерии оптимальности, описывающие необходимость наличия определенного функционала:
1. Реализовать в системе возможность сохранения информации о различных типах изданий, с учетом того, что издание может быть собственное (проводимое самостоятельно) или внешнее (которое проводится сторонней организацией).
2. Обеспечить возможность сохранения информации об авторах статей с указанием ученых степеней, занимаемых должностей в различных организациях.
17
3. Реализовать возможность сохранения информации об организациях, в том числе их типе и отделах, в которых работают авторы.
4. Предоставить возможность сохранения информации о рецензиях на статьи и их результатах.
5. Реализовать возможность сохранения информации о выпусках различных типов изданий, а также предоставления информации о них пользователю.
6. Реализовать механизм сохранения информации о написанных определенными авторами статьях.
7. Предусмотреть возможность сохранения информации о комитетах и авторах, являющихся их участниками.
8. Реализовать возможность сохранения информации о номинациях авторов статей.
9. Предоставить возможность отслеживания рекомендаций статей в другие издания, в частности в журналы, рекомендованные ВАК для опубликования результатов исследований кандидатских и докторских диссертаций.
10. Реализовать в системе модуль аналитики, выводящий информацию о статьях, находящихся в определенных состояниях, отправленных письмах со сборниками и сертификатами, а также выпусках для участников комитетов.
2. Реинжиниринг существующей системы
Имеющаяся система была спроектирована, когда предъявляемые к ней требования не были полностью ясны. В ходе эксплуатации системы обнаружились ошибки проектирования и возникла потребность в новых функциях системы. Проблемы проектирования также связаны с возможностями выбранного языка программирования C#, в котором отсутствует множественное наследование реализаций, вследствие чего код программы получился довольно громоздким. Также не использовалось множественное наследование деклараций интерфейсов.
На основе исходного кода с помощью CASE-инструмента проектирования ПО Enterprise Architect методом обратного инжиниринга была получена модель существующей системы. На основе анализа полученной модели был выявлен ряд недостатков, а именно:
1. В системе возможно сохранение информации только двух типов изданий: конференция и журнал, подразделяющихся, в свою очередь, на собственные (проводимые самостоятельно) и внешние (проводимые сторонней организацией). При этом иерархия классов организована весьма нерационально. По существу, мы имееи два вида издания, но в системе они представлены четырьмя классами: собственное и чужое издание, статья конференции и журнала.
2. Наличие множества реализаций одних и тех же интерфейсов, которые приходилось использовать для эмуляции множественного наследования.
3. Дублирование одинаковых атрибутов в разных базовых классах, объясняемое отсутствием множественного наследования классов.
С учетом наличия вышесказанных недостатков, было принято решение о реализации новой версии программы, ядром которой является архитектура MDA (Model Driven Architecture). Эта архитектура позволяет создать приложение, управляемое моделью. Одним из стандартов, используемым в MDA, является графический унифицированный язык моделирования UML, который принципиально позиционировался как независящий от платформ и технологий. Именно поэтому он используется для проектирования различных аспектов информационных систем. Мы будем использовать только диаграммы классов, т.к. они позволяют отразить структуру приложения.
Полученная модель иерархии классов разбита на 2 части и представлена на рисунках 1 и 2. На рис. 1 представлена диаграмма классов иерархии предоставляемых конференцией услуг. На рис. 2 представлена основная диаграмма классов.
18
Рис. 1 - UML диаграмма классов иерархии предоставляемых услуг конференции
При рассмотрении рисунков 1 и 2 видно, что в модели присутствуют классы с постфиксом Object. Классы Object - это абстрактные базовые, несохраняемые классы, которые использованы для представления атрибутов. Для обозначения абстрактного класса в языке UML наиболее распространено написание его имени курсивом. Так как построение диаграммы было выполнено в Microsoft Visual Studio 2012, а абстрактные классы реализованы в виде интерфейсов, то они отображаются регулярным шрифтом (без наклонов). Данную реализацию можно объяснить тем, что используется множественное наследование, а в C# это можно эмулировать только интерфейсами.
Всего в модели используется 14 абстрактных классов. Каждый такой класс хранит в себе информацию о каком-то определенном атрибуте. При этом возможно наследование одного класса Object от другого.
Так как свойства и признаки атрибута определяются в абстрактном классе, его использование позволяет сократить время и облегчить процесс реализации основных классов. Также нельзя не отметить тот факт, что при данной реализации отсутствует дублирование кода. Отсюда следует, что при необходимости внести какие-либо изменения или обнаружении ошибки, исправление будет происходить в одном конкретно определенном месте программы (базовом классе).
В соответствии с КО1, а также выявленным недостатком существующей системы, в данной модели был выделен класс EditionKind, определяющий тип издания. Его использование позволяет хранить в системе различные виды изданий (журналы, конференции, монографии и т.п.), не создавая при этом новых таблиц в БД. Вся информация об издании при этом хранится в одном классе BaseEdition. Так как издания могут быть внутренними и внешними, существуют два производных от базового класса ForeignEdition и OwnEdition соответственно.
С вышеуказанными классами имеется связь у ForeignIssue и OwnIssue. Данные классы представляют собой сущности, хранящие информацию о выпусках изданий (номера журнала, сборники конференции), соответственно представлены внешний и собственный выпуски. Данная реализация обеспечивает выполнение КО5.
Как известно, в выпусках печатаются статьи, информация о которых также важна для пользователей системы, это КО6. Для этого в модели реализованы такие классы, как ForeignArticle и OwnArticle. Статьи на конференцию присылают авторы, поэтому в
соответствии с КО2 следует хранить о них определённую информацию. Для выполнения данной возможности реализован класс Scientist - ученый.
19
Рис. 2 - Основная UML диаграмма классов
Для удобства хранения и использования в системе организованы классы должности -Degree и ученые степени - ScienceRank.
Для полноты информации об авторе нам также необходимо знать его место работы. Именно с этой целью реализован класс WorkingPlace - рабочее место. Данный класс получен в результате организации n-арной ассоциации. С его помощью мы легко сопоставляем и находим связи между автором (Scientist), организацией (Organization), отделом (Department) и должностью (Post). При этом нельзя не отметить то, что для удобства работы с организациями выделен специальный класс OrganizationKind, хранящий информацию о типе организации.
Данный класс также реализован в системе для удобства работы с ней, ведь организационно-правовая форма не уникальна, и каждый раз вводить одно и то же значение утомительно. Вся данная схема удовлетворяет КО3.
Рецензии на статьи выполняют авторы, входящие в определенные типы комитетов, это требования, содержащиеся в КО4 и КО7. Для того чтобы пользователь мог легко узнать информацию о рецензии и ее авторе, в системе реализован класс Member - участник комитета и Review - рецензия. Данные классы связаны между собой, и таким образом организована связь рецензии и рецензента. Также для удобства использования организованы классы-перечисления, в которых предоставлены возможные варианты результата рецензии (ReviewResult), типа комитета (CommitteeType) и должности в комитете (CommitteePost).
За опубликованные статьи авторы могут быть признаны победителями в определенных номинациях, что соответствует требованию КО8. Для хранения данной информации в системе предусмотрен класс Nomination.
В соответствии с КО9, который гласит, что система должна предоставлять возможность отслеживания рекомендаций статей в другие издания, реализован класс RecommendationInSupportEdition. Указанный класс содержит в себе информацию о результате рекомендации, ее текст, а так же дату сохранения результата.
Для пользователей системы очень важно знать сводную аналитическую информацию, касающуюся статей, находящихся в определенных состояниях (на рецензии, отклонена, рекомендована к печати), а так же отправленных письмах и выпусках, предназначенных участникам комитетов. Для удовлетворения КОю в системе организован специальный модуль «Аналитика», который предоставляет пользователю всю вышеуказанную информацию.
Рассмотрев схему организации системы и прочитав ее описание, можно сделать вывод о том, что все критерии оптимальности, предъявленные к системе, соблюдены.
После разработки новой модели было выполнено ее сравнение с моделью существующей системы. Необходимо было проверить, все ли классы отражаются в новой модели. Проверка показала, что реинжиниринг выполнен корректно и в полном объёме.
Так как данные, которые используются системой, хранятся в реляционной базе данных, следующим этапом стала проверка новой БД на наличие эквивалентных таблиц, соответствующих таблицам старой БД, и присутствие в них всех необходимых столбцов.
3. Импорт данных из существующей системы в новую
Разработка новой системы не означает, что работа в ней начнется с чистого листа, и данные существующей старой системы останутся только в ней. Поэтому следующим важным и неотъемлемым шагом стал импорт данных из старой системы в новую.
Простое копирование данных было невозможно, так как возникли следующие сложности:
1. Существующая система в качестве объектного идентификатора использовала значение типа guid, а новая - int.
21
2. Модель новой системы предполагает наличие различных типов изданий, подразделяя их только на внешние и внутренние. В то время как в существующей системе было четкое разделение на типы изданий - журналы и конференции, которые в свою очередь могут быть собственными и чужими.
Исходя из этого, перенести данные нужно было так, чтобы не потерять связи первичных-внешних ключей и соответствия между записями.
Для выполнения данной задачи было написано множество многотабличных сложных запросов на языке SQL. Заполнение таблиц базы данных происходило последовательно, начиная с простых таблиц, которые не ссылались на другие таблицы и переходя к более сложным, содержащим отношения (связи) между таблицами.
4. Реализация бизнес-логики и проверка расчетных значений
Выполнив SQL-запросы и добавив тем самым данные из существующей системы в новую, необходимо было проверить, все ли записи успешно импортированы.
Для таблиц, значения которых хранятся в БД, данная задача не составила особого труда. Проверка осуществлялась путем сравнения количества записей, соответствующих таблиц различных систем.
Реализация вычисляемых атрибутов, используемых для расчета значений, потребовала написания бизнес-логики на языке C#. Ее правильность проверялась сопоставлением определенных значений существующей и новой системы. Так, если значения выбранных записей совпадали, следовал вывод о том, что реализация выполнена корректно.
Каждый класс - объект системы состоит из определенного количества атрибутов -записей. При этом каждый из них имеет свою степень значимости. Так, отсутствие информации о значении записи одного атрибута, никак не повлияет на функциональность системы, а отсутствие другого, наоборот, сделает работу системы некорректной.
Таким образом, чтобы не допустить возникновения некорректных ситуации при работе пользователя с системой, были определены следующие бизнес-правила.
1. Обязательный атрибут. Данное правило определено для атрибутов, значения которых важны для корректной работы системы. Так, пользователь не сможет сохранить запись, если значение данного атрибута будет отсутствовать.
2. Значение уникально. Данное правило определяет единственность значения атрибута или комбинации значений. Система не позволит пользователю сохранить запись со значением, уже имеющимся в ней.
3. Проверка значения или набора значений определенному предикату (логическому выражению).
4. Отсутствие правила означает, что наличие значения данного атрибута возможно, но необязательно. Его отсутствие в системе никак не повлияет на ее работу.
Выводы
В данной статье была рассмотрена разработка информационной системы каталогизирования научных работ, основанная на реинжиниринге существующей ИС каталогизирования конференции «Объектные системы». Рассмотрены назначение и содержание основных этапов и выполняемые действия. Дальнейшим развитием системы является доработка бизнес-правил, необходимых для правильного функционирования системы, а также настройка графических форм пользовательского интерфейса. В будущем планируется разработка Web-приложения для рассматриваемой системы.
Литература
1. Васенин В. А., Голомазов Д. Д., Ганкин Г. М. Архитектура, методы и средства базовой составляющей системы управления научной информацией "ИСТИНА — Наука МГУ" / Программная инженерия, № 9. 2014. С. 3-12
22
2. Олейник П.П. Опыт применения инструментов объектно-реляционного отображения при разработке информационной системы каталогизирования научных работ // Информационные технологии в науке, экономике и образовании: материалы 5-й Всероссийской научнопрактической конференции 2-3 сентября 2010 года / под. ред. О.Б. Кудряшовой; Алт. гос. техн. ун-т., БТИ. - Бийск: Изд-во Алт. гос. техн. уни-та, 2010. - С. 102-105.
3. Олейник П.П., Игумнов Е.А., Свечкарёв Е.А. Опыт проектирования информационной
системы для каталогизирования научных работ при проведении международных конференций // Объектные системы - 2010: материалы II Международной научно-практической
конференции. Россия, Ростов-на-Дону, 10-12 ноября 2010 г., Ростов-на-Дону, 2010. - С. 48-51.
4. Олейник П.П., Игумнов Е.А., Свечкарёв Е.А. Реализация модуля рецензирования в информационной системе проведения научных конференций // Объектные системы - 2011: материалы III Международной научно-практической конференции (Ростов-на-Дону, 10-12 мая 2011 г.) / Под общ. ред. П.П. Олейника. - Ростов-на-Дону, 2011. - С. 26-29.
УДК 04.004
УНИФИЦИРОВАННАЯ МОДЕЛЬ ТЕСТИРОВАНИЯ ИНСТРУМЕНТОВ РАЗРАБОТКИ ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ ПРИЛОЖЕНИЙ
Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,
ОАО "Астон", доцент, Шахтинский институт (филиал) Южно-Российского государственного политехнического университета им. М.И. Платова, Россия, Ростов-на-Дону, [email protected]
Введение
В настоящий момент существует множество инструментов, предоставляющих объектный подход для разработки приложений. Несмотря на наличие собственных достоинств и недостатков, основная цель их - предоставить разработчику все преимущества объектно-ориентированной парадигмы. Данная статья подробно описывает унифицированную модель тестирования инструментов разработки объектно-
ориентированных приложений, для демонстрации, которой использован графический унифицированный язык моделирования. Практическая реализация модели
продемонстрирована на примере применения классических методов (паттернов) объектнореляционного отображения (ОРО) в инструменте, разработанном автором. Таким образом, объектная модель приложения реализуется в среде реляционной СУБД. Такой подход наиболее оправдан, с точки зрения автора, потому что РСУБД - самый популярный тип систем управления БД.
1. Проектирование унифицированной модели тестирования
При проектировании унифицированной модели тестирования использован такой же подход, как при описании шаблонов (паттернов) проектирования в работе [1]. Этот подход предполагает описание многократно используемых решений широко распространённых проблем, возникающих при разработке программного обеспечения без привязки к конкретной предметной области. Основная задача данного раздела - это описание модели и структурных элементов (классов и ассоциаций), а не корректность модели и точность её соответствия конкретной предметной области.
Стандартным графическим языком моделирования различных аспектов объектных систем является язык UML. Этот язык, а именно структурные диаграммы классов, будут рассмотрены в данной работе. В итоге под унифицированной моделью тестирования инструментов разработки объектно-ориентированных приложений будем понимать диаграмму классов, состоящую из классов и атрибутов, и содержащую наиболее часто встречающиеся на практике отношения классов.
23
