Разработка информационных систем (ИС) – это про создание средств управления информацией. ИС принимают информацию, по определенным правилам перерабатывают ее и отдают результат потребителям: на печать, на экран, в наушники, передают в другие системы.
Поэтому для того, чтобы создать качественную ИС, не достаточно понять бизнес-процессы и потребности Заказчика. Важно понимать, какой именно информацией система должна управлять. А для этого нужно знать, какие объекты попадают в предметную область проектируемой ИС и какие логические связи между ними существуют. Для формирования такого понимания используются логические модели предметной области.
Что иллюстрирует логическая модель
Целью построения логической модели является получение графического представления логической структуры исследуемой предметной области.
Логическая модель предметной области иллюстрирует сущности, а также их взаимоотношения между собой.
Сущности описывают объекты, являющиеся предметом деятельности предметной области, и субъекты, осуществляющие деятельность в рамках предметной области. Свойства объектов и субъектов реального мира описываются с помощью атрибутов.
Взаимоотношения между сущностями иллюстрируются с помощью связей. Правила и ограничения взаимоотношений описываются с помощью свойств связей. Обычно связи определяют либо зависимости между сущностями, либо влияние одной сущности на другую.
Пример: Заказ пиццы
Клиент оформляет заказ на приобретение пиццы. В общем случае клиент может заказать в разном количестве пиццы разных сортов. Поэтому каждый заказ включает позиции. Каждая позиция указывает сорт пиццы, которую клиент желает получить, а также ее количество.
Основные требования
Основные требования к содержанию модели
1. Логическая модель должна отображать все сущности и связи, значимые для той цели, ради которой мы ее рисуем.
2. Все объекты модели (и сущности, и связи) должны быть именованы. Именование сущностей и связей должно выполняться в терминах предметной области.
3. Для связей должна быть указана кратность (один — многие).
4. Для каждой связи должно быть указано направление чтения.
Пример: на модель добавлены наименования связей, их размерности и направление чтения.
5. Для сущностей должны быть указаны как минимум основные атрибуты.
Пример: для сущностей указаны основные атрибуты
Основные требования к качеству модели:
1. Модель должна читаться по схеме:
<Сущность 1> — <отношение / влияние> — <Сущность 2>.
Чтение ранее рассмотренного примера: Клиент оформляет заказ. Заказ включает в себя позиции, в каждой из которых указывается какого сорта пиццу и в каком количестве желает получить клиент.
Клиент может существовать без заказа. Однако заказ невозможно зарегистрировать без указания клиента. Один клиент может оформить неограниченное количество заказов
В соответствии с моделью в одном заказе может быть бесконечное количество позиций. Необходимо уточнить, на сколько это корректно.
2. Модель должна быть структурирована, сущности должны быть сгруппированы по логическому смыслу.
3. Крайне желательно избегать пересечения связей.
4. Расположение объектов модели должно быть таким, чтобы ее удобно было читать.
Есть одно наблюдение — если на модель смотреть приятно, то скорее всего она выполнена качественно.
Рекомендации по разработке
- Необходимо определить, зачем нам нужна логическая модель. На какие вопросы она должна нам в конце концов ответить? Почему она повлияет на качество выполнения анализа и как поможет решению поставленной перед нами задачи?
Без ответов на эти вопросы разработка модели теряет всякий смысл, поскольку мы будем делать что-то, от чего особо ничего не ожидаем. Соответствующим будет и результат.
Ответы на эти вопросы дают нам требования к модели, а в ходе разработки позволят принимать решения о ее развитии и судить о ее качестве.
- Необходимо определить границы моделирования — какую часть исследуемой предметной области модель должна охватить.
Как правило, ответ на этот вопрос вытекает из понимания стоящей перед бизнес-аналитиком задачи.
В большинстве случаев границы моделирования определяются либо исследуемыми бизнес-процессами, либо фрагментом информационного пространства компании, попадающим под решаемую задачу.
- Разработка логической модели должна начинаться в момент начала исследования предметной области и заканчиваться тогда, когда завершается выполнение задачи. Это едва ли не единственный артефакт, который разрабатывается на протяжении всего анализа предметной области и определения требований к системе.
Разработка логической модели – итеративный процесс. Она должна последовательно, по мере проработки предметной области и поставленной задачи, уточняться и детализироваться.
- В ходе анализа осуществляется выявление и отображение на модели сущностей и связей.
Логическую модель надо строить так, чтобы сущности назывались именами существительными, связи — глаголами, а чтение диаграммы рождало бы пусть и корявые, но предложения, описывающие то, что происходит в предметной области. Если этого удалось добиться, то модель вышла замечательная. Если не удалось такое, то разработчику модели еще есть над чем поработать.
- По мере проработки модели уточняется состав сущностей и связей, а также определяются атрибуты сущностей.
Заключение
Важно помнить, что логическая модель — это не про структуру базы данных, это про логическую структуру предметной области твоей задачи. Исключая ее из разрабатываемых атрибутов, ты лишаешь себя эффективного инструмента анализа и проектирования, позволяющего очень точно учесть аспекты бизнеса, не иллюстрируемые динамическими моделями.
И наоборот — своевременное и грамотное использование логической модели делает ее очень сильным инструментов в руках бизнес- или системного аналитика.
Автор:
Сергей Калинов
Ведущий бизнес-аналитик
EPAM Systems
Спасибо за статью, все очень круто, но хотелось бы понять некоторые штуки:
Раз есть подпункт \»время доставки\», хочется добавить \»адрес доставки\» в позицию \»клиент\». Как «позиция заказа» взаимосвязана с «Сорт пиццы» — Если «кол-во заказа — 6 шт″ — «Сорт пиццы: «1-ый, 2-ой» Какой сколько? Комментарии клиента могут повлиять на сорт пиццы, или изменение ее состава? Ну и \»сумма заказа\» — куда будет относиться и нужна ли она в описании этого процесса?
З.Ы. Вопросы для собственного понимания. Потому что его пока очень мало. ))
Александр,
Хочется добавить \»адрес доставки\» - да, стоит добавить. Но это будет не атрибут Клинета, а атрибут Заказа. Один и тот же клиент может заказывать пиццу на разные адреса.
Как «позиция заказа» взаимосвязана с «Сорт пиццы» — все верно — в позиции заказа указываем какой сорт пиццы заказал клиент и в каком количестве.
Комментарии клиента могут повлиять на сорт пиццы, или изменение ее состава? - комментарий относится к заказу. Это может быть что-то связанное с выполнением заказа — указанный адрес является офисным зданием, позвоните за 15 минут до приезда и т.п.
Сумма заказа — это вычисляемое значение, но его можно закрепить атрибутом сущности Заказ. Также в модели не хватает указания стоимости пиццы. По-хорошему у Позиции заказа должен быть атрибут «Стоимость».
Сергей спасибо,
статья в целом понравилась, НО:
1. не проработанная концепция (vision) данного примера не даёт достаточно полного представления о бизнесе. Поэтому возникает гораздо больше вопросов, чем ответов, которые можно получить из построенной диаграммы. Понятие сорт пиццы вносит путаницу — это действительно, какой-то сорт (1-й сорт, 2-й и т.д.) или её название? Я как-то привык выбирать по названию… Откуда клиент получит информацию о номенклатуре, стоимости, а часто и о весе пиццы? Есть ли тут такое понятие как прейскурант (меню)? Будет ли учитываться порядок заказов и следует ли контролировать их очерёдность, а также контролировать просроченные и выполненные заказы? На основании чего делается вывод о просроченном статусе заказа? И так далее…
2. Выявление связей между классами, с учётом их направления, непосредственно из предметной области без анализа взаимодействия объектов (sequence diagram, collaboration diagram) крайне сложная задача. Связи получаются неадекватными и неоднозначными. Если бы можно было бы так легко строить диаграммы классов, то тогда зачем нужны проектировщики? В представленной модели класс Клиент знает атрибуты класса Заказ, а последний (Заказ) вообще никакого представления об атрибутах Клиента не имеет! Здесь ассоциация должна быть двусторонняя. Скорее всего ошибка возникла из-за не удачно введённого названия этой ассоциации. В данной модели Клиент выступает в роли сущности, отвечающей за сохранность данных, а не в роли актёра, инициирующего функциональный сервис «оформление заказа».
Нельзя забывать, что логическая структура — это классы, а связи между ними, это вызов соответствующих операций этих классов. Не путайте сущности с актёрами! Сущность Клиент, которая на других диаграммах станет классом программной системы не будет обладать операцией «оформление заказа». Одно и то же понятие предметной области может выступать и в роли актёра (инициировать функционал, use case diagram), и в роли сущности (класса, отвечающего за данные, class diagram).
Остальные связи представленные в модели, тоже не выдерживают критики.
По поводу обязательности именования связей. Замечу, что они именуются, если данная связь не очевидна. Многие авторы склоняются к тому, что в логической модели сущностей предметной области главное не связи, а сами сущности и их атрибуты. Поэтому связи в них можно вообще не показывать за исключением агрегаций.
Все эти вопросы поднимаются и обсуждаются на предлагаемом мною online-тренинге http://www.webmax.by/vebinary/analiz_i_modelirovanie_v_up/
Ещё раз, коллега, спасибо за статью и поднятую в ней тему. Извините за критику, надеюсь, что она покажется полезной.
Николай, думаю в данном случае все немного проще. После сегодняшнего дня, так уж получилось, у меня появилась возможность взглянуть на статью по новому. В данном случае в виде примера служит вот этот конкретный текст:
Клиент оформляет заказ на приобретение пиццы. В общем случае клиент может заказать в разном количестве пиццы разных сортов. Поэтому каждый заказ включает позиции. Каждая позиция указывает сорт пиццы, которую клиент желает получить, а также ее количество.
Именно он проработан и выведен в виде логической модели предметной области. Мы можем много чего нафантазировать по поводу применяемых фич и усложнить пример до непонимания, но если следовать основной цели статьи, то данный пример объективно описывает логическую модель предметной области указанной в «дано».
З.Ы. Что бы не впасть в \»аналитический паралич\» хD
Александр, я рад, что в отличие от меня, исходный текст и модель не вызывает у вас вопросов. Но, все же, я позволил себе перефразировать vision с минимальными фантазиями и несколько изменить диаграмму, представленную автором статьи. Конечно, это тоже далеко не шедевр, она тоже вызывает вопросы, а эстетически смотрится хуже, но главное, в ней разделены субъект и класс, отвечающий за его данные. И ДОЛОЙ ПАРАЛИЧ (как физический, так и аналитический)!
Результат представлен по ссылке:
https://onedrive.live.com/redir?resid=8AE2948AA00D89BE!14069&authkey=!ACLVcWgY4rv0LoA&ithint=folder%2cdocx
Спасибо за статью! Мне как раз понравилось, что пример диаграммы в статье очень простой. Помогает передать смысл и не отпугивает сложностью :)
Диаграмму я эту очень люблю, однако, как вы писали, очень важно изобразить ее читабельно и разбочиво. Когда сущностей и объектов много, то она легко может превратиться в сложночитаемую паутину.
Еще одно часто встречающееся название такой диаграммы — доменная диаграмма.
По поводу «часто встречающегося названия»:
1. Яндекс выдает один результат по точному запросу — на ваш комментарий.
2. Гугл — 6, один из них на форум этого ресурса. Остальное скорее похоже на мусор.
Если попробовать искать английский вариант, то лучше не становится.
\»Когда сущностей и объектов много, то она легко может превратиться в сложночитаемую паутину.\»
Наталья, а не могли бы Вы мне подсказать, как по Вашему мнению, на диаграмме автора показаны только сущности, только объекты или и сущности, и объекты вместе? И, что всё же главное в этой диаграмме — «паутина» связей?
Сергей, спасибо за статью. Она хороша для тех, кто не догадывался подобным образом моделировать то, что в UML называется статической структурой системы. Важно
Ваша диаграмма очень похожа на диаграмму классов UML. В ассоциативных связях UML уже «встроены» понятия агрегации и композиции. Возможно, использование ромбиков вместо глаголов сделает диаграмму более читабельной. Кстати, почему именование связей строго обязательно? и почему диаграмма должна читаться предложениями описанным вами образом? Почему нельзя «человеческим языком» описать то, что изображено на диаграмме, а нужно обязательно подобными предложениями, на потенциальную «кривость» которых вы указали?
Замечу также, что множественность отношений встроена в «стрелочки» из crow’s foot notation. Использование кружков и палочек на концах отношений вместо текста вида [1..*] может визуально разгрузить диаграмму.
И последний вопрос. Кто сталкивался с ситуацией, когда участники проектной команды говорили, что БД рисует архитектор, поэтому аналитику не нужно рисовать такие диаграммы? Или что разработчики увидят две похожие диаграммы (эта и БД) и запутаются? Мне не раз приходилось убеждать таких людей в необходимости логической модели, часто мне это не удавалось. Приходилось партизанить: я рисовал диаграмму для себя (ночью, на конспиративной квартире), затем, глядя на неё, описывал всё остальное и саму диаграмму в итоге никому не показывал. У вас бывало такое? Как боролись?
Коллеги, предлагаю ту же диаграмму, но в стереотипах UML <<business entity>> и с немного подкорректированными связями. Со стереотипами получилось гораздо менее загружено https://onedrive.live.com/redir?resid=8AE2948AA00D89BE!14069&authkey=!ACLVcWgY4rv0LoA&ithint=folder%2cdocx
Только стереотип <<business worker>> отражается не так, как хотелось бы. На OneDrive диаграмма демонстрируется ужасно, т.к. шрифты становятся жирными, поэтому я поместил файлик для скачивания на дропбоксе по ссылке: https://www.dropbox.com/sh/ue03zrzn02fstyo/AADWQrF1Pmq7DEeTtO-0d4_Wa?dl=0
Как я ни старался улучшить восприятие через OneDrive, ничего не получилось — корёжатся и вордовские и pdf-файлы
Эта диаграмма показывает логическую структуру сущностей предметной области. Она по своей сути является диаграммой классов. Сущность предметной области отображает совокупность однотипных объектов в предметной области. Данная диаграмма в корне отличается от диаграммы логической структуры БД, т.к. её предназначение это моделирование предметной области и на ней могут быть показаны в том числе и те сущности, которые потом не найдут своего отражения в виде классов программы.
Начальная диаграмма логической структуры БД, основанная на классах, отражающих сущности предметной области, тоже может строится аналитиком и её вместо исходных текстов будет использовать проектировщик БД для построения полной архитектуры БД.
Самое тяжёлое в этих диаграммах это адекватное представление связей между сущностями. Для этого надо определять и направления связей, и один из четырёх возможных типов связей: ассоциация, агрегация (композиция), наследование и зависимость. Для этого надо анализировать последовательность посылки сообщений между объектами и рассматривать доступ к атрибутам. Часто доступ к атрибутам (public, private, protected, implementation) приходится учитывать для выбора связи. Если подходить к этому формально, то практически вся диаграмма будет состоять из одних агрегаций! Но это далеко не так.
Поэтому многие проектировщики против таких диаграмм и им легче разобраться в исходном тексте, чем в «паутине» лишних и неадекватных связей, представленных аналитиком.
Скорее всего не стоит в этих диаграммах делать упор на связях. Главное показать сами сущности, их атрибуты, а по последним обязательно расписать в документации будет ли этими данными оперировать прогр.система или они используются только в бизнесе, откуда данные в системе появятся, для чего нужны и как будут обрабатываться. Поэтому для демонстрации связей можно ограничиваться ассоциациями и тогда для пояснения смысла вводить их наименования там где это не очевидно. Но можно и вообще убрать связи с диаграммы.
Уведомление: Логическая модель предметной области | Блоги экспертов