Файл: Применение объектно-ориентированного подхода при проектировании информационной системы.pdf

В данной модели актером является пользователь электронной базы данных музыки, а набором действий - редактирование данных и поиск. Между сущностью «Пользователь» и «Редактирование», «Пользователь» и «Поиск исполнителя», а также «Пользователь» и «Поиск альбома», определены отношения ассоциации. Между сущностью «Редактирование» и сущностями «Создание новой записи», «Удаление записи», «Изменение записи» определены отношения включения (include). Между сущностью «Поиск альбома» и сущностями «по названию», «по стилю» также проставлены отношения включения. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой. Диаграмма прецедентов приводится на рис. 4.

Рисунок 4. Диаграмма прецедентов (Use Case Diagram)

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

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

В нашем случае основным является класс «Исполнитель» с атрибутами: «Название», «Дата рождения», «Страна проживания», «Награды», «Фото». С помощью отношения ассоциации он связан с классом «Альбом», с помощью реализации – с классом «Поиск исполнителя», имеющим стереотип «interface», и с классом «Тип Стиля», имеющим стереотип «enum». Классы «Исполнитель» и «Альбом» связаны с классом «Электронная таблица», не имеющим атрибутов, с помощью отношений обобщения. Диаграмма классов для разрабатываемой нами системы приводится на рис. 5.

Рисунок 5. Диаграмма классов (Class Diagram)

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

Подробно о преобразовании объектно-ориентированной модели в реляционную можно прочитать в [6], мы остановимся на основных моментах:

1) основные классы, содержащие данные, предназначенные для хранения, преобразуются в таблицы;

2) при наличии ассоциаций типа «один-к-одному» хотя бы с одной стороны нужно добавить дополнительное кодовое поле где указать код (ключ) второй записи для обеспечения связи данных;

2) при наличии ассоциаций типа «один-ко-многим» со стороны подчиненных записей (со стороны «многие») необходимо ввести дополнительное поле, где указать код (ключ) записи которой они подчиняются (со стороны «один»);

3) при наличии ассоциаций типа «многие-ко-многим» необходимо ввести дополнительную таблицу связей, содержащую минимум два поля: код одного участника и код второго участника, таким образом ассоциация типа «многие-ко-многим» преобразуется в две ассоциации типа «один-ко-многим» через таблицу связи;

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

3.3. Диаграммы взаимодействия

На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Диаграмма последовательности имеет как бы два измерения. Одно - слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Она служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях.

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

Рисунок 6. Диаграмма последовательностей (Sequence Diagram)

В данном примере инициатором является «Пользователь» он посылает сообщение «Ввести новую запись» объекту «Электронная таблица», а также сообщения «Ввести название альбома, стиль, год выпуска, описание» и «Сохранить запись» объекту. Далее объект «Форма базы данных музыки» получает сигнал «Активизировать поля формы». Эта форма передает сигнал объекту «Менеджер записи» о сохранении записи. «Менеджер записи», в свою очередь, создает новую запись, присваивает ей название альбома, стиль, год выпуска, описание. и передает сообщение объекту «Менеджер транзакций» о сохранении новой записи. «Менеджер транзакций» сохраняет запись в базе данных.

3.4. Реализация информационной системы

Для реализации модели справочно-информационной системы музыки на CD была выбрана одна из самых популярных систем программирования Borland Delphi .

Delphi — это среда быстрой разработки, в которой в качестве языка программирования используется строго типизированный объектно-ориентированный язык Object Pascal, В основе работы Delphi лежит технология визуального проектирования и событийного программирования, суть которой заключается в том, что среда разработки берет на себя большую часть рутинной работы, оставляя программисту работу по конструированию диалоговых окон и функций обработки событий.

Для поддержки процесса программирования из среды моделирования обычно используются специальные программные средства.

Фирмой Ensemble Systems разработана программа-мост Rose Delphi Link (RDL), связывающая Rational Rose и Delphi. Основные функции RDL – это генерация кода и обратное проектирование. Генерируемый RDL код не содержит реализацию функциональности. Генерируются только декларативные элементы: определения классов, интерфейсов, записей, типов и т.д.

Рисунок 7. Диаграмма классов, выполненная с помощью Rose Delphi Link

Мощность и гибкость Delphi при работе с базами данных, возможность связи с Rational Rose и отсутствие специальных требований к ресурсам компьютера, позволяют эффективно использовать Delphi для разработки приложения справочно-информационной системы музыки на CD.Приложение состоит из одной формы, на которой находятся следующие основные компоненты: DBGrid, DBEdit, DBNavigator, Table, DataSource и Query.

Рисунок 8. Внешний вид диалогового окна

Слева на форме отображаются характеристики исполнителя, такие как, «Исполнитель», «Дата рождения», «Страна проживания», «Награды», «Фото».

Справа на форме отображаются сведения об альбоме, такие как, «Исполнитель», «Название альбома», «Стиль», «Год выпуска», «Описание».

Поиск осуществляется с помощью компонента Query, в котором формируется SQL-запрос на выборку. Полученный результат отправляется в компонент DataSource и после этого отображается в компоненте DBGrid.

Ниже представлен вариант поиска исполнителя по названию.

Рисунок 9. Поиск по критериям

Итак, проанализировав предметную область и поставленную задачу, с помощью программы Rational Rose была разработана концептуальная модель информационно – справочной системы музыки на CD. Затем эта модель была реализована в Borland Delphi 7. В результате получилась удобная и наглядная система, с помощью которой пользователь всегда будет знать о том, какие альбомы и каких исполнителей имеются в его фонотеке, добавлять данные при приобретении нового диска или удалять при утере.

В [7] приводится пример подробной разработки модели медицинского учреждения средствами UML.

Выводы

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

Cструктура программной системы задается структурой классов. Диаграммы классов UML предоставляют мощные средства специфицирования классов. Грамотное использование наследования и полиморфизма, применение интерфейсов составляют основу построения эффективной модели статического вида с точки зрения разработки. Для описания поведенческих (динамических) аспектов данного вида модели системы используются взаимодействия.

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

Развитые CASE-средства, построенные на основе UML (прежде всего Rational Rose) поддерживают связь с средствами программирования, что позволяет осуществлять переход от модели к исходному коду программы (прямое проектирование) и обратно (обратное проектирование), что создает основу для эффективной поддержки программных приложений и их модернизации.

ЗАКЛЮЧЕНИЕ

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

Можно выделить основные этапы разработки системы с использованием средств UML:

1) описание задания в общих чертах на естественном языке;

2) выделение прецедентов и актеров бедующей системы;

3) определение объектов и взаимодействий между ними;

4) детализация функциональности с помощью диаграмм последовательности (переходов) для каждого прецедента;

5) группировка объектов, переход от объектов и сущностей к компонентам;

6) ревизия результатов предыдущих этапов;

7) детальная проработка реализации компонентов, разделение компонентов по участникам коллектива разработчиков;

8) Построение профиля баз данных с учетом способа хранения данных в выбранной СУБД;

9) размещение компонентов системы;

10) кодирование.

Каждый этап поддерживается соответствующими UML-диаграммами.

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

Язык UML является открытым языком. Механизмы расширения позволяют построить развернутую модель с учетом специфических особенностей конкретной предметной области, оттенить некоторые нюансы структуры и поведения вводимых элементов. Язык постоянно развивается, новые версии языка содержат расширенный набор стереотипов для моделирования бизнес-отношений, хранилищ данных, WEB-приложений. На базе новых стереотипных классов строятся новые диаграммы, например диаграмма бизнес-прецедентов (используется на начальном этапе проектирования при проведении так называемого бизнес-моделирования), содержащая не так давно введенные бизнес-актеры и бизнес-прецеденты.