Армен Базиян, ведущий бизнес-архитектор и аналитик компании AnalyticsHub, к.ф.-м.н.
Коротко
В данной статье изложены принципы разработки объектной модели при проектировании ИТ-систем, а также рассмотрены некоторые приёмы проектирования, улучшающие качество модели.
О разбиении мира на объекты
Прежде чем перейти к описанию приёмов проектирования проведём экскурс в общие принципы проектирования ИТ-моделей. Для этого вспомним ER-диаграмму (ERD) [1] - как основу описания мира языком ИТ. ERD содержит в себе ключевую информацию модели автоматизации – объекты, их свойства и связи между объектами. Несмотря на свою простоту, ERD представляет собой удивительную по своей глубине интерпретацию окружающего мира. Каждый из элементов ERD заслуживает отдельного рассмотрения:
Каждая из составляющих ERD является продуктом человеческого мышления и осознания окружающего мира. Объект - это не есть некий факт, но продукт восприятия. Рассмотрим этот феномен подробнее:
Объекты
Умение выделять объекты из окружающего мира является субъективной способностью человека (да и не только). Человек классифицирует («нарезает») окружающий мир на объекты, исходя из своего субъективного представления о нём (думая при этом, что его восприятие объективно).
Приведу пример:
Как вы думаете, что это такое?
Варианты ответа будут рознится, в зависимости от того, каков размер человека, по сравнению с данным объектом. Ниже представлены варианты ответов:
Иными словами, один и тот же объект, с точки зрения формализации его описания, в зависимости от своих параметров (размера) называется по-разному, т.е. классифицируется человеком как разные объекты.
Или противоположный пример:
Все представленное многообразие, различное с точки зрения ИТ-описания, человеком классифицируется как один объект – стол, в соответствии с его функциональным назначением.
Приведённые примеры показывают субъективизм человека при классификации объектов. Проектировщик ИТ-системы может формировать объекты, как ему вздумается с целью оптимизации работы системы. Скажем, объект в первом примере он может назвать «перекрытие на четырех ножках» или, короче, «четвероног»[2]. И новый термин укрепится в сознании людей, которые будут работать с такой системой.
Также интересно отметить, что социализация, образование, обучение человека направлены на то, чтобы вложить в его голову общепринятый набор объектов, используемых в обществе или профессиональном сообществе. Это позволяет человеку быть социальным существом, т.е. правильно формулировать свои мысли понятным для других образом. Например, математический термин «производная» понятен всем, кто имеет начальное математическое образование, а термин «флюксия» непонятен, хотя означает то же, что и производная[3]. Именно единый набор объектов является основой для коммуникаций людей.
Названиям объектов нас учат с самого детства, закладывая в голову соответствие между явлениями и их названиями. В голове каждого заложен как набор общеупотребимых объектов, так и собственных, индивидуальных, никому не понятных, рождённых им в течение жизни с использованием личного опыта. На личных объектах иногда формируются решения, которые тоже непонятны окружающим 🙂
Свойства объектов
Свойство или атрибут объекта – это некая его характеристика. Но всякая характеристика сама по себе также является объектом и может в свою очередь иметь набор свойств/атрибутов. Вообще, деление на объекты и их атрибуты является субъективным и зависит от задачи.
Например, объект «Погода» имеет атрибут «Температура воздуха». Но если объектом исследования является «Температура воздуха», то именно она становится объектом, который обрастает атрибутами «Давление», «Влажность», «Время года» и т.п. Атрибут – это особенный вид связи объектов друг с другом, при котором объект-атрибут классифицируется как свойство описываемого объекта. Само понятие атрибута – субъективно и применимо в совокупности с задачей, которую решает моделирование.
Связи между объектами
Видов связей между объектами превеликое множество. Приведём несколько примеров связей:
Вообще, по аналогии с правилом «5-ти рукопожатий» любые два объекта можно поставить в отношение друг с другом через связи с другими объектами. Эта бесконечная связанность всего со всем является фундаментальной в человеческом восприятии мира и более подробно описана в работе «О стратегии развития человечества в новом мире искусственного интеллекта».
Сейчас лишь отметим, что всё многообразие связей между объектами в ERD уложено в одно понятие связи. Т.е. просто «имеют связь друг с другом». При этом характер связи никак не уточняется (предполагается, что за границами системы всем понятно, каков тип этой связи). И эта универсальность позволяет описывать весь мир в простой модели сущность-связь.
Вся эта преамбула сделана для того, чтобы показать широту уровня свободы проектировщика при создании ИТ-систем.
Общая информация
Теперь перейдем к формализации понятий.
Определение ИТ-системы
Определений ИТ-систем много, и все они имеют очень общий характер, и потому мало понятны простому обывателю (в качестве примера отсылаю к Википедии).
Здесь и далее понятие ИТ-системы мы будем трактовать узко, с точки зрения её проектировщика, а именно: это модель из объектов (и их атрибутов), связанных друг с другом информационными потоками (т.е. правилами изменения атрибутов объектов при изменении других атрибутов, которые с ними связаны). При этом эффективность модели информационной системы оценивается уровнем оптимизации движения информации (чем быстрее информация от точки, где она появилась, достигает точки, в которой она нужна, тем более удачно спроектирована система).
Как следствие, получаем 4 части системы:
(Тоже мудрено получилось 🙂)
Каждый участник бизнес-процесса, человек, который принимает в нём участие, является источником и потребителем информации. Он получает информацию (как потребитель), на основании которой принимает решение или производит действия, а потом вносит результаты решения или действий в систему (как источник). Чем больше данных для принятия решения имеет участник бизнес-процесса, тем лучше спроектирована система. В идеале она должна быть спроектирована настолько хорошо, чтобы все действия и все решения осуществляла сама 🙂
Границы системы
Исходя из сказанного, нужно сначала определить, для кого и для чего создаётся система, определить её назначение и границы применимости, т.е. обозначить так называемый scope ИТ-проекта.
И уже с этого момента начинается творчество.
Приведу яркий пример из опыта. В проекте автоматизации компании, которая занимается укладкой асфальта, для расчёта сроков и стоимости работ существенным фактором оказывается погода в период проведения работ. Включение погодных условий в модель является необходимостью, которая может быть реализована несколькими способами:
Из приведённого примера мы видим, что в систему можно втянуть вообще все объекты мира, т.к. все зависит от всего. И иногда это просто необходимо, чтобы модель отражала реальность и была применимой. (Ярким примером является рассказ Рея Бредбери «И грянул гром», когда маленькая мёртвая бабочка влияет решающим образом на будущее мироздания). Но такие системы обычно не становятся объектами автоматизации, т.к. остаются на анализ человеку, а автоматизируют системы с очерченными границами и обычно предполагаемыми процессами.
Не меньше свободы при выборе лиц, участников бизнес-процесса. Это просто показать на таком примере: может ли современная, скажем, складская ИТ-система быть эффективной без автоматизации бухгалтерского учёта? Ответ – нет. Отдельно стоящая система потребует двойного ввода и учёта данных, что вызовет недовольство у сотрудников и клиентов (помню, в одной логистической компании данные по выданному при въезде пропуску трижды вбивали в систему до момента выдачи заказа). Уровень автоматизации предприятия должен наращиваться комплексно. Нередки случаи, когда автоматизация частной задачи приводит к необходимости пересмотра многих процессов предприятия. И увеличение границ проекта в части включения в него смежных бизнес-процессов вполне объяснимо. Впрочем, возможно и обратное, когда автоматизацию нарезают на мелкие, более-менее независимые блоки, называемые микросервисами. Но это уже вопросы архитектуры автоматизации. Пока оставим их в стороне.
О зрелости постановки задачи на автоматизацию
Данный раздел раскрывает простое утверждение о том, что «хаос нельзя автоматизировать».
Для постановки задачи как минимум нужно понять цели автоматизации, источники и потребителей информации, таких, которые «не поплывут» при проработке требований. И уровень рисков в этой части пропорционален уровню инновационности системы. Созданная «с чистого листа» система имеет риски не прижиться на существующих людях или процессах. Поэтому лучше сначала «обкатать» бизнес-процесс в виде прототипа «на коленках», и только потом его автоматизировать.
Некоторые приёмы проектирования ИТ-систем
Сложность и гибкость системы
Как было ранее описано в примерах со столом, проектировщик системы волен сам выбирать объекты учёта. Он может подниматься вверх на уровень все новых обобщений с целью создания универсальной системы-конструктора, которая применима вообще к любой задаче автоматизации (и такие системы есть. Например, 1С умело балансирует между готовыми решениями и возможностью их кастомизации). Или, напротив, может сознательно каждый объект учёта оставлять как уникальный без обобщений, т.к. понимает, что со временем в учёте данные объекты разойдутся в атрибутном составе.
Является очевидным тот факт, что чем больше возможностей имеет система, тем больше настроек надо сделать, чтобы она функционировала определённым образом. То есть уровень сложности системы растет с ростом количества её возможностей. У многофункциональных систем проект по настройке системы под конкретный бизнес сравним по трудоёмкости с написанием системы «с нуля» под конкретные требования заказчика (зато многофункциональные системы легче продавать: «А это система умеет делать? – Да!» 🙂). И уровень квалификации персонала в «навороченных» системах должен быть существенно выше, чем у простых и понятных. Поэтому на рынке рядом живут ERP-системы, настраиваемые под клиента, и системы, которые разрабатываются на заказ «с нуля». Система должна балансировать между вариативностью настроек и статичностью своих возможностей, реализуя оптимальный уровень сложности. Об этом более подробно описано в предыдущей работе автора «Модель будущего при проектировании ИТ-систем».
От общего описания подходов к проектированию перейдем к конкретным приёмам, которые помогают в создании модели. Данная информация больше адресована проектировщикам, но может быть интересна и тем, кто интересуется моделированием.
Классический приём определения объектов системы
Напомним классический способ определения объектов системы и их атрибутов.
Необходимо выписать из сценария использования системы все существительные. Это и есть кандидаты на поля таблиц в системе. Но если с атрибутами можно разобраться более-менее однозначно, то в группировке их в объекты есть вариативность. О том, как выбрать ключевые объекты читайте в следующем разделе.
Приём Ядро-Контент
Разберём подбор объектов на примере. У любой компании есть клиенты, и объект «Клиенты» в системе почти очевиден.
Однако, если у компании есть поставщики, то имеет смысл рассмотреть объединение объектов «Клиенты» и «Поставщики» в одном объекте «Контрагенты», в котором клиенты и поставщики будут храниться единообразно и отличаться только одним признаком – типом контрагента. Такой подход может оказаться «прозорливым» в случае, если в компании могут появиться новые типы контрагентов, например – оптовые клиенты, рекламное агентство, аудиторская компания и т.п. В этом случае для учёта достаточно будет завести новый тип контрагента, ограничившись настройкой системы, в отличие от первого случая, где придётся создавать новые объекты, и существенно дорабатывать систему (доработка БД, новые формы ввода данных, формы выбора типа контрагента, новая логика внутри других блоков системы и т.п.).
Объединение клиентов и поставщиков в системе открывает новые возможности по унификации работы с ними в бизнесе. Так, например, если в компании работают отдельно подразделение продаж и подразделение закупок, то система откроет возможность компании создать унифицированный процесс работы с контрагентами (например, по их обзвону через CRM) и объединить подразделения закупок и продаж воедино. (Об этой возможности можно заявить, подтолкнув компанию к оптимизации расходов, а можно дождаться, когда бизнес сам о ней спросит).
И наоборот, в случае, когда процессы работы с клиентами и поставщиками имеют много специфического, и эта специфичность обусловлена самой сутью бизнеса, объединение объектов приведет к необходимости создания подчинённых объектов и росту сложности системы.
Суть выше описанного приёма состоит в том, чтобы последовательно перебирать возможные объекты системы, восходя по уровню общности от одного объекта к другому и реализовать в модели ровно тот, который останется неизменным при дальнейшем развитии бизнеса. Попросту говоря, осуществлять синтез полученной информации и материализовывать её в максимально общих объектах.
Хороший проектировщик системы – это тот, кто глубоко знает автоматизируемый бизнес; это человек, который понимает, куда бизнес «может гнуться», а куда – нет. Задача хорошего проектировщика – сделать так, чтобы система «гнулась» в тех же местах, что и бизнес и была жесткой там же, где он не будет меняться. И тогда проектировщик ИТ-системы становится проектировщиком бизнеса.
Для того, чтобы понять специфику бизнеса неискушенному аналитику придётся задавать заказчику много вопросов, которые, могут даже вызвать удивление или расширить его собственное понимание своего бизнеса (при соответствующей квалификации аналитика).
Приведем гипотетический пример проектирования колесной системы автомобиля:
Вопросы проектировщика постановщику задачи:
Вопросы, отражающие глобальное представление проектировщика системы о бизнесе, заданные в частных примерах, позволяют проверить корректность выбранной концепции.
Приведу пример из опыта. Для контроля состояния сети продаж бизнес в течение продолжительного времени собирал информацию о значениях двух ключевых параметров рынка. Поэтому в ИТ-системе, которая собирала эти параметры, для каждого из них было заведено отдельное поле в базе данных. Однако, со временем, появился еще один параметр, включение которого в систему потребовало существенной доработки системы (добавления нового поля в базу данных, доработки всех форм ввода и вывода показателей). При появлении еще одного нового показателя в системе пришло осознание того, что показатели являются контентом, а не объектами. Поэтому была изменена архитектура системы и создана сущность «Показатели», в которую были включены все существующие показатели. С этого момента добавление показателей в систему не требовало никаких доработок (а их потом было немало).
Вместо заключения
Резюмируя вышесказанное, чем глубже проектировщик знает предметную область, которую он автоматизирует, тем более точную модель он создаст. При моделировании он правильно выберет объекты и смоделирует связи.
© 1929 Жорж Брак. «Круглый стол».
[1] ER – entity-relation диаграмма, которая показывает набор объектов, их атрибуты и связи между объектами. Ключевая диаграмма, описывающая структуру базы данных.
[2] И здесь интересно отметить, что единое понятие «нога» применяется к таким различным объектам как нога человека, ножка стола, ножка насекомого.
[3] Просто Ньютону в этой части повезло меньше, чем Лейбницу, интерпретация дифференциального исчисления которого оказалась более понятной окружающим, чем ньютоновская теория.