Концептуальное моделирование предметной области.

План:

1. модель «сущность-связь» Питера Чена
2. диаграмма классов уровня анализа UML.

Модель «Сущность-связь».

Её называют ERD-моделью. Эта модель базируется на 3 понятиях: сущность, атрибут, связь. Сущность – реальный или абстрактный объект, информация о котором должна сохраняться и быть доступной. Это бизнес-понятие и бизнес-событие предметной области. Необходимо различать тип и экземпляр сущности. Тип сущности относится к набору однородных объектов, а экземпляр – к конкретному. Например, тип – студент, экземпляр – Иванов. Моделирование БД ведется на уровне типов. Сущности обозначаются прямоугольниками. Атрибут – любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Атрибуты используются для определения того, какая информация о сущности должна быть собрана в системе. Один или несколько атрибутов обязательно однозначно идентифицируют экземпляр сущности. Это ключ. Все экземпляры сущности должны различаться. Атрибуты обозначаются кружочками. Связь – графически изображенная ассоциация, установленная между двумя сущностями. Изображается ромбом. Существует 4 типа связи:

• Один к одному (1:1). Одному экземпляру первой сущности соответствует один или ноль экземпляров другой сущности.
• Один ко многим (1:М). Одному экземпляру первой сущности соответствует ноль, один или несколько экземпляров второй сущности.
• Многие к одному (М:1). Ноль, один или несколько экземпляров первой сущности соответствует одному экземпляру второй сущности.
• Многие ко многим (М:N). Ноль, один или несколько экземпляров одной сущности связаны с нулем, одним или несколькими экземплярами второй сущности.

Приведем пример ER-модели в нотации Питера Чена.

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

Модель Питера Чена слабо формализована. В настоящее время применяются более развитые нотации, которые положены в основу CASE-средств автоматизированного проектирования ПО. CASE-средства – графический редактор, поддерживающий одну или несколько нотаций информационного моделирования, поддерживает целостность и на выходе получает программный код, соответствующий модели на выбранном ЯПВУ.

Диаграммы классов уровня анализа языка UML.

В январе 1997 года три теоретика объектно-ориентированного моделирования Г. Буч, Джим Рамбо, Айвар Якобсон объединились в компании Rational Software и разработали нотации языка объектно-ориентированного моделирования UML.

Процесс разработки ПО включает 4 стадии:

1. анализ требований к автоматизированной системе.
2. объектно-ориентированный анализ предметной области.
3. ОО проектирование системы.
4. реализация.

Подо все эти стадии существуют соответствующие диаграммы, а сам язык UML предназначен для визуального моделирования, проектирования и документирования программных систем. Разработка концептуальной модели предметной области выполняется в рамках 2 этапов: анализ требований и ОО анализ предметной области. Анализ требований визуализируется посредством 2 диаграмм: Use Case Diagram (диаграмма вариантов использования (ВИ) системы), Activity Diagram (диаграмма деятельности). Первая диаграмма отражает варианты использования системы и взаимодействующие с ними актеры, то есть отражает предназначение системы, а вторая отображает логику каждого ВИ. Процесс разработки АИС начинается с анализа требований, результатом которого является Use Case диаграмма. Она состоит из актеров – это роль объекта вне системы, напрямую взаимодействующей с ней (менеджер, работник склада), ВИ – это последовательность выполняемых системой действий, которая приводит к видимому, значимому для актера результату. Актер и ВИ связываются посредством связей: ассоциация (прямая линия), расширение – включение добавочного поведения в ВИ (штрихпунктирная линия), включение – включение добавочного обязательного поведения в ВИ, обобщение – отношение между общим и специфичным. Правила: не моделировать связи между актерами; не соединять связью два ВИ, кроме случаев связи включения и расширения; порядок выполнения ВИ не отражается в диаграмме; каждый ВИ должен быть инициирован актером; БД – это слой под диаграммой и потоки информации не отражаются на диаграмме; каждый актер может взаимодействовать с определенным набором ВИ.

Рассмотрим для примера фрагмент диаграммы ВИ тестовой информационной системы «склад деталей».

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

Отдельно разрабатывается концептуальная модель предметной области, и этот процесс начинается с выявления основных концептуальных объектов, которые встречаются в системе (основные бизнес-понятия и бизнес-события в системе). Необходимо стремиться, чтобы эти объекты лежали в основе системы и удовлетворяли посредством своего атрибутивного набора описанным ВИ создаваемой системы. Концептуальная модель – это декомпозиция предметной области. Требования к системе сменяются быстрее, чем реальный мир, и задача проектировщика АИС – удовлетворить потребности заказчика на основе концептов предметной области. Основной составляющей ОО анализа в UML является разработка диаграммы классов, которая определяет типы объектов системы и различного рода связи между ними.

В UML существует 3 различные диаграммы классов:

1. концептуальная модель предметной области (модель анализа)
2. модель спецификации классов (модель проектирования)
3. модель реализации.

Концептуальная модель – это модель анализа.

Класс – это совокупность объектов с общими атрибутами, операциями, отношениями и семантиками. Изображается в виде прямоугольника, разделенного на 3 части: имя класса, атрибуты, методы.

Отношение определяет ассоциации между классами: зависимость – это семантическое отношение между двум сущностями, при котором изменение одной влечет изменение другой (штрихпунктирная линия со стрелкой), ассоциация – структурное отношение, описывающее совокупность связей (прямая, на которой показывается степень связи (сколько экземпляров связано), обязательность (для всех экземпляров она должна быть), имя связи)). Варианты степеней: n – много, 0..0, 0..1, 0..n, 1..1, 1..n. Разновидностью ассоциации является агрегирование – отношение «часть-целое». Около целого рисуется ромб, а у частей прямые. Если ромб закрашен, то поддерживается каскадное удаление (удаление целого влечет удаление всех частей). Обобщение – отношение «подтип-супертип» (стрелка). Реализация – связь между интерфейсами и реализующими классами (штрихпунктирная линия со стрелкой).

Рассмотрим концептуальную модель «склад деталей».

Количество

Строка отпуска

Склад

Примечание:

1. деталь сделана из конкретного материала. Эта идея использования справочника материалов. Связь М:1
2. может не быть деталей, сделанных из какого-то материала (0..n)
3. деталь лежит на конкретном складе, много деталей связаны с конкретным складом, склад может быть пуст. Склад – справочник для детали. Справочник всегда связан отношением «многие к одному»
4. во время поставки поставляется одна деталь конкретным поставщиком, но во время поставки обязательно должны быть и поставщик и деталь
5. поставщик находится в одном конкретном городе. Город – это справочник для поставщиков, могут быть города, где нет поставщиков.
6. накапливается историчность регистрационных сведений поставщика, у него может меняться адрес, название и др. Атрибуты юридического лица: название, юридический адрес, ИНН, ОГРН, организационно-правовая форма, ФИО руководителя, телефон
7. за 1 отпуск можно поставить (отпустить) несколько видов деталей. Строка отпуска – часть целого отпуска. Должна быть хотя бы 1 запись строки
8. клиент может быть юридическим лицом или частным предпринимателем (ИП). Рационально поддерживать 2 отдельных справочника со своим реквизитом. Клиент – супер-тип двух подтипов: юридическое лицо и ИП. Во время отпуска связь поддерживается с 1 клиентом, при этом поставляется несколько видом деталей.

Принцип создания концептуальной модели:

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

o Типы актеров (люди, организации).

o Актеры (роли, участники).

o Физические объекты (реальные вещи).

o Дескриптивные вещи (спецификации описания).

o Транзакции (события, процессы).

o Элементы транзакций (строка заказов, поставки).

o Места, контейнеры (магазин, склад).

В настоящее время есть готовые шаблоны концептуальных моделей предметных областей.

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