Модель хранения данных

Модели данных служат для проектирования структуры постоянных хранилищ данных, используемых системой. Они бывают двух типов:

a) Логическая и

b) Физическая.

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

В логической модели данных отображаются ключевые сущности и взаимосвязи, относящиеся к важнейшей информации, которую приложению необходимо хранить в базе данных. Она связана с моделью классов, которые используются при проектировании программы. Логическая модель отражает ключевые логические сущности и их взаимосвязи, необходимые для соблюдения требований системы к постоянному хранению данных в соответствии с общей архитектурой приложения. В теории баз данных логическую модель еще называют моделью «сущность – связь» илиER-диаграммой (от Entity – сущность и Relationships – связь).

Модель содержит совокупность сущностей, представленных в виде прямоугольников, внутри которых записывается название. Сущности связываются между собой линиями (отношениями), которые сопровождаются надписями, указывающими тип отношения: один к одному, один ко многим или многие ко многим. Типы связей и отношений иллюстрирует рисунок 6.3. На нем числом указывается конкретное (начальное) значение отношения, а звездочкой – любое (много).

Рис. 6.3

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

Рис. 6.4

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

Пример логической модели данных для объекта «Клинические записи» приведен ниже на рис. 6.5.

Рис.6.5

Модель показывает, что клинические записи включают (агрегируют) ряд блоков. При этом «минимальный набор данных» и «план лечения» могут быть включены в каждую клиническую запись в единственном экземпляре, а блоки «результаты анализов», «предписания врача», «ход лечения» могут повторяться неограниченное число раз.

Архив состоит из множества клинических записей (агрегирует клинические записи), но может быть и пустым.

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

Физическая модель данных состоит из подробных макетов таблиц базы данных и их взаимосвязей, созданных на основе логической модели. Таблицы в ней содержат параметры столбцов, а также ключи и индексы.

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

Рис. 6.6

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

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

На следующем рисунке (6.7) представлен фрагмент модели базы данных— две таблицы, соответствующие классам «пациент» и «минимальный набор данных» (см. рисунок для объекта «Клинические записи» логической модели данных). Связьмежду ними обязательная, поскольку «минимальный набор данных не может существовать без «пациента».

Рис.6.7 Фрагмент модели базы данных

На диаграммах указываются дополнительные характеристики таблиц и столбцов:

a) Ограничения, которые определяют допустимые значения данных в столбце или операции над данными:

- (ключ (PK,FK) – ограничение, определяющее тип ключа и его столбец;

- проверка (Check) – ограничение, определяющее правило контроля данных;

- уникальность (Unique) – ограничение, определяющее, что в столбце содержатся неповторяющиеся данные);

b) триггер – программа, выполняющая при определенных условиях предписанные действия с базой данных;

c) тип данных и пр.

Диаграммы вариантов использования

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

Цели построения диаграммы:

1) определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования;

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

3) разработать исходную концептуальную модель системы для ее последующей реализации;

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

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

Таким образом, основными компонентами ДВИ являются:

a) Актеры;

b) Прецеденты;

c) Отношения.

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

Рис. 6.8

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

Стандартное графическое изображение актера представлено на рис. 6.9.

Актер всегда находится вне системы, его внутренняя структура никак не воспринимается.

Рис. 6.9

Примеры актеров: клиент банка, банковский служащий, продавец, сотовый телефон.

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

Отношения

Один актер может взаимодействовать с несколькими вариантами использования и наоборот.

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

Виды отношений

1) ассоциативное (отношение ассоциации, association relationship);

2) расширения (extend relationship);

3) обобщения (generalization relationship);

4) включения (include relationship).

Отношение ассоциацииустанавливается между вариантом использования и актером и отражает связь между ними. Оно определяет, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. Обозначение: в виде прямой линии. Могут быть дополнительные обозначения (кратность, направление связи, наименование), как показано на рис. 6.10.

Рис. 6.10

Отношение расширенияопределяет взаимосвязь базового варианта использования с некоторым другим вариантом, функциональное поведение которого задействуется базовым не всегда, а только при выполнении некоторых дополнительных условий. Стрелка указывает на базовый вариант использования (см. рис. 6.11).

Рис. 6.11

Отношение обобщенияслужит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования Б (или актер А может быть обобщен до актера Б). Стрелка указывает в сторону родительского ВИ (актера). Такие отношения изображены на рис. 6.12 и 6.13.

Рис. 6.12

Рис. 6.13

Отношение включенияуказывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта. Пример такого отношения приведен на рис. 6.14.

Рис. 6.14

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

Рис. 6.15

Примеры диаграмм вариантов использования

ДВИ процесса оформления заказа на покупку товара приведена на рис. 6.16, а Диаграмма прецедентов для процесса постройки дома – на рис. 6.17.

Рис. 6.16

Рис. 6.17

Диаграммы классов

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

Класс – это множество объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. На диаграмме он представляется прямоугольником, который может иметь вид, приведенный на рис. 6.18.

Рис. 6.18

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

Атрибут - это свойство, которое является общим для всех объектов данного класса. Общий формат записи атрибутов:

<квантор видимости> <имя атрибута> [кратность]: <тип атрибута> = <исходное значение> {строка-свойство}

Квантор видимости может принимать одно из следующих значений: +,#,-,~.

«+» - атрибут с областью видимости типа общедоступный (public).

«#» - атрибут с областью видимости типа защищенный (protected).

«-» - атрибут с областью видимости типа закрытый (private).

«~» - атрибут с областью видимости типа пакетный (package).

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

Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. Формат:

[нижняя граница . . верхняя граница]

Примеры: [0..1], [0..*], [1..3,5..7].

Тип атрибута - выражение, определяемое некоторым типом данных (в зависимости от языка программирования). В простейшем случае – осмысленная строка текста.

Пример:

цвет: Color

имяСотрудника[1..2]: String;

видимость: Boolean

Исходное значениеслужит для задания некоторого начального значения в момент создания отдельного экземпляра класса.

Пример:

цвет: Color = (255, 0, 0)

имяСотрудника[1..2]: String = ‘Иван Иванов’;

видимость: Boolean = истина

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

Пример:

заработнаяПлата: Currency = $500 {frozen}

Операции классапредставляют собой некоторый сервис, который предоставляет каждый экземпляр класса или объект по требованию своих клиентов.

Правила записи операций:

<квантор видимости> <имя операции> (список параметров):
<выражение типа возвращаемого значения> {строка-свойство}

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

<вид параметра> <имя параметра>: <выражение типа> = <значение по умолчанию>

Строка-свойство служит для указания значений свойств, которые могут быть применены к данной операции. Например, для указания последовательности действий будет использована строка-свойство вида:

{concurrency = имя} ,

где имя может принимать одно из следующих значений:

sequential (последовательная),

concurrent (параллельная),

guarded (охраняемая).