АрхитектураИС_Семестр3_МетодПособие8-9

41

Выводы

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

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

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

При моделировании систем, особенно интерактивных, возникает необходимость работать с объектами принципиально различного типа. Язык UML имеет возможности моделирования классов (и соответственно объектов) в широком диапазоне от непрограммных сущностей до примитивных типов данных.

Контрольные вопросы

Дайте определение понятию класс.

1.В чем разница между понятиями «класс» и объект?

2.Какие основные элементы содержит спецификация класса?

3.Какими свойствами могут обладать атрибуты?

4.Что включает в себя описание процедуры?

5.Что специфицируют обязанности классов, и на каком этапе проектирования их рекомендуется использовать?

6.Дайте характеристику понятию «словарь системы»

7.Чем рекомендуется руководствоваться при распределении обязанностей классов?

42

8. Приведите примеры непрограммных сущностей, как они представляются средствами UML?

9.Когда применяются примитивные типы? Привадите примеры спецификации примитивных типов на UML-диаграммах.

10.Чем рекомендуется руководствоваться при моделировании классов?

Упражнения

1. Смоделируйте класс «Студент», специфицируйте свойства его атрибу-

тов.

2.Смоделируйте класс «Статистическая выборка», включающий массив исходных данных и вычисляющий, минимальное, максимальное, среднее значение и среднеквадратичное отклонение. Специфицируйте конструкторы и операции, укажите область видимости операций.

3.С использованием класса«Статистическая выборка» из упражнения 3 определите класс «Упорядоченная выборка», позволяющий получить упорядоченный массив элементов. Специфицируйте конструкторы и операции, укажите область видимости операций.

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

5.По выполнению упражнения 4 определите атрибуты и операции введенных классов, результаты отобразите на диаграмме классов UML.

6.Информационная система торгового предприятия производит учет товаров, клиентов, фиксирует произведенные продажи. Для построения модели данной системы введите классы и распределите обязанности между ними.

7.По выполнению упражнения 6 определите атрибуты и операции введенных классов, результаты отобразите на диаграмме классов UML.

43

информационной системы музыки наCD. Данная система должна предоставлять пользователю средства электронной картотеки, включать в себя такие возможности как: добавление, удаление и редактирование данных об исполнителях, альбомах; обеспечивать поиск записи по названию альбома, по стилю; поиск исполнителя; просмотр обложки альбома и фотографии исполнителя.

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

В качестве среды моделирования будемиспользовать систему

Rational Rose [3] фирмы Rational Software, являющейся признанным лидером в разработке систем моделирования программного обепспечения.

3.1. Диаграмма прецедентов

Диаграмма прецедентов является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor)

или действующим лицом называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.

В данной модели актером является пользователь электронной базы данных музыки, а набором действий - редактирование данных и поиск. Между сущностью «Пользователь» и «Редактирование»,

46

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

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

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

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

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

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

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

Если реляционная модель была построена на базе хорошо продуманной объектно-ориентрованной модели, полученная реляционная модель обычно не содержит аномалий обновления и удаления информации и удовлетворяет условиям нормализации. Однако полезно проверить полученную реляционную модель на соответствие нормальным формам (см., например, [5, c. 89].

На рис. 3.3. приводится диаграмма профиля данных для разрабатываемой нами информационной системы «музыка на CD».

47

Рис 3.3. Профиль базы данных

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

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

ме и, следовательно, может потенциально участвовать во всех ее взаимодействиях.

Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни. Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия. Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом.

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

48

циируются раньше тех, которые расположены ниже.

1: Ввсти новую запись

2: Активизировать поля формы

3: Ввести название альбома, стиль, год выпуска, описание

4: Сохранить новую запись

5: Сохранить новую запись

6: Создать запись альбома

7: Присвоить название альбома , стиль, год выпуска, описание

8: Сохранить запись

9: Сохранить запись в базе данных

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

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

49

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

вбазе данных.

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

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

граммирования Borland Delphi .

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

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

RDL – это генерация кода и обратное проектирование. Генерируемый RDL код не содержит реализацию функциональности. Генерируются только декларативные элементы: определения классов, интерфейсов, записей, типов и т.д. Основная идея обратного проектирования состоит в том, что все изменения, сделанные на уровне программного кода в Delphi отображаются в объектной модели, построенной в Rational Rose, и наоборот, при изменении классов, методов и т.д. в объектной модели Rational Rose, соответственно, корректируется программный код.