43
подсистемой, классом). Актёры не могут быть связаны друг с
другом (за исключением отношений обобщения/наследования),
прецедент — эллипс с надписью, обозначающий выполняемые
системой действия (могут включать возможные варианты),
приводящие к наблюдаемым актёрами результатам. Надпись
может быть именем или описанием (с точки зрения актёров) того,
«что» делает система (а не «как»). Имя прецедента связано с
непрерываемым (атомарным) сценарием — конкретной
последовательностью действий, иллюстрирующей поведение
[15]. В ходе сценария актёры обмениваются с системой
сообщениями. Сценарий может быть приведён на диаграмме
прецедентов в виде UML-комментария. С одним прецедентом
может быть связано несколько различных сценариев [16].
Диаграммы использования (use-case) описывают отношения и
зависимости между группой вариантов использования и Актерами,
участвующими в этом процессе.
Важно заметить, что диаграммы вариантов использования не
подходят для представления дизайна и не могут описывать внутренности
системы. Диаграммы использования предназначены для облегчения связи с
будущими пользователями системы и с клиентом и особенно полезны для
определения необходимых функций, которые должна иметь система.
Диаграммы использования показывают, что система должна делать.
Случай использования
Вариант использования описывает - с точки зрения актеров - группу
действий в системе, которая создает конкретный, осязаемый результат.
Варианты использования - это описания типичных взаимодействий
между пользователями системы и самой системой. Они представляют
внешний интерфейс системы и определяют форму требований к системе.
При работе с вариантами использования важно помнить некоторые
44
простые правила:
Каждый вариант использования связан как минимум с одним актером.
У каждого варианта использования есть инициатор (т. е. Актер)
Каждый вариант использования приводит к соответствующему
результату.
Варианты использования также могут иметь отношения с другими
вариантами использования. Три наиболее типичных типа отношений между
случаями использования:
<< include >>, указывает, что вариарт использования имеет место
внутри другого варианта использования
<< extends >>, указывает, что в определенных ситуациях или в какой-
либо точке (называемой точкой расширения) вариант использования
будет расширен другим.
Обобщение указывает, что вариант использования наследует
характеристики «супер» -использования и может переопределять некоторые
из них или добавлять новые аналогично наследованию между классами.
Актер является внешним объектом (вне системы), который
взаимодействует с системой, участвуя (и часто инициируя) Вариант
использования. Актеры могут быть из реальной жизни (например,
пользователи системы), другие компьютерные системы или внешние
события.
Актеры не представляют физических людей или системы, а только их
роль. Это означает, что когда человек взаимодействует с системой по-
разному (принимая на себя разные роли), он будет представлен несколькими
участниками. Например, лицо, оказывающее поддержку клиентов по
телефону и принимающее заказы от клиента в системе, будет представлено
актером «Персоналом поддержки» и актером «Торговым представителем»,
Варианты использования описаны в текстовых описаниях. Обычно
они принимают форму примечания или документа, которые каким-то
45
образом связаны с вариантом использования, и объясняют процессы или
действия, которые происходят в варианте использования.
Основными действующими лицами проектируемой системы являются:
менеджер по приему автомобилей, мастер, руководитель СТО. Диаграмма
вариантов использования представлена на рис.3.5.
Рисунок 3.5 – Диаграмма вариантов использования
3.3 Разработка модели данных автоматизированной системы
Логическое моделирование связано со сбором бизнес-требований и
преобразованием этих требований в модель. Логическая модель основана на
потребностях бизнеса, а не на базе данных, хотя потребности бизнеса
используются для определения потребностей базы данных. Логическое
Менед жер
Вед ение реестра клиент ов
Вед ение реестра ТС
Оформление заказов клиентов
Поиск д анных
Авт оризация
Руковод итель
Формироват ь отчет по д иагностике
Формирование от четов по заказам
Формирование от четов по сот руд никам
Механик
46
моделирование включает сбор информации о бизнес-процессах, бизнес-
единицах (категориях данных) и организационных единицах. После
получения этой информации формируются диаграммы и отчеты, включая
диаграммы взаимосвязей сущностей, диаграммы бизнес-процессов и, в
конечном счете, диаграммы процессов. Полученные диаграммы должны
отражать существующие процессы и данные, а также отношения между
бизнес-процессами и данными. Логическое моделирование должно точно
визуально отображать действия и данные, относящиеся к конкретному
бизнесу.
Диаграммы и документация, сгенерированная в ходе логического
моделирования, используются для определения того, были ли полностью
собраны требования бизнеса. Руководство, разработчики и конечные
пользователи внимательно изучают эти диаграммы и документацию, чтобы
определить, требуется ли дополнительная работа до начала физического
моделирования.
Полная атрибутивная модель предполагает наиболее детальное
представление структуры проектируемой базы данных: представляет данные
в третьей нормальной форме и включает все сущности, атрибуты и связи.
Далее необходимо создать таблицы базы данных и установить связи
между ними.
Логические модели данных представляют собой абстрактную
структуру предметной области. Они часто носят схематический характер и
чаще всего используются в бизнес-процессах, которые стремятся охватить
важные для организации вещи и то, как они соотносятся друг с другом.
После утверждения и утверждения логическая модель данных может стать
основой для физической модели данных и сформировать структуру базы
данных.
Данные о сущностях и их определения разработанной модели данных,
отражены в таблице 3.3.
47
Таблица 3.3 – Сущности и их определения
Имя сущности
Определение
Клиент
Данные о клиенте
Автомобиль
Данные об автомобилях
Сотрудник
Данные о сотрудниках СТО
Акт приема
Данные о приемке автомобиля на диагностику
Заказ наряд
Данные о заказ-нарядах на диагностику
автомобиля
Дефектовка
Данные о проведенной диагностике и
выявленных дефектах
Дефекты
Данные о возможных дефектах
Узлы
Перечень узлов автомобиля
Данные о выявленных связях между сущностями, в результате
многоаспектного анализа предметной области, представлены в таблице 3.4 и
3.5.
Таблица 3.4 – Связи между сущностями: НИД/ИД
Родительская
сущность
Дочерняя
Сущность
Имя связи
Тип связи
КЛИЕНТ
АВТОМОБИЛЬ
ИМЕЕТ
НИД 1:М
АКТ ПРИЕМА
ЗАКАЗ НАРЯД
ФОРМИРУЕТСЯ
ИД 1:М
УЗЛЫ
ДЕФЕКТОВКА
СОДЕРЖИТ
НИД 1:М
ДЕФЕКТ
ДЕФЕКТОВКА
ВЫЯВЛЯЕТ
НИД 1:М
ДЕФЕКТОВКА
ЗАКАЗ НАРЯД
ВЫПОЛНЯЕТСЯ
ИД 1:М
Таблица 3.5 – Связи между сущностями: М:М
Родительская
сущность 1
Дочерняя
сущность
(имя связи)
Родительская
сущность
2
Тип
Связи
Автомобиль
АктПриема
Сотрудник
М:М
Модель на основе ключа (KB) - это модель данных, которая полностью
48
описывает все основные структуры данных, которые поддерживают
широкую сферу бизнеса. Целью модели KB является включение всех
объектов и атрибутов, которые представляют интерес для бизнес-процессов.
Как следует из названия, модель КБ включает в себя ключи. В
логической модели ключ идентифицирует уникальные экземпляры внутри
объекта. При реализации в физической модели ключ обеспечивает легкий
доступ к базовым данным.
В принципе, модель на основе ключа охватывает ту же область, что и
диаграмма отношений-сущность (ERD), но раскрывает больше деталей,
включая контекст, в котором могут быть построены подробные модели
уровня реализации.
Чтобы разработать правильную логическую модель данных,
необходимо однозначно идентифицировать каждый экземпляр в сущности.
В каждом объекте в модели данных горизонтальная линия разделяет
атрибуты на две группы, ключевые области и неключевые области. Область
над линией называется ключевой областью, а область под линией называется
областью данных.
Ключевая область содержит первичный ключ для объекта. Первичный
ключ - это набор атрибутов, используемых для идентификации уникальных
экземпляров объекта. Первичный ключ может состоять из одного или
нескольких атрибутов первичного ключа, если выбранные атрибуты
образуют уникальный идентификатор для каждого экземпляра в сущности.
Обычно объект имеет много неключевых атрибутов, которые
отображаются ниже горизонтальной линии. Атрибут без ключа не
однозначно идентифицирует экземпляр объекта. Например, база данных
может иметь несколько экземпляров одного и того же имени клиента, что
означает, что «имя клиента» не является уникальным и, вероятно, будет
несимвольным атрибутом.
Выбор первичного ключа
49
Выбор первичного ключа - важный шаг, требующий серьезного
рассмотрения. Прежде чем на самом деле выбрать первичный ключ, может
потребоваться рассмотреть несколько атрибутов, которые называются
атрибутами ключа-кандидата.
Правила, которые используются для выбора первичного ключа из
списка всех ключей-кандидатов, являются строгими и могут применяться
последовательно во всех типах баз данных и информации. В правилах
указано, что группа атрибутов или атрибутов должна:
Уникально идентифицировать экземпляр.
Никогда не включать значение NULL.
Не меняться со временем. Экземпляр берет свою уникальность из
ключа. Если ключ изменяется, это другой экземпляр.
После выбора первичного ключа из списка ключей-кандидатов
необходимо назначить некоторые или все оставшиеся ключи-кандидаты в
качестве альтернативных ключей. Альтернативные ключи часто
используются для идентификации разных индексов, которые используются
для быстрого доступа к данным. В модели данных альтернативный ключ
обозначается символом (AKn), где n - это число, которое помещается после
атрибутов, которые образуют альтернативную группу ключей.
В отличие от первичного ключа или альтернативного ключа, запись
инверсии является атрибутом или набором атрибутов, которые обычно
используются для доступа к сущности, но которые не могут привести к тому,
что вы найдете только один экземпляр объекта. В модели данных символ IEn
помещается после атрибута.
Атрибут может принадлежать альтернативной группе ключей, а также
группе ввода инверсии.
Внешний ключ - это набор атрибутов, которые определяют первичный
ключ в родительском объекте и переносятся через отношения от родителя к
дочернему объекту. В модели данных внешний ключ обозначается символом
50
(FK) после имени атрибута
По мере разработки модели данных можно обнаружить определенные
объекты, которые зависят от значения атрибута внешнего ключа
уникальности. Для этих объектов внешний ключ должен быть частью
первичного ключа дочернего объекта (над линией), чтобы однозначно
определять каждый объект.
В реляционных терминах дочерний объект, который зависит от
атрибута внешнего ключа для уникальности, называется зависимым
объектом. В обозначении IDEF1X зависимые объекты представляются в виде
прямоугольников с округлыми углами.
Объекты, которые не зависят от какого-либо другого объекта в модели
для идентификации, называются независимыми объектами.
Зависимые объекты далее классифицируются как зависимые от
существования, что означает, что зависимый объект не может существовать,
если его родитель не выполняет и не зависит от идентификации, что
означает, что зависимый объект не может быть идентифицирован без
использования ключа родителя.
Описание основных ключей для сущностей модели данных
представлено в таблице 3.6
Таблица 3.6 – Описание ключевых полей
Сущность
Атрибут
Тип данных
Тип ключа
КЛИЕНТ
кодКлиента
Числовой
Первичный
АВТОМОБИЛЬ
кодАвто
кодКлиента
Числовой
Числовой
Первичный
Внешний
СОТРУДНИК
кодСотрудника
Числовой
Первичный
АКТ ПРИЕМА
НомерАкта
кодАвто
кодСотрудника
Числовой
Числовой
Числовой
Первичный
Внешний
Внешний
ЗАКАЗ НАРЯД
номерНаряда
номерАкта
Числовой
Числовой
Первичный
Внешний
УЗЛЫ
кодУзла
Числовой
Первичный
51
ДЕФЕКТ
кодДефекта
Числовой
Первичный
ДЕФЕКТОВКА
кодДефектовки
номерНаряда
кодУзла
кодДефекта
Числовой
Числовой
Числовой
Числовой
Первичный
Внешний
Внешний
Внешний
На рисунке 3.6 представлена КВ – модель предметной области.
Рисунок 3.6 – KB – модель данных
Процесс проектирования базы данных включает в себя создание трех
типов схем - концептуальной, логической и физической. Структура базы
данных, документированная в этих схемах, преобразуется через язык
определения данных, который затем может быть использован для создания
базы данных. Полная атрибутивная модель (FA – fully attributed) данных
содержит подробные атрибуты (описания) для каждой сущности.
имеет
оформляет
оформляется по
Выполняется
формируется
выявляет
содержит
Автомобиль
#
o
кодАвто
типКузова
...
Integer
Text (100)
Сотрудник
#
o
кодСотрудника
Фамилия
...
Integer
Text (100)
Клиент
#
o
кодКлиента
ФИО
...
Integer
Text (150)
АктПриема
#
o
номерАкта
ДатаПриема
...
Integer
Date
ЗаказНаряд
#
o
номерНаряда
ДатаНачалаРабот
...
Integer
Date
Дефектовка
#
o
кодДефектовки
...
Integer
Text (200)
Дефект
#
o
кодДефекта
...
Integer
Text (100)
Узлы
#
o
кодУзла
...
Integer
Text (100)
52
Описание атрибутов сущностей базы данных представлено в таблице
3.7
Таблица 3.7 – Описание атрибутов сущностей базы данных
Сущность
Атрибут
Тип
данных
Длина
Обязательное
поле
Ключевое
Клиент
кодКлиента
Integer
Да
Да
ФИО
Text
(150)
150
Да
адрес
Text
(100)
100
Да
телефон
Text
(10)
10
Да
Сотрудник
кодСотрудника
Integer
Да
Да
Фамилия
Text
(100)
100
Да
Имя
Text
(100)
100
Да
Отчество
Text
(100)
100
Да
ТипСотрудника
Text
(100)
100
Да
Автомобиль
кодАвто
Integer
Да
Да
типКузова
Text
(100)
100
Да
Марка
Text
(100)
100
Да
Модель
Text
(100)
100
Да
регНомер
Text
(100)
100
Да
кодКлиента
Integer
Да
АктПриема
номерАкта
Integer
Да
Да
Жалобы
Text
(255)
255
Да
ДатаПриема
Date
8
Да
Примечание
Text
(255)
255
Да
кодАвто
Integer
Да
ЗаказНаряд
номерНаряда
Integer
Да
Да
номерАкта
Integer
Да
ДатаНачалаРабот
Date
8
Да
ДатаОкончанияРабот
Date
8
Да
Дефектовка
кодДефектовки
Integer
Да
Да
кодУзла
Integer
Да
кодДефекта
Integer
Да
состояние
Text
(255)
255
Да