CC BY
69
Рис. 2. Пример отношения композиции между классами
Отношения зависимости и обобщения не представлены в объектной модели на рисунке 1, но они также используются для описания отношений между объектами конфигурации. Например, отношение зависимости отражает взаимосвязь между прикладными объектами, когда один объект использует значения атрибутов другого объекта в своих операциях. Отношение обобщения может изображаться на диаграмме для отражения наследования предопределенных атрибутов и процедур прототипа конкретными прикладными объектами [2].
Разработанная объектная модель является основой для проектирования объектов прикладной конфигурации. В разработанных объектах конфигурации будет сохраняться информация по статистике заболеваемости, которая позволит формировать различные нестандартные аналитические отчеты.
Литература
1. Широбокова С.Н. Использование языка UML при проектировании прикладных приложений на платформе «1С:Предприятие 8»// Новые информационные технологии в образовании: доклады и выступления участников VIII Междунар. науч.-практ. конф. «Комплексная модернизация процесса обучения и управления образовательными учреждениями с использованием технологии 1С», Москва, 3-4 февр. 2009г. -Ч.3.-С.270-274.
2. Широбокова С.Н., Рябова М.В. Методика проектирования прикладных приложений на платформе "1С:Предприятие 8" с использованием языка UML// Компьютерное моделирование 2008: Труды Междунар. науч.-техн. конф., г.Санкт-Петербург, 24-25 июня 2008г. / СПб.: Изд-во Политехнического университета, 2008.- С. 245-252.
3. Нуралиев С. «Платформа 1С:Предприятие» как средство разработки бизнес-приложений // PC Magazine/RE. - 2006. - №11.
4. Широбокова С.Н., Хашиева Л.Н. Разработка информационных моделей экономических систем с использованием унифицированного языка моделирования UML: Учебное пособие / РГЭУ «РИНХ». - Ростов-на-Дону, 2002. - 144с.
УДК 004.9
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОД К СОЗДАНИЮ ТИПОВЫХ ИНФОРМАЦИОННЫХ СИСТЕМ ДЛЯ МУНИЦИПАЛЬНЫХ ОБРАЗОВАНИЙ
Григоров Антон Сергеевич, Череповецкий государственный университет, инженер-программист отдела информационных систем, МУ «Центр муниципальных информационных ресурсов и технологий», Россия, Череповец, antongrigorov1986@,gmail.com
Введение
Скорость разработки программного обеспечения растёт с каждым годом. Быстро изменяющиеся экономические, политические факторы часто требуют незамедлительного реагирования. Поэтому создаваемые информационные системы должны быть мобильны и
64
восприимчивы к таким изменениям, необходимо чтобы производимые корректировки в работе системы были менее трудоёмкими с точки зрения разработчиков, а новые функций системы были доступны для пользователей как можно скорее. Возникает необходимость создания инструментов, позволяющих ускорить разработку новых информационных систем и доработки уже имеющихся. В данной статье рассматривается механизм создания муниципальных геоинформационных систем, основанный на использовании метаописания предметных областей и автоматической генерации информационных подсистем по данному метаописанию. Также описывается модель ядра системы и принципы функционирования пользовательских подсистем. Данная модель разрабатывается на базе МУ «ЦМИРиТ» г. Череповца в рамках создания муниципальной геоинформационной системы (МГИС).
1. Общая структура муниципальной информационной системы
Одной из самых больших проблем, возникающих при создании МГИС, является то, что при изменении функций информационной системы (ИС) или добавлении новой подсистемы, как правило, приходится вносить достаточно большие изменения в существующую систему или переписывать всё программное обеспечение (ПО), использовавшееся до этого.
Для того чтобы решить эту проблему, вся муниципальная геоинформационная система и её подсистемы должны строиться по единой методике с помощью одних и тех же средств проектирования [1]. В программном комплексе при построении МГИС предлагается выделить две основные части: системную и функциональную [2].
Рис. 1. Общая структура муниципальной информационной системы
Системная часть образует базис информационной системы - её ядро. Ядро ИС должно быть независимо относительно реализуемой системой бизнес-логики, в первую очередь оно должно организовывать выполнение основных функций системы. Учитывая то, что в основном ИС муниципальных организации оперируют «картотечной» информацией, к таким функциям можно отнести:
1. ввод в систему данных об объекте и их редактирование;
2. поиск данных об объектах;
3. создание отчётов, основанных на данных, обрабатываемых в ИС.
Основной функцией ядра является интерпретация моделей конкретных подсистем: набора метаданных, в которых описывается множество объектов подсистемы и операций, выполняемых над этими объектами, указываются источники данных и методы доступа к ним, определяются способы отображения данных. Иными словами, метаданные «объясняют» ядру, где что в подсистеме находится, и как всем этим можно управлять.
Функциональная часть представляет собой набор прикладных подсистем, например "Адресный реестр" или "Земельный кадастр". Каждая подсистема описывается моделью метаданных с чётко определённой семантикой. В модели описываются объекты предметной области, их свойства, взаимосвязи с другими объектами, операции выполняемые объектами
65
и др. Для описания предметной области и построения моделей от функциональных программистов требуется выполнение следующих действий:
1. Определение основных объектов описываемой предметной области.
2. Выделение основных свойств объектов и разделение их на смысловые группы (представления объекта с разных точек зрения).
3. Выявление связей между объектами.
4. Описание операций, которые можно выполнять над объектами и их группами свойств (создание, удаление объекта; редактирование его свойств и др.)
5. Организация поисков объектов и создание шаблонов отчётов, которые могут быть в системе.
Рис. 2. Фрагмент описания подсистемы
Результатом выполненной работы будет модель, описанная на языке UML, отражающая структуру разрабатываемой подсистемы. На рис. 2 представлен пример фрагмента описания подсистемы «Аренда земли».
Для каждого элемента модели указывается, какие компоненты ядра системы с ним связаны. Например, для каждого выделенного класса объектов подсистемы должен быть указан компонент, предоставляющий доступ к хранилищу данных об объектах этого класса. В тоже время для каждого представления набора свойств объекта может быть указан модуль его отображения, а для отчёта - используемый компонент генерации отчётов. Во всех случаях для разных элементов системы могут использоваться различные компоненты, единственным условием является то, чтобы эти компоненты реализовывали определённый интерфейс, через который ядро системы будет с ними взаимодействовать.
В общем случае алгоритм работы ИС можно описать следующим образом:
1. Клиент выполняет запрос некоторых данных, обрабатываемых ИС.
2. Ядро системы выполняет запрос метаданных той подсистемы, с которой работает клиент.
3. На основе полученных метаданных ядро, определив источник требуемых данных и метод доступа к этим данным, выполняет запрос за данными.
4. После получения требуемых данных ядро также на основе метаданных определяет способ их отображения и формирует ответ клиенту.
В рассматриваемой модели доступ пользователей к ресурсам ИС осуществляется средствами веб-приложения. Данный подход имеет следующие преимущества:
1. Любые изменение функционала ИС станут сразу же доступны пользователям.
2. Уменьшение затрат на настройку, обновление программного обеспечения на операторских местах. Для начала работы в системе требуется лишь установленный браузер.
66
Резюмируя сказанное выше можно сказать, что смысл отделения функциональной части от системной заключается в том, что при разработке новых подсистем программистам не придётся заниматься кодированием «ядра» приложения: нужно будет лишь описать метамодель создаваемой подсистемы. Следует отметить также, что при данном подходе, основывающемся на использовании моделей метаданных, описывающих подсистемы, можно организовать автоматическую генерацию структуры базы данных, предназначенной для хранения объектов информационной системы. Это позволит увеличить скорость разработки и внедрения новых ИС [3].
2. Автоматическая генерация приложения на основе модели
Построенная модель может быть использована для автоматической генерации структуры реляционной базы данных (БД). Так каждый объект системы (<<Object>>) транслируется в таблицу базы данных. Связь между объектам в зависимости от своей мощности переводится в набор внешних ключей или, в случае со связью многие ко многим, в таблицу, хранящую пары внешних ключей связываемых объектов. Группам свойств (<<View>>), объединяющих сходные характеристики объекта вместе, ставятся в соответствие представления в БД.
Рис. 3. Автоматическая генерация приложения на основе модели
Выполняемые объектами операции могут быть представлены в виде хранимых процедур и функций БД или программных модулей, написанных на языках программирования, выполнение которых поддерживает ядро системы (например, JavaScript, Java, Ruby, Groovy и др.). Кроме этого, после этапа создания структуры хранения данных, таблицы БД могут быть заполнены тестовыми данными, что позволит получить прототип работающей подсистемы, выполнить её тестирование, а также обнаружить ошибки и неточности в описании модели. Если моделируется какая-либо картотечная или учётная информационная система, то чаще всего уже после создания модели и автоматической генерации приложения, можно получить почти полностью готовый к работе комплекс.
Заключение
Описанный в данной статье подход применяется в МУ «ЦМИРиТ» г. Череповца в рамках создания муниципальной геоинформационной системы (МГИС). В рамках проекта была разработана детальная спецификация правил описания прикладных подсистем. Для хранения моделей разработана структура xml-файла со строгой семантикой, позволяющая однозначно интерпретировать создаваемые модели. Для возможности автоматического создания информационной системы был разработан генератор, который посредством XSLT-преобразований переводит модель подсистемы в набор скриптов схемы БД для целевой СУБД (Oracle, MySQL) и исходный код логики работы подсистемы на конкретном языке программирования (PL/SQL, SQL/PSM, Java, JavaScript, Ruby и др.).
Указанный подход позволил значительно сократить временные затраты на создание новых подсистем для муниципальной геоинформационной системы г. Череповца.
67
Литература
1. Максимов И. В. Дата-центры как средства оптимизации затрат на содержание IT-инфраструктуры муниципальных образований. Материалы 3-й Всероссийской конференции «Геоинформационные технологии в муниципальном управлении», Уфа 2009. [Электронный ресурс]. - Режим доступа: http://www.gisa.ru/52101.html
2. Григоров А.С., Григоров А.С. Создание информационных систем для муниципальных образований. Информатизация процессов формирования открытых систем на основе СУБД, САПР, АСНИ и систем искусственного интеллекта (ИНФОС-2009): Материалы 5-й межд. научно-техн. конф. - Вологда: ВоГТУ, 2009. С. 85-88.
3. Григоров А.С., Григоров А.С. Создание информационных систем для муниципальных образований с помощью подхода, основанного на метаданных. Вузовская наука - региону. Материалы 8-й всеросс. научно-техн. конф. - Вологда: ВоГТУ, 2010.
УДК 519.682.4, 371.32
ПРОБЛЕМЫ ПРЕПОДАВАНИЯ ОБЪЕКТНЫХ ТЕХНОЛОГИЙ В ЭКОНОМИЧЕСКОМ ВУЗЕ
Штанюк Антон Александрович, к.т.н., доц., Нижегородский коммерческий институт, Россия,
Нижний Новгород, shtan@land.ru
В мире современных информационных технологий объектный подход давно уже занимает прочные позиции в связи с широким применением объектных технологий и языков в инженерной практике. Однако далеко не везде признают необходимость изучения объектно-ориентированного подхода (ООП) при подготовке специалистов прикладных направлений, в том числе экономического, несмотря на использование в экономических ВУЗах соответствующих языков программирования (С++, Java, Object Pascal). В данной работе рассматриваются часто встречающиеся проблемы, связанные с данным вопросом и предлагаются способы снижения их негативных последствий.
К причинам отсутствия должного образования в области ООП, на наш взгляд, относятся:
• упрощенное понимание объектной парадигмы;
• незнание методов и подходов самим преподавателем;
• сложность предметной области и моделей предметной области;
• незаинтересованность или низкая мотивация со стороны обучающихся.
Упрощенное понимание объектной парадигмы заключается в том, что многие
преподаватели трактуют ООП в качестве надстройки над традиционным процедурным подходом, позволяющим упростить разработку программ. Самым популярным примером из этой области является трактовка класса С++ как «дальнейшего развития понятия структуры». В результате класс начинает использоваться не в качестве базового механизма описания объекта, а как удобный способ хранения данных, к которому прилагаются еще и функции для их обработки. В программе самым причудливым образом сочетаются обособленные объекты, глобальные функции и переменные. Самым печальным последствием такого подхода, является внутренняя несогласованность различных частей программы, «нестыковка» различных классов между собой.
Неправильное использование объектной парадигмы приводит к появлению программ, гораздо хуже приспособленных для изучения и сопровождения, чем при использовании других парадигм. В результате создается большое количество однотипных и посредственных программ, вместо небольшого числа хорошо продуманных и спроектированных.
Незнание объектно-ориентированных методов и подходов самим преподавателем — к сожалению, весьма распространенное явление. Ведь многие преподаватели в силу субъективных или объективных причин не желают повышать свой профессиональный уровень, знакомиться с инструментами ООП и составлять модели предметной области, в
68
