> For the complete documentation index, see [llms.txt](https://frogs-organization-2.gitbook.io/oop.-sbornik./llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://frogs-organization-2.gitbook.io/oop.-sbornik./14.-koncepcii-informacionnogo-modelirovaniya..md).

# 14. Концепции информационного моделирования.

## Какие документы создаются при объектно-ориентированном анализе:

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

#### Виды документов:

1. Для всей программы.
2. Для каждого домена.
3. Для каждой подсистемы.
4. Для каждого класса.
5. Для каждого состояния.
6. Для каждого действия.

#### Для всей программы:

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

#### Для каждого домена

Если домен большой, то есть количество классов превышает цифру в районе 50 (или стоит опустить планку до 30), то такой домен мы разбиваем на подсистемы по минимуму связей.

* `Модель связей подсистем`;
* `Модель взаимодействия подсистем`;
* `Модель доступ к подсистемам`;

#### Каждой подсистемы

* `Информационная модель` (выделяем сущности, классы) С этой модели мы начинаем, собственно, проектировать. Разрабатывая информационную модель, мы выделяем:
  * `Описание классов и их атрибутов`;
  * `Описание связей`;
* `Модель взаимодействия объектов` (диаграмма взаимодействий). Выделяя модель взаимодействия объектов, мы формируем список событий, которые происходят в нашей подсистеме:
  * `Список событий` (в результате модели взаимодействий объектов);
* `Модель доступа к объектам`;

#### Для каждого класса (сущности)

* `Модель состояний` (ДПС - диаграмма переходов состояний); (Для каждого состояния.)
* `Таблица процессов состояний` (ТПС); (Для каждого состояния.)
* `Диаграмма потоков данных действий` (ДПДД); (для каждого действия)
* `Описание процессов`; (для каждого действия)

#### С чего начинать разработку?

Объектно-ориентированный подход - подход белого ящика. Мы идем от сущности, которая у нас реально существует, и из чего состоят эти сущности. Начинается всё с информационного моделирования. Понятно, что в начале мы разбили задачу на домены. Рассматриваем данном случае прикладной домен, грубо говоря, нашу задачу. Когда мы переходим к понятию подсистемы? Когда кол-во классов в прикладном домене становится критическим, и когда четко выделяются группы объектов, которые мы четко можем разбить на подсистемы. В любом случае, мы начинаем разработку прикладного домена с информационного моделирования.

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

## Диаграмма сущность связь, сущности, связи.

### Описание сущности

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

Как описать сущность:

* Каждой сущности мы присваиваем `уникальный номер`. Он должен быть уникальным в нашем домене.
* Мы присваиваем `имя сущности`. Нужно стремится, чтобы это было существительное... но это не всегда так.
* `Ключевой литерал` - для удобства работы, например, чтобы не расписывать полностью имя сущности, которое мы выделили.
* `Атрибуты.` Если это привилегированный идентификатор, атрибут который указывающий, мы его помечаем звездочкой. Все остальные атрибуты мы просто перечисляем.

![](https://user-images.githubusercontent.com/62243773/172060812-6e15d12b-88f0-478c-a167-a48e9e202245.png)

Вот таким образом на информационной модели мы записываем нашу сущность.

### Атрибуты

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

У нас есть объект. Мы выделяем, что характеризует этот объект. Естественно, это зависит от той задачи, которая нам требуется. Мы подходим не "что нам делать", а "чем характеризуется". Мы выделяем атрибуты объектов, характеристики. Любая характеристика, которая нас заинтересовала, абстрагируется как атрибут.

Атрибуты делятся на:

* `Идентифицирующие или указывающие`. Идентификатор - набор из одного или нескольких атрибутов, которые четко идентифицируют объект. Атрибуты, которые мы объединили в понятии идентификатор, являются идентифицирующими. Еще их называют указывающими атрибутами.

> Привилегированный идентификатор (начинается с `*`)

* `Описательные`. Любая характеристика объекта, которая его описывает. Например, студент. Средний балл. Это может быть описательной характеристикой? Нет. А вес, рост? Да.
* `Вспомогательные`. Мы их вводим для формализации связей и состояния (статус).

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

![](https://user-images.githubusercontent.com/62243773/172061400-7bd377f8-b23c-4ef5-867a-1b3868eb0c65.png)

Все атрибуты могут менять и объект от это ни как не меняется, то есть поменялось имя, то объект остался прежним, или же вес, то тоже самое.

Все сводится в таблицу:

* строка - объект,
* столбец - атрибут.

#### Описание атрибутов

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

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

#### Описание идентифицирующего атрибута

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

Среди всех идентифицирующих атрибутов мы выделяем привилегированный атрибут. Например, для студента, если имя и фамилия - идентифицирующие атрибуты, из них фамилия - привилегированный.

**Описание описательного атрибута**

Четко показываем, какую конкретную характеристику объекта сберегает этот атрибут. Так же показываем, как определяется этот атрибут, кто задает значение этого атрибута.

**Описание вспомогательного атрибута**

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

#### Изменение атрибутов

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

**Если изменился указательный атрибут**, то просто другое имя стало у того ж самого объекта. Была Иванова, а стала Петрова, но объект остался тот же самым.

**Если изменился описательный атрибут**, то это говорит о том, что какая-то характеристика изменилась. Например, изменился вес, но объект остался прежним.

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

#### Правила атрибутов:

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

Мы выделяем правила атрибутов:

* Для данного объекта каждый атрибут в любой момент времени должен иметь значение. Не может быть такого, чтобы какой-то атрибут не был определен. Это значение должно быть единственным. Если, когда мы выделили какую-то сущность, в ней появился объект, который мы отнесли к этой сущности, но у него, возможно, какой-то атрибут не определен - значит, объект относится к другой сущности.
* Атрибут не должен содержать внутренней структуры. Он не должен быть для нас сложным. Это что-то простое, например: вес, рост и так далее.
* Когда атрибут имеет составной идентификатор, каждый атрибут, который является частью идентификатора, представляет характеристику всего объекта, а не его части, ну и тем более не характеристику чего-либо другого. Например, для студента, ФИО - это всё характеристики самого объекта, самого студента, а не его части.
* Если атрибут не является частью идентификатора, то он должен представлять характеристику данного объекта, указанного идентификатором, а не характеристику какого-либо другого атрибута. Это типичная ошибка - добавить атрибуты, которые характеризуют другие атрибуты или части объекта.

### Связи между сущностями

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

> Формализация связей - Мы должны формализовать связь. У нас есть связь, и кто-то за эту связь должен отвечать.

Сущность студент и сущность преподаватель. Между этими сущностями возникает связь. Преподаватель преподает студенту, студент учится у преподавателя

#### Пример Преподаватель-Студент

![](https://user-images.githubusercontent.com/62243773/172062184-5e07c459-d649-415b-a152-6225b20f4d39.png)

#### Типы связей по условности:

* Безусловная связь.
* Условная связь.

В определенных ситуациях объекты могут не участвовать в связи. Рассмотрим пример: преподаватель <--->> студент. У каждого студента должен быть руководитель, но у преподавателя может не быть студентов, которыми он руководит в данный момент. В этом случае мы со стороны объекта, который может не участвовать в связи, ставим буковку у - условная связь.

* Биусловная связь.

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

#### Типы связей по множественности:

**1. Один к одному.**

Например, муж <-----> жена. Хотя в некоторых других странах, например, арабских, у одного мужа может быть несколько жен... (муж - жена, безусловная связь (с одной и с другой стороны объект должен присутствовать)). Добавляем атрибут к одному из объектов, участвующих в связи (к тому, кто главнее, т.е. к мужу);

![](https://user-images.githubusercontent.com/62243773/172062483-d2728d90-3bab-42df-a75e-dc48256bbed6.png)

Как мы формализуем? Есть id мужа и id жены.

Мы добавляем вспомогательный атрибут к одному из участвующих из объектов. К кому? К тому, кто наиболее осведомлен. Кто главный, жена или муж? Пусть будет муж. Добавляем мужу id жены, и тут мы должны указать на связь. И для этого мы каждую связь помечаем идентификатором, и если это внутренняя связь, то она обозначается буквой R, потом идет номер связи, уникальный в каждом домене. Помечаем, что этот атрибут устанавливает эту связь.

Когда это безусловная связь, то на один из объектов накладывается условие жизни другого объекта. В истории, раньше, если умирал какой-то руководитель, царь, то его хоронили вместе с женой... идея понятна? Надо бы устранить недостаток, и не хоронить жену вместе с мужем. Умирает жена, как муж узнает об этом? Вот это является проблемой этой связи. Также держатель связи может поменять связь, а как быть с женой или же его жену кто-то другой нашел. Как эти проблемы решать? Вести ассоциативный объект.

Можем ли мы формализовать эту связь ассоциативным объектом? Нужен ли в связи мужа и жены посредник?

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

**2. Один ко многим**

Например, преподаватель <----->-> студент. У каждого студента на кафедре должен быть руководитель. Но у преподавателя может быть несколько студентов.

> Примечание: Если нам не важен, кто главный, мы должны формализовать связь со стороны "многих".

![](https://user-images.githubusercontent.com/62243773/172062722-a6ae6139-8efa-408b-ab20-e0d1eeb118e4.png)

С какой стороны формализовать эту связь? Вспомним второе правило атрибутов: атрибут не должен содержать внутренней структуры. По этой причине, когда связь у нас один ко многим, мы не можем ее формализовать со стороны одного, мы должны формализовать её со стороны многих.

В данном примере мы добавляем идентификатор преподавателя. Получается, студент главный!

Со стороны многих стоит объект рангом ниже, чем объект со стороны одного: он не может формализовать связь. В этом случае мы можем формализовать связь ассоциативным объектом. Но здесь мы формализуем (добавляем вспомогательный атрибут) со стороны зависимого объекта (студента), а главнее преподаватель, что плохо, как быть? Опять же вводим ассоциативный объект.

**3. Многие ко многим**

Например, учебный курс <-<----->-> студент. Один учебный курс могут прослушивать многие студенты. Один студент может прослушивать несколько учебных курсов.

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

![](https://user-images.githubusercontent.com/62243773/172063246-caf96ab8-a24d-4b8b-992d-8da38d9c9630.png)

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

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

#### Что нужно для связи

* Идентификатор связи
* Формулировка связи со стороны каждого участвующего объекта связи
* Вид связи (один к одному, один ко многим, многие ко многим)
* Формализация связи (или добавлением вспомогательного атрибута, или добавлением ассоциативного объекта)
* Формулировка основания связи (зачем нам нужна эта связь)

#### Композиция связей

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

![image](https://user-images.githubusercontent.com/62243773/172064597-820095ca-c5bb-4420-b540-01152cfd64fd.png)

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

R3 = R1 + R2 - композиция других связей.

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

#### Супер-классы

Супер-класс - абстрактное понятие на этапе информационного моделирования. Необходимо выделять общие атрибуты разным сущностям в супер-класс.

Возможно такая ситуация, когда объект мы отнесли к какому-то классу, но для него этого атрибута нет. Или мы отнесли два объекта к разным сущностям, разным классам, но они имеют общие атрибуты. В этом случае мы должны объединять эти классы так называемым суперклассом. Атрибуты, являющиеся общими для разных классов, нужно выносить в этот суперкласс, а все остальные атрибуты, которыми отличаются объекты, будут в подклассах.

**Пример c Объектом**

![](https://user-images.githubusercontent.com/62243773/172065434-95dbbb44-95a3-4f28-b2e1-57c52679a574.png)