14. Концепции информационного моделирования.
Понятие атрибута. Типы атрибутов. Правила атрибутов. Понятие связи. Типы связей. Формализация связей. Композиция связей. Подтипы и супертипы. Диаграмма сущность-связь.
Какие документы создаются при объектно-ориентированном анализе:
Когда мы проводим анализ, мы формируем рабочие документы. Эти рабочие документы помогают нам проводить анализ, и эти рабочие документы мы в дальнейшем используем для разработки уже проектных документов, на основе которых мы выполняем этап эволюции.
Виды документов:
Для всей программы.
Для каждого домена.
Для каждой подсистемы.
Для каждого класса.
Для каждого состояния.
Для каждого действия.
Для всей программы:
Cхема доменов. Мы разбиваем задачу на домены.Проектная матрица(используется не только при проектировании, но и эволюции.) Она нам нужна, для того, чтобы четко оценивать, на какой стадии разработки нашего ПО мы находимся.
Для каждого домена
Если домен большой, то есть количество классов превышает цифру в районе 50 (или стоит опустить планку до 30), то такой домен мы разбиваем на подсистемы по минимуму связей.
Модель связей подсистем;Модель взаимодействия подсистем;Модель доступ к подсистемам;
Каждой подсистемы
Информационная модель(выделяем сущности, классы) С этой модели мы начинаем, собственно, проектировать. Разрабатывая информационную модель, мы выделяем:Описание классов и их атрибутов;Описание связей;
Модель взаимодействия объектов(диаграмма взаимодействий). Выделяя модель взаимодействия объектов, мы формируем список событий, которые происходят в нашей подсистеме:Список событий(в результате модели взаимодействий объектов);
Модель доступа к объектам;
Для каждого класса (сущности)
Модель состояний(ДПС - диаграмма переходов состояний); (Для каждого состояния.)Таблица процессов состояний(ТПС); (Для каждого состояния.)Диаграмма потоков данных действий(ДПДД); (для каждого действия)Описание процессов; (для каждого действия)
С чего начинать разработку?
Объектно-ориентированный подход - подход белого ящика. Мы идем от сущности, которая у нас реально существует, и из чего состоят эти сущности. Начинается всё с информационного моделирования. Понятно, что в начале мы разбили задачу на домены. Рассматриваем данном случае прикладной домен, грубо говоря, нашу задачу. Когда мы переходим к понятию подсистемы? Когда кол-во классов в прикладном домене становится критическим, и когда четко выделяются группы объектов, которые мы четко можем разбить на подсистемы. В любом случае, мы начинаем разработку прикладного домена с информационного моделирования.
Всегда разработка начинается с физических сущностей, которые существуют. Во есть задача, рассматривается задача на примерах с физическими сущностями. Пытаемся выделить характеристики этих объектов
Диаграмма сущность связь, сущности, связи.
Описание сущности
В диаграмме сущность-связь на информационной модели сущности располагаем в прямоугольнике.
Как описать сущность:
Каждой сущности мы присваиваем
уникальный номер. Он должен быть уникальным в нашем домене.Мы присваиваем
имя сущности. Нужно стремится, чтобы это было существительное... но это не всегда так.Ключевой литерал- для удобства работы, например, чтобы не расписывать полностью имя сущности, которое мы выделили.Атрибуты.Если это привилегированный идентификатор, атрибут который указывающий, мы его помечаем звездочкой. Все остальные атрибуты мы просто перечисляем.
Вот таким образом на информационной модели мы записываем нашу сущность.
Атрибуты
Мы начинаем всегда с физических объектов, которые реально существуют в нашей подсистеме. Мы смотрим, какие объекты у нас существуют и пытаемся эти объекты сгруппировать по принципу одних и тех же характеристик.
У нас есть объект. Мы выделяем, что характеризует этот объект. Естественно, это зависит от той задачи, которая нам требуется. Мы подходим не "что нам делать", а "чем характеризуется". Мы выделяем атрибуты объектов, характеристики. Любая характеристика, которая нас заинтересовала, абстрагируется как атрибут.
Атрибуты делятся на:
Идентифицирующие или указывающие. Идентификатор - набор из одного или нескольких атрибутов, которые четко идентифицируют объект. Атрибуты, которые мы объединили в понятии идентификатор, являются идентифицирующими. Еще их называют указывающими атрибутами.
Привилегированный идентификатор (начинается с
*)
Описательные. Любая характеристика объекта, которая его описывает. Например, студент. Средний балл. Это может быть описательной характеристикой? Нет. А вес, рост? Да.Вспомогательные. Мы их вводим для формализации связей и состояния (статус).
Для каждого атрибута мы смотрим, какие значения он может принимать, то есть определяем его множество значений. Это нужно для того, чтобы в дальнейшем понять, какого типа этот атрибут.
Все атрибуты могут менять и объект от это ни как не меняется, то есть поменялось имя, то объект остался прежним, или же вес, то тоже самое.
Все сводится в таблицу:
строка - объект,
столбец - атрибут.
Описание атрибутов
Каждый атрибут мы должны описать. Нужно четко понять, почему мы его выделили, и это описать.
Что из себя представляет описание атрибута? Это текст, из которого становится понятно, зачем нам нужен данный атрибут, почему мы его выделили, почему мы выделили данную характеристика.
Описание идентифицирующего атрибута
Мы должна описать форму указания (если она уместна), кто назначает указание и указать степень, в которой этот идентифицирующий атрибут используется, как идентификатор.
Среди всех идентифицирующих атрибутов мы выделяем привилегированный атрибут. Например, для студента, если имя и фамилия - идентифицирующие атрибуты, из них фамилия - привилегированный.
Описание описательного атрибута
Четко показываем, какую конкретную характеристику объекта сберегает этот атрибут. Так же показываем, как определяется этот атрибут, кто задает значение этого атрибута.
Описание вспомогательного атрибута
Надо делать описание только того атрибута, который формализует связь. В данном случае надо просто указать, какую связь формализует данный атрибут и почему мы так формализуем эту связь, а не по другому.
Изменение атрибутов
Мы четко должны понимать: изменение атрибута не приводит к изменению объекта. Объект остается таким же, тем же самым.
Если изменился указательный атрибут, то просто другое имя стало у того ж самого объекта. Была Иванова, а стала Петрова, но объект остался тот же самым.
Если изменился описательный атрибут, то это говорит о том, что какая-то характеристика изменилась. Например, изменился вес, но объект остался прежним.
Если изменяется вспомогательный атрибут, который формализует связь, то это говорит о том, что просто другие объекты участвуют в этой связи. Поменялись объекты участвующие в связи.
Правила атрибутов:
Для каждого атрибута мы формируем список значений, которые может принимать данный атрибут.
Мы выделяем правила атрибутов:
Для данного объекта каждый атрибут в любой момент времени должен иметь значение. Не может быть такого, чтобы какой-то атрибут не был определен. Это значение должно быть единственным. Если, когда мы выделили какую-то сущность, в ней появился объект, который мы отнесли к этой сущности, но у него, возможно, какой-то атрибут не определен - значит, объект относится к другой сущности.
Атрибут не должен содержать внутренней структуры. Он не должен быть для нас сложным. Это что-то простое, например: вес, рост и так далее.
Когда атрибут имеет составной идентификатор, каждый атрибут, который является частью идентификатора, представляет характеристику всего объекта, а не его части, ну и тем более не характеристику чего-либо другого. Например, для студента, ФИО - это всё характеристики самого объекта, самого студента, а не его части.
Если атрибут не является частью идентификатора, то он должен представлять характеристику данного объекта, указанного идентификатором, а не характеристику какого-либо другого атрибута. Это типичная ошибка - добавить атрибуты, которые характеризуют другие атрибуты или части объекта.
Связи между сущностями
Между сущностями существуют связи, и эту связь мы должны задать из перспективы каждого участвующего объекта. Связи могут быть разными.
Формализация связей - Мы должны формализовать связь. У нас есть связь, и кто-то за эту связь должен отвечать.
Сущность студент и сущность преподаватель. Между этими сущностями возникает связь. Преподаватель преподает студенту, студент учится у преподавателя
Пример Преподаватель-Студент
Типы связей по условности:
Безусловная связь.
Условная связь.
В определенных ситуациях объекты могут не участвовать в связи. Рассмотрим пример: преподаватель <--->> студент. У каждого студента должен быть руководитель, но у преподавателя может не быть студентов, которыми он руководит в данный момент. В этом случае мы со стороны объекта, который может не участвовать в связи, ставим буковку у - условная связь.
Биусловная связь.
Случай, когда с двух сторон объекты не участвуют в связи. Это редко, но возможно (когда оба носителя связи могут быть условными).
Типы связей по множественности:
1. Один к одному.
Например, муж <-----> жена. Хотя в некоторых других странах, например, арабских, у одного мужа может быть несколько жен... (муж - жена, безусловная связь (с одной и с другой стороны объект должен присутствовать)). Добавляем атрибут к одному из объектов, участвующих в связи (к тому, кто главнее, т.е. к мужу);
Как мы формализуем? Есть id мужа и id жены.
Мы добавляем вспомогательный атрибут к одному из участвующих из объектов. К кому? К тому, кто наиболее осведомлен. Кто главный, жена или муж? Пусть будет муж. Добавляем мужу id жены, и тут мы должны указать на связь. И для этого мы каждую связь помечаем идентификатором, и если это внутренняя связь, то она обозначается буквой R, потом идет номер связи, уникальный в каждом домене. Помечаем, что этот атрибут устанавливает эту связь.
Когда это безусловная связь, то на один из объектов накладывается условие жизни другого объекта. В истории, раньше, если умирал какой-то руководитель, царь, то его хоронили вместе с женой... идея понятна? Надо бы устранить недостаток, и не хоронить жену вместе с мужем. Умирает жена, как муж узнает об этом? Вот это является проблемой этой связи. Также держатель связи может поменять связь, а как быть с женой или же его жену кто-то другой нашел. Как эти проблемы решать? Вести ассоциативный объект.
Можем ли мы формализовать эту связь ассоциативным объектом? Нужен ли в связи мужа и жены посредник?
Если мы четко знаем, что у нас время жизни двух объектов полностью совпадают, тогда мы можем четко формализовать один к одному с помощью добавления вспомогательного атрибута к одному из объектов. Но если время время жизни объектов не совпадает, и нам важно во время выполнения программы чтобы объекты могли появляться/уничтожаться, в этом случае вышеописанным способом формализовать нельзя. В этом случае нам нужен объект, отвечающий за эту связь, посредник - ассоциативный объект. Он будет держать эту связь, и тогда у нас не возникнет проблем с жизненными циклами. Теперь и жена может стать вдовой, и муж вдовцом.
2. Один ко многим
Например, преподаватель <----->-> студент. У каждого студента на кафедре должен быть руководитель. Но у преподавателя может быть несколько студентов.
Примечание: Если нам не важен, кто главный, мы должны формализовать связь со стороны "многих".
С какой стороны формализовать эту связь? Вспомним второе правило атрибутов: атрибут не должен содержать внутренней структуры. По этой причине, когда связь у нас один ко многим, мы не можем ее формализовать со стороны одного, мы должны формализовать её со стороны многих.
В данном примере мы добавляем идентификатор преподавателя. Получается, студент главный!
Со стороны многих стоит объект рангом ниже, чем объект со стороны одного: он не может формализовать связь. В этом случае мы можем формализовать связь ассоциативным объектом. Но здесь мы формализуем (добавляем вспомогательный атрибут) со стороны зависимого объекта (студента), а главнее преподаватель, что плохо, как быть? Опять же вводим ассоциативный объект.
3. Многие ко многим
Например, учебный курс <-<----->-> студент. Один учебный курс могут прослушивать многие студенты. Один студент может прослушивать несколько учебных курсов.
Мы не можем формализовать связь ни с одной стороны, ни с другой. Для этого добавляют так называемый ассоциативный объект, задача которого - формализовать эту связь.
Пусть у каждого есть квартира, причем не одна. Более того - у одной квартиры может быть несколько собственников. Создадим ассоциативный объект - владение. Идентификатором владения является как id собственника, так и id квартиры. Этот ассоциативный объект, который формализует связь многие ко многим, кроме атрибутов, формализующих связь (если для обычного объекта это были вспомогательные атрибуты, то тут они являются идентифицирующими), может иметь дополнительные атрибуты: доля владения данной квартирой, дата приобретения и так далее.
Примечание про ассоциативную связь. С помощью ассоциативной связи мы реализуем связи многие ко многим и любую связь, которая имеет динамическое поведение, то есть может меняться во время работы программы. Связь может исчезать, объект может меняться с одной стороны... за это должен отвечать ассоциативный объект. Когда мы четко должны выстроить иерархию, кто главный, а кто нет - в этом случае главенство передается этому объекту.
Что нужно для связи
Идентификатор связи
Формулировка связи со стороны каждого участвующего объекта связи
Вид связи (один к одному, один ко многим, многие ко многим)
Формализация связи (или добавлением вспомогательного атрибута, или добавлением ассоциативного объекта)
Формулировка основания связи (зачем нам нужна эта связь)
Композиция связей
На информационной модели некоторые связи могут быть следствием других связей.
Есть связь студента с кафедрой, и есть связь студента с руководителем. Получились такие связи, когда кафедра может на студента через преподавателя и на прямую. Когда получилась такая связь, мы одну из связей формализуем как композицию других. Избыточностей связей не должно быть.
R3 = R1 + R2 - композиция других связей.
Надо выявлять такие связи на диаграмме, на их указывать, такие связи не надо формализовывать. Так уже существуют ассоциативные объекты между кафедрой и руководителем, и руководителем и студентом, то зачем нам еще ассоциативный объект между кафедрой и студентом - это лишнее.
Супер-классы
Супер-класс - абстрактное понятие на этапе информационного моделирования. Необходимо выделять общие атрибуты разным сущностям в супер-класс.
Возможно такая ситуация, когда объект мы отнесли к какому-то классу, но для него этого атрибута нет. Или мы отнесли два объекта к разным сущностям, разным классам, но они имеют общие атрибуты. В этом случае мы должны объединять эти классы так называемым суперклассом. Атрибуты, являющиеся общими для разных классов, нужно выносить в этот суперкласс, а все остальные атрибуты, которыми отличаются объекты, будут в подклассах.
Пример c Объектом
Last updated
