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

8. Филлмор Ч. Дело о падеже // Новое в.зарубежной лингвистике. М.: Прогресс, 1981. Вып.Х. С. 369-495.

УДК 04.004

ТЕСТОВАЯ МОДЕЛЬ ДЛЯ ОБУЧЕНИЯ ПРОЕКТИРОВАНИЮ ОБЪЕКТНООРИЕНТИРОВАННЫХ БАЗ ДАННЫХ

Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,

ОАО "Астон", доцент, ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, [email protected]

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

Рис. 1 - Концептуальная (слева) и логическая (диаграмма классов, справа) модели тестовой

предметной области

В качестве предметной области использована информационная система для отдела кадров. Эта предметная область понятна каждому специалисту и довольно подробно описана в различных источниках, в том числе и работе, посвященной языку моделирования UML [1]. Т.к. реализовать структуру БД необходимо в среде ООСУБД, то финальной стадией проектирования является построение диаграммы классов, для которой были выделены следующие критерии оценивания (КО), требующие наличия:

1. Глубокой иерархии наследования;

2. Абстрактных и реализованных классов;

3. Сложных (n-арных) ассоциаций;

4. Связей с атрибутами;

5. Перечислений;

6. Рекурсивных связей.

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

86

сложной задачей. Поэтому в тестовой модели необходимо предусмотреть не менее трех классов, связанных отношением наследования.

При проектировании структуры БД студент детально изучает описание предметной области. Описание представляет набор предложений, представляющих бизнес-процессы. С точки зрения реализации описываются только экземпляры конкретных классов, но при проектировании необходимо выделить наиболее общее поведение, что приводит к появлению на диаграмме классов абстрактных классов, экземпляры которых не будут созданы в системе (в ООСУБД). Точное понимание различий между абстрактными и конкретными классами - это основа основ при проектировании, поэтому требование наличия таких сущностей оформлено в КО2.

Функциональные возможности унифицированного языка моделирования UML позволяют описать не только простые бинарные ассоциации, соединяющие только два класса, но и более сложные (n-арные), соединяющие три и более класса. Именно для представления таких элементов введён КО3. Особенно интересны подобные связи с точки зрения реализации в целевом языке программирования, так как приводят к появлению промежуточного класса.

Перейдем к КО4. Выделение характеристик, относящихся к конкретным сущностям, в конечном итоге приводит к появлению атрибутов, принадлежащих к определенным классам. Опыт преподавания показал, что у студентов возникают некоторые проблемы при выделении атрибутов, относящихся к связям. Сложность состоит в том, что значения атрибутов относятся не к экземпляру сущности, а именно к экземпляру связи.

Очень часто необходимо предусмотреть набор заранее предопределенных констант, имеющих определенный смысл в контексте предметной области. Для подобных случаев вводятся перечисления, требование наличия которых представлено в КО5.

Наличие рекурсивных связей предполагает присутствие отношений ассоциации, на обеих краях которой присутствует один и тот же класс. В КО6 описано требование наличия подобных связей. Эти связи могут присутствовать во многих предметных областях и реализуются в виде древовидных структур.

Перейдем к процессу проектирования. Изучение процесса проектирования основывается на методологии «сущность-связь», описанной в работе [2]. Разработка структуры любой базы данных начинается с анализа, в ходе которого изучаются предметная область, основные бизнес-процессы, требования и пожелания будущих пользователей системы. Этот этап определяется с установления границ будущей разрабатываемой системы и определения функционала, который необходимо реализовать в будущем приложении.

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

Предпоследним этапом является логическое проектирование БД, под которым понимается конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учёта специфики используемой СУБД и прочих условий реализации. В общем случае, логическое проектирование базы данных заключается в преобразовании концептуальной модели данных в логическую модель данных предприятия с учетом выбранного типа СУБД (в нашем случае - в понятия объектной СУБД). Логическая модель данных является источником информации для этапа физического проектирования. Она предоставляет разработчику физической модели данных средства проведения всестороннего анализа различных аспектов работы с данными, что имеет важное значение для выбора эффективного проектного решения.

87

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

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

Из представленного ранее видно, что процесс разработки структуры БД начинается с концептуального проектирования. На рис. 1 слева представлены все выделенные сущности, связи и атрибуты. Для описания организаций выделана сущность Company. С целью представления группы компаний и организации древовидной структуры используется рекурсивная связь Include. Сущность Department представляет отдел внутри организации. Для описания каждой должности выделена сущность Post. Тип должности (постоянная или временная) представлен перечислением PostKind. Информация о каждом работнике сохраняется в сущности Worker. Уровень заработной платы отображается в сущности Salary. Сложная связь Position представляет собой конкретную должность, занимаемую определенным сотрудником в указанном отделе указанной организации. При этом описанная ассоциация имеет атрибуты.

При построении логической объектно-ориентированной модели была детально проанализирована концептуальная модель. Оказалось, что многие сущности имеют одинаковые атрибуты сходного назначения. Например, атрибут Name, сохраняющий название, присутствует в сущностях Company, Department, Worker, Post, поэтому было принято решение выделить класс NamedObject Так как в предметной области отсутствуют экземпляры данной сущности, то полученный класс является абстрактным.

При анализе концептуальной модели оказалось, что многие сущности имеют атрибут Telephone, позволяющий сохранить номера телефонов. В логической модели для описанных целей был выделен абстрактный класс TelephonedObject. Многие классы одновременно имеют атрибуты Name и Telephone. Чтобы избавиться от необходимости наследоваться от обоих классов объявлен промежуточный абстрактный класс NamedAndTelephonedObject.

Абстрактный класс AddressedObject содержит атрибут Address, который сохраняет адрес. Этот класс является базовым для классов Company и Worker. Остальные сущности переносятся с концептуальной модели практически без изменений.

Проверим полученную диаграмму классов на соответствие выделенным критериям оценивания. Из рис. 1 видно, что присутствует глубокая иерархия классов, т.к. класс Worker наследуется от класса AddressedObject, который унаследован от NamedAddTelephonedObject и выступает дочерним по отношению к абстрактным классам NamedObject и TelephonedObject. Следовательно, требования КО1 выполнены.

Абстрактные классы, которые не отражают объекты предметной области, позволили упростить модель, и они имеются в достаточном количестве на построенной диаграмме классов. Это позволяет утверждать, что требования КО2 выполнены.

Сложная ассоциация Position представляет собой n-арную связь и её наличие говорит о том, что требования КО3 соблюдены. Требования КО4 выполнены, т.к. имеется классассоциация, имеющая атрибуты. В данном случае атрибуты DateStart и EmployeeNumber не относятся к какой-либо сущности, входящей в связь, а относятся именно к экземпляру ассоциации.

Условия КО5 также выполнены, т.к. на диаграмме классов имеется перечисление. Рекурсивная связь представлена отношением ассоциацией Include, которая позволяет

88

описать группу компаний, что в итоге представится в виде иерархической структуры и соответствует требованию КО6.

Таким образом, из описания видно, что представленная на рис. 1 (справа) диаграмма классов соответствует всем выделенным критериям оптимальности. Следующим шагом является реализация в среде целевого языка программирования и платформы. Студенты самостоятельно выбирают предпочитаемый язык программирования. Как правило, это либо C#, либо Java. При этом в качестве ООСУБД применяется бесплатная версия DB4O, в которой имеется набор библиотек для обоих перечисленных языков.

Литература

1. Новиков Ф.А., Иванов Д.Ю. Моделирование на UML. Теория, практика, видеокурс. - СПб.: Профессиональная литература, Наука и Техника, 2010. - 640 с.: ил. + цв. Вклейки (+ 2 DVD).

2. Коннолли, Томас, Бегг, Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. - М. : Издательский дом "Вильямс", 2003. - 1440 с. : ил. - Парал. тит. англ.

УДК 04.004

ОРГАНИЗАЦИЯ ПОРТАЛА НАУЧНОГО СОТРУДНИЧЕСТВА

Маликова Валерия Игоревна, ученица 8 «Б» класса, гимназии им. А. С. Пушкина города Шахты,

Россия, Шахты, [email protected]

Олейник Павел Петрович, к.т.н, системный архитектор программного обеспечения,

ОАО "Астон", доцент, ШИ (ф) ЮРГПУ (НПИ) им. М.И. Платова, Россия, Ростов-на-Дону, [email protected]

Информационные технологии - это наука о хранении, обработке и передаче данных с применением персонального компьютера. Сейчас понятие «Информационные технологии» также известно как «Компьютерные технологии». Существующие естественные науки -химия, биология, физика и другие - состоят из отдельных дисциплин, но Информационные технологии объединяют множество отдельных дисциплин в одно целое для изучения общего предмета - информатики и вычислительной техники. К их числу относятся: теория информации, кибернетика, программирование, теория алгоритмов, искусственный интеллект и многое другое. Развитию Информационных технологий послужило одно из самых значительных достижений XX века - создание электронно-вычислительных машин - ЭВМ. Термины «компьютер» и «электронная-вычислительная машина» можно рассматривать как синоним.

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

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

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

В России не существует полномасштабных научных порталов, а существует множество научных форумов, организованных на базе ВУЗов.

89