Файл: Проектирование ПО Структурный подход.docx

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

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

6.4. Проверка адекватности логической модели

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

«Студент получает оценки за экзамены. Много оценок (по разным предметам) выставляются одному студенту».

Рис. 6.3.

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

6.5. Выбор первичного ключа

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

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

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

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

При проведении связи между двумя сущностями в дочерней сущности автоматически образуются внешние ключи (foreign key). Связь образует ссылку на атрибуты первичного ключа в дочерней сущности, и эти атрибуты образуют внешний ключ в дочерней сущности. Атрибуты внешнего ключа обозначаются символами (FK) после своего имени.

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

Таблица 6.1. Атрибуты сущности «Студент»

В полученном списке существуют атрибуты, которые нельзя определить в виде одного поля БД. Такие атрибуты требуют дополнительных определений и должны рассматриваться как сущности, состоящие, в свою очередь, из атрибутов. К таковым относятся: опыт работы, иностранный язык, тестирование, экспертная оценка, оценки по экзаменам. Определим их атрибуты (таблицы 6.2 – 6.5).

Таблица 6.2. Атрибуты сущности «Опыт работы»

Таблица 6.3. Атрибуты сущности «Иностранный язык»

Таблица 6.4. Атрибуты сущности «Тестирование»

Таблица 6.5. Атрибуты сущности «Экспертная оценка»

Составим ERD-диаграмму, определяя типы атрибутов и проставляя связи между сущностями (рис. 6.4). Все сущности будут зависимыми от сущности «Студент». Связи будут типа «один-ко-многим».

Рис. 6.4.

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

Следующим этапом при построении логической модели является определение типов атрибутов (табл. 6.6).

Таблица 6.6. Типы атрибутов

Раздел 7. Описание методологии STD

Диаграмма переходов состояний STD (State Transition Diagrams) предназначены для моделирования и документирования аспектов систем, зависящих от времени или реакции на событие. Они позволяют осуществлять декомпозицию управляющих процессов и описывают отношения между входными и выходными управляющими потоками для управляющего процесса-предка.

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

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

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

Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так и внутри моделируемой системы при выполнении некоторого условия (например, счетчик=999 или «кнопка нажата»). Следует отметить, что, вообще говоря, не все события вызывают переходы из отдельных состояний. С другой стороны, одно и то же событие не всегда вызывает переход в то же самое состояние.

Таким образом, условие представляет собой событие (или события), вызывающее переход и идентифицируемое именем перехода. Если в условии участвует входной управляющий поток управляющего процесса-предка, то имя потока должно быть заключено в кавычки, например, «пароль»=999, где пароль - входной поток управляющего процесса-предка.

Кроме условия с переходом может связываться действие или ряд действий, выполняющихся, когда переход имеет место. То есть действие – это операция, которая может иметь место при выполнении перехода. Если действие необходимо для выбора выходного управляющего потока управляющего процесса-предка, то имя этого потока должно заключаться в кавычки, например:

«Введенная карта» =true,

где Введенная карта – выходной поток управляющего процесса-предка.

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

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

Рис. 7.1.

При построении STD-диаграммы рекомендуется следовать перечисленным ниже правилам:

• строить STD-диаграмму на как можно более высоком уровне детализации DFD-диаграммы;

• строить как можно более простые STD-диаграммы;

• по возможности детализировать STD-диаграммы;

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

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

1. Все ли состояния определены и имеют уникальное имя?

2. Все ли состояния достижимы?

3. Все ли состояния имеют выход?

4. Реагирует ли система (для каждого состояния) соответствующим образом на все возможные условия (особенно на ненормальные)?

5. Все ли входные (выходные) потоки управляющего процесса отражены в условиях (действиях) на STD-диаграмме?

В качестве примера рассмотрим диаграмму переходов состояний для системы управления лифтом (рис. 7.2). Для этого используем DFD-диаграммы этой системы.

Рис. 7.2.

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