Поскольку данные элементы рассматриваются с точки зрения Archimate начнем с определений.
Бизнес-объект — это понятие, используемое в конкретной области бизнеса.
В разделе 3.6 поясняется, что язык ArchiMate в целом ориентирован на описание типов, а не экземпляров, так как именно типы лучше всего подходят для описания архитектуры предприятия. Поэтому бизнес-объектом зачастую описывается тип объекта (ср. с диаграммой классов в UML). В реальности одной сущности будет соответствовать несколько экземпляров. Лишь изредка бизнес-объекты представляют собой конкретизированные информационные экземпляры, генерируемые и потребляемые элементами поведения, например, бизнес-процессами. Пример: одноэлементный класс, т. е. тип, который может иметь только один экземпляр
Объект данных — это данные, структурированные для автоматизированной обработки.
Объект данных должен быть автономным информационным элементом и должен иметь значение не только для слоя приложений, но и для бизнес-слоя. Примеры объектов данных: учетная запись клиента, база данных клиентов, страховая рекламация.
В разделе 3.6 поясняется, что язык ArchiMate в целом ориентирован на описание типов, а не экземпляров, так как именно типы лучше всего подходят для описания архитектуры предприятия. Поэтому объект данных обычно применяется для моделирования типа объекта (ср. с диаграммой классов в UML). В реальных приложениях одному объекту данных в модели (одному типу) может соответствовать несколько экземпляров этого объекта данных.
Важное исключение: объект данных можно использовать для описания типа, к которому принадлежит один единственный экземпляр. Пример такого типа — база данных (тип), которая существует на предприятии в единственном экземпляре.
Давайте разбираться.
Начнем с «Бизнес-объекта», строго говоря из определения вообще непонятно что это, из описания понятнее не становится)).
Для начала разбора определим, что в отношении Бизнес-объект/Объект данных, строго говоря бизнес-объект может не быть данными или информацией в любом виде, т.е. это более широкое понятие (в т.ч. предмет материального мира).
Давайте на примерах. Когда нам нужен абстрактный элемент (объект), то можно и нужно использовать бизнес-объект. Например, нам как компании для моделирования нужен объект «Договор», т.е. вообще любой независимо от его особенностей, формы представления, атрибутов, т.е. любой договор, то мы используем «Бизнес-объект». У этой абстракции тем не менее есть набор свойств/атрибутов, которые будут у любого экземпляра данного типа (номер, дата, стороны и т.п.).
Возможно на каком-то этапе нам потребуется выделить подтипы/подклассы договора, чтобы наделить их дополнительными свойствами:
- Дополнительное соглашение
- Спецификация
- Рамочный договор
- Разовый договор
Каждый из этих подтипов будет содержать дополнительные свойства, добавляющих к типу верхнего уровня новые характеристики.
Рис.1 «Пример модели Тип/Подтип (Класс/Подкласс)
На рис.1 приведена метамодель определяющая тип/класс «Договор» и дополнительно определены подтипы/подклассы договоров, которые связаны с дополнительными требования к свойствам.
Теперь рассмотрим элемент «Объект данных».
Исходя из определения в контексте примера должен существовать некий объект данных «Договор» в рамках некоей информационной системы.
Для простоты не будем погружаться в логику хранения данных и воспримем данный объект через призму пользовательского интерфейса «Форма договора» или в быту))) «карточка договора» в информационной системе.
Т.е. воспринимаемый нами информационный объект, содержащий некий набор атрибутов/полей с данными. Помимо этого, каким-то образом необходимо учесть в информационной системе специфику имеющихся подклассов (подтипов) договоров.
Для этого помимо карточки договора необходимо также иметь справочник подтипов(подклассов) - это еще один объект данных (справочник типов договоров) на стороне ИС.
Как результат анализа мы проектируем на стороне информационной системы набор объектов данных.
- Договор
- Тип договора
Связываем их связью, в договоре я могу выбрать тип договора (один ко многим).
И наконец формулируем требования, правила заполнения полей объекта «Договор» как для него в целом, так и для конкретного выбранного типа договора.
Рис.2. Связь бизнес-объектов с объектами данных информационной системы.
Наши рассуждения от абстрактного «Бизнес-слоя/Бизнес-объекты», корректно переходят в слой «Приложения/Данные» наш бизнес-объект появляется в информационной системе в виде объектов данных и требований к ним.
Завершим наши рассуждения привязкой предыдущей логики к любимым нами бизнес-процессам.
Допустим нам необходимо согласовать наш договор в нашей информационной системе и у нас есть flow движок (BPMS/Документооборот).
Рис.3 Модель процесса согласования договора.
Как видно из модели в зависимости от значения атрибута «Тип договора» в карточке договора маршрут согласования может изменяться, в согласовании принимают участие разные сотрудники.
Если подводить итоги по нашей короткой статье.
- Бизнес-объект – это не только данные и информация, т.е. это шире чем объект данных))).
- Бизнес-объект — это более/самое абстрактное представление данного типа структурного элемента по отношению к его реализации в реальной жизни.
Мы в нашей цепочке рассуждений от абстрактного понятия бизнес-объект и его классификации перешли не только к реализации этого элемента в виде данных в информационной системе, но и к корректной автоматизации бизнес-процесса с учетом всей вышеописанной логики, тем самым продемонстрировав и отличия логики применения элементов при моделировании и их связи для корректного проектирования решений
Возможно кому-то данная тема станет понятнее, а возможно, как раз наоборот возникнут новые вопросы)).