Дерево детализации функций

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

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

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

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

Рассматривая сквозной пример «Электронный магазин» на начальном этапе разработки, выделим продукты/услуги:

• • товар — основной продукт, реализуемый магазином, где процесс его создания предполагает закупку и продажу:
  • — электроника;
  • — СD, DVD и Вlu-Rау диски;
  • — бытовая техника;
• • доставка товара — дополнительная услуга, предоставляемая магазином для своих клиентов;
• • консультирование — информационная услуга, обеспечивающая информирование клиента об особенностях продаваемых в магазине товаров.

В зависимости от глубины рассмотрения предметной области состав продуктов и услуг может быть значительно большим, а также, учитывая, что отдельные товары могут обладать отличительными особенностями, как в части описания, так и по технологии продажи, то они могут быть разделены на виды товаров, представляясь отдельными продуктами. При рассмотрении производственных систем в качестве продуктов (рис. 2.4) могут быть отдельные комплектующие и составные части производимого продукта, если они должны быть реализованы в качестве самостоятельного продукта.

Рис. 2.4. Дерево продуктов/услуг.

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

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

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

Рис. 2.5. Дерево основных информационных объектов.

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

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

Любой информационный объект предметной области в реальной жизни, как правило, представляется материальным объектом, если рассматривается производство материального продукта. Однако, в случае, когда в предметной области формируется нематериальный продукт (например, «Совещание», «Расписание» и т. д.) или оказывается услуга, то информационные объекты будут зачастую представляться нематериальными элементами. Когда же речь идет о вспомогательных информационных объектах, то они очень часто представляются нематериальными объектами предметной области (например, «Дисциплина», «Класс опасности», «Статус студента» и т. д.).

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

Так, для рассматриваемого примера основным продуктом выделен «Товары», но он, будучи также информационным объектом, является составной частью нематериального объекта «Заказ», который представляется более важным элементом с точки зрения реализации бизнес-процесса, поскольку клиенты для приобретения товаров реализует эту функцию не для каждого товара в отдельности, а для совокупности товаров, образующих объект «Заказ». Этот объект будет являться информационной характеристикой материального объекта «Товары» и, фактически, станет основным элементом при рассмотрении бизнес-процесса. В результате моделирования бизнес-процессов был сформулирован бизнес-процесс «Управление реализацией товаров» (рис. 2.6), предполагающий, в информационном плане, формирование и реализацию заказов, получаемых из совокупности товаров как информационных объектов.

Рис. 2.в. Бизнес-процесс «Управление реализацией товаров» .

Как очевидно из бизнес-процесса, для реализации поставленной задачи необходимо выполнить три под процесса (функции): «Заказ товара», «Сбор заказа» и «Реализация товара». Каждый из подпроцессов реализует задачу обработки данных об одном основном объекте предметной области. Как правило, ключевым (основным) объектом является тот объект, который получается в результате выполнения функции. Таким образом, для первого подпроцесса ключевым объектом будет «Товары» в состоянии «Заказанные товары», для второго подпроцесса — объект «Товары» в состоянии «Товары для доставки», а для третьего подпроцесса — объект «Товары» в состоянии «Доставленные товары» .

Материальный объект «Товары» в процессе реализации деятельности изменяет свое состояние, что отражено в бизнес-процессе, и по мере этих изменений наполняется рядом информационных параметров. К таким информационным объектам в начале бизнес-процесса относится «Потребность в товарах», который начинает определять ту совокупность товаров, которые должны быть приобретены клиентом (покупателем) и преобразоваться в информационный объект «Заказ». Этот объект можно рассматривать одним из основных информационных объектов, определяющим все необходимые характеристики для реализации товаров клиенту (покупателю). По окончании выполнения бизнес-процесса информационным объектом, характеризующим доставленные товары, является реализованный заказ, включающий в себя не только сам заказ, но некоторые другие характеристики.

В итоге контекстного рассмотрения предметной области дерево функций будет представлено, как показано на рис. 2.7.

Рис. 2.7. Дерево функций контекстного уровня.

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

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

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

Рис. 2.8. Окружение функции «Управление реализацией товаров» .

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

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

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

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

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

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

Однако, в некоторых случаях возникает сложная ситуация в определении типа информационного элемента. Например, строка адреса «127 083, г. Москва, у л. Верхняя Масловка, д. 21, кв. 2» может представляться простым типом, а может — структурным элементом. Возникает вопрос: «Как определить, какой из вариантов стоит рассматривать?» Конечно, все зависит от потребностей обработки данных в базе данных. В случае, когда адрес является все лишь неделимой характеристикой объекта и в процессе работы с ним нет необходимости выделять ни дом, ни улицу, ни город, ни индекс, то данные сведения будут описываться простым атрибутов — текстовая строка. Но в случае когда в процессе работы с информационной системой, например, необходимо будет выбрать товары, доставляемые в город Москву, то возникает необходимость характеризовать адрес доставки структурным элементом, выделяя в качестве отдельного атрибута характеристику «Город» .

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

Понимание и умение выделить структурные элементы и простые атрибуты позволяют разработчику минимизировать процессы нормализации базы данных уже на начальном этапе разработки.

Так, в рассматриваемом примере информационный объект «Реализованный товар» описан рядом характеристик, которые позволяют охарактеризовать его ключевые свойства. Определение этих характеристик основывается не только и не столько на умозаключениях разработчика, сколько на анализе документов (электронных и печатных), которые участвуют в реализации рассматриваемой функции. Например, характеристика «Клиент» выделена из документа «Товарный чек», где отражены сведения о покупателе товаров. Название атрибута определяется терминологией предметной области и должно давать исчерпывающую информацию об указанном информационном объекте. Стоит обратить внимание на то, что при описании характеристик реализуемого заказа характеристика «Клиент» не была рассмотрена на уровне простых атрибутов. Конечно, документ дает представление об атрибутивном составе данного информационного объекта, но для реализованного заказа не имеет значения состав характеристик, которыми будет описываться клиент. Важно, что объект «Клиент» всем его атрибутивным составом должен присутствовать в объекте «Реализованный заказ» и описывать физическое или юридическое лицо, приобретшее указанные в документе «Товарный чек» товары.

В результате рассмотрения объекта предметной области «Потребность в товарах» разработчиком были выделены атрибуты: «Категория товара», «Характеристики товара», «Ценовой диапазон». Поскольку интервальный тип данных предусмотрен не во всех СУБД, то стоит задуматься над использованием атрибута «Ценовой диапазон» и определиться с его применением в базе данных. Возможно, стоит это атрибут разделить па два простых атрибута — «Начальная цена» и «Конечная цена», что в рассматриваемом примере и будет сделано.

Используя инструментарий описания бизнес-элементов в IBM WebSphere Business Modeler, определим атрибутивную структуру объекта «Потребность в товарах» (рис. 2.9).

Потребность в товарах.

Рис. 2.9. Базовое атрибутивное описание объекта «Потребность в товарах» .

Как очевидно из примера, два последних атрибута: «Начальная цена» и «Конечная цена» , — описываются типом «Целое», т. е. целочисленным типом данных, поскольку значения этих атрибутов определяют денежную характеристику, но не требуют высокой точности, что позволяет ограничиться для удобства работы с данными именно целочисленными типами данных.

Сложнее дело обстоит с двумя другими атрибутами, поскольку они не представляются простым элементом и их описание типом «Текст» не является абсолютно логичным. Тем не менее, для атрибута «Категория товара» (рис. 2.10), если изначально неизвестно, что это будет фиксированный набором значений справочник (классификатор) или его значение будет вводиться вручную пользователем информационной системы с клавиатуры, то использование такого типа данных может быть оправданным. Однако, в данном случае, такое объяснение не является логичным, поскольку список категорий товара для магазина является всегда ограниченным набором фиксированных значений и его корректировка выполняется достаточно редко, то его можно рассматривать в качестве классификатора, и это приводит к необходимости определения данного атрибута бизнес-элементом в модели бизнес-процессов.

Рис. 2.10. Атрибутивное описание объекта «Потребность в товарах» .

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

С атрибутом «Характеристики товара» ситуация более сложная, поскольку он предполагает рассмотрение множества различных характеристик, которыми может описываться товар, и анализ предметной области показывает, что для каждой категории товара перечень этих характеристик может быть различным, что не позволяет этот атрибут описать конкретным объектом предметной области. В связи этим оставим пока данный атрибут с типом данных «Текст» как наиболее подходящим для его описания, но вернемся к его рассмотрению позже, когда будем изучать категоризацию в моделировании и универсальные конструкции, которыми такой атрибут целесообразно рассматривать.

Со вторым информационным объектом ситуация намного проще, поскольку этот элемент также представляется материальным документом, обладающим фиксированным набором атрибутов. Выделяя атрибуты информационного объекта, важно начать выделять все мелкие атрибуты, которые не имеют прямого отношения к рассматриваемому объекту^[1]. Чтобы не создавать большого количества атрибутов, стоит уже на данном этапе рассматривать атрибутивный состав объекта в укрупненном варианте (рис. 2.11).

Рис. 2.11. Атрибутивное описание объекта «Реализованный товар» .

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

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

Рассмотрим аналогичным образом декомпозиционную функцию «Заказ товара» (рис. 2.12), которая рассматривает процесс преобразования потребности клиента в заказ. При том, что на уровне моделирования бизнес-процессов мы можем рассматривать потоки в материальном и в информационном плане, нужно учитывать, что информационное представление есть не что иное, как описание структуры материального или информационного объекта. В интересах дальнейшего построения базы данных рассмотрение бизнес-процессов целесообразно только с информационной точки зрения.

В рассматриваемом для моделирования бизнес-процессов программном средстве IBM WebSphere Business Modeler компонент моделирования «Бизнес-элемент» является тем самым информационным объектом, который дает возможность спланировать информационную структуру бизнесдеятельности (процесса) и представить структуры данных. Однако стоит учитывать, что при переносе структур данных из IBM WebSphere Business Modeler в IBM InfoSphere Data Architect атрибуты бизнес-элементов могут быть преобразованы в сущности модели базы данных^[2]. Это объясняется тем, что бизнес-элементом в моделировании бизнес-процессов представляется информационный объект предметной области, группирующий внутри себя комплекс информационных структур, формирующих хранилище данных^[3] как совокупность информационных объектов.

Рис. 2.12. Процесс «Заказ товара» .

При рассмотрении подпроцесса «Заказ товара» выделяется три функции: «Представление каталога товаров», «Наполнение корзины товаров» и «Формирование заказа». Этот процесс интересен тем, что он включает в себя три разных тина функций. Один тин функций представляется функцией «Представление каталога товаров». Эта функция относится к функциям, реализующим информационную обработку, и ее дальнейшее рассмотрение должно вестись в рамках построения диаграммы потоков данных.

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

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

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

Третий тип функции представляется операцией формирования и публикации документа «Заказ товара», с одновременным фиксированием факта завершения формирования информационного объекта «Заказ» .

Но вернемся на уровень выше к рассмотрению функции подпроцесса «Заказ товара», окружение которой может быть представлено в виде схемы, показанной на рис. 2.13.

Рис. 2.13. Окружение функции «Заказ товара» .

Построение окружения функции в части определения декомпозиционных функций возможно только после ее декомпозиции в рамках моделирования бизнес-процессов, что и было проведено ранее. В результате моделирования окружения функции были выделены два информационных объекта, три входящих документа и один выходящий документ (табл. 2.2).

Таблица 2.2.

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

Другим информационным объектом для функции «Заказ товара» является результат выполнения функции, представляемый документом «Заказ» (рис. 2.14) и соответствующим бизнес-элементом.

Рис. 2.14. Форма документа «Заказ» .

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

Поскольку в современной разработке баз данных мы используем не только документ в качестве источника информации об информационных объектах, но и сведения, получаемые при моделировании бизнес-процессов с выделением бизнес-элементов, соответствующих информационным объектам, то уже на этом этапе можно выделить некоторые атрибуты, которые не имеют непосредственного отношения к заказу, но участвуют в описании информационных объектов, которые рассматриваются атрибутами заказа. Так, рассматривая документ «Заказ», можно выделить ряд атрибутов (табл. 2.3).

Разбирая указанные в документе атрибуты, несложно увидеть, что есть атрибут, который не имеет отношения ни к заказу, ни к товарам, указываемым в заказе. Этим атрибутом является «№ п/п». Его смысл ограничен таблицей списка заказываемых товаров, всегда в каждом документе «Заказ» начинается со значения «1». Это позволяет сказать, что такой атрибут не должен рассматриваться в процессе разработки базы данных и будет учтен только при разработке отчетных форм по информационным потребностям (запросам) пользователей.

Атрибут «Клиент» нам известен по предыдущему рассмотрению предметной области. Этот атрибут ранее рассматривался в качестве бизнесэлемента. Возникает вопрос: «Являются ли атрибут „Клиент“ и бизнесэлемент „Клиент“ одним и тем же?» Отвечая на данный вопрос, нужно определиться со смыслом атрибута и бизнес-элемента. Атрибут «Клиент» представляет собой характеризацию человека, который оформляет заказ и которому это заказ будет доставлен. Учитывая, что человеком, приобретающим товар, что определено смыслом бизнес-элемента «Клиент», является человек, который будет товар получать, а точнее, которому будет доставляться товар, получаем, что смыслы атрибута и бизнес-элемента идентичны. Поэтому в описании бизнес-элемента «Заказ», который соответствует документу «Заказ», атрибут «Клиент» (рис. 2.15) должен быть связан с бизнес-элементом «Клиент» .

Рис. 2.15. Добавление атрибута «Клиент» в бизнес-элемент «Заказ» .

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

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

Рис. 2.16. Добавление сведений об организации в бизнес-элемент «Заказ» .

Атрибуты «Артикул», «Наименование товара», «Цена» имеют отношение к товару, и из их описания это очевидно. Поэтому данные атрибуты стоит объединить под одним элементом «Товар», который в бизнес-процессах будет представляться бизнес-элементом.

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

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

Первым атрибутом для товаров заказа является объект «Заказ». Это достаточно просто объяснить. Если посмотреть на документ «Заказ», то несложно увидеть необходимость указания большого количества товаров в рамках единого заказа, что говорит о том, что сам заказ, а именно его атрибуты, характеризуют заказываемые клиентом (покупателем) товары.

Именно поэтому атрибут «Заказ», связанный с объектом «Заказ», появился в объекте «Товары заказа» (рис. 2.17). К тому же, его наличие еще подтверждается самим названием объекта — «Товары заказа» .

Рис. 2.17. Добавление атрибутов по товару в бизнес-элемент «Товары заказа» .

Стоит взглянуть на атрибут «Сумма» по строкам таблицы заказываемых товаров. Этот атрибут является вычисляемым, форму которого предполагает перемножение значений атрибутов «Количество» и «Цена». Здесь нужно задуматься о возможностях реализации данной операции в СУБД. Конечно, ее можно реализовать, когда пользователь самостоятельно укажет значение или его вычислит приложение. Но в СУБД имеются возможности реализации вычисляемых полей. Учитывая эту особенность в момент моделирования базы данных и ее реализации, стоит задуматься о том, как будет выполняться данное вычисление. Текущее представление не позволяет использовать возможности СУБД, поскольку атрибуты «Количество» и «Цена» размещены в разных бизнес-элементах и в модели базы данных будут находиться в разных сущностях (таблицах), что по правилам работы с вычисляемыми полями в СУБД недопустимо. Правила СУБД предполагают, что для реализации технологии вычисляемого значения для поля таблицы нужно, чтобы все используемые в вычислении поля находились в той же таблице, что и вычисляемое поле.

Исходя из сказанного выше, данное поле пока сохраним в составе атрибутов бизнес-элемента «Заказ», но запомним, что вычисление его значения необходимо рассмотреть отдельно в процессе моделирования базы данных и ее реализации в СУБД.

Остался последний атрибут, который еще не был рассмотрен, «Общая сумма». Этот атрибут имеет отношение к заказу клиента в целом и предполагает вычисление стоимости заказа по всем заказанным товарам. Использование атрибута будет основываться на уточнении его смысла. Если он предполагает отражение только суммарной стоимости для отчета, то в бизнес-элемент включать данный атрибут не стоит, поскольку реализация запросов, но формированию соответствующего документа позволит получить нужное значение. Если значение этого атрибута нужно для последующего применения в хранилище данных, чтобы не выполнять постоянные вычисления его значения, загружая ресурсы СУБД, то его можно включить в состав атрибутов бизнес-элемента «Товары заказа» .

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

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

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

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

Рис. 2.18. Декомпозиция бизнес-процесса «Заказ товара» .

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

Дерево зависимости функций Декомпозиция бизнес-процесса позволила выделить основные бизнесфункции, которые реализуются в предметной области, где происходят обработки и представление данных относительного ключевого бизнесобъекта (продукта/услуги). Рассматривая атрибутивный состав бизнесобъекта (продукта/услуги), в бизнес-процессе выделяют информационные объекты и характеристики, которые представляют информационные потоки в бизнес-функциях, что позволяет при дальнейшем рассмотрении определиться со вспомогательными информационными объектами, обеспечивающими качественную и полноценную обработку данных о бизнес-объекте (продукте/услуге).

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

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

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

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

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

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

Рассмотрим бизнес-функцию «Представление каталога товаров» (рис. 2.19). Эта функция не подлежит дальнейшей декомпозиции, поскольку любое ее выполнение никаким образом нс изменит состояние продукта «Товар», а только уточнит процесс выполнения. Поэтому дальнейшее представление этой функции в виде бизнес-функции нецелесообразно, а необходимо определить потоки данных, которые позволят сформировать ее реализацию.

Чтобы определиться с потоками данных бизнес-функции, сначала нужно сформировать входящий и выходящий информационные потоки. В этом случае на модели бизнес-процесса добавляем входящий поток «Потребность в товарах», который уже был сформирован ранее. Также в качестве выходного потока добавляем «Каталог товаров», который одновременно является входящим потоком для функции «Наполнение корзины товарами» .

Бизнес-элемент «Каталог товаров» в предметной области для электронного магазина может не быть представленным материальным документом, но его электронная версия может представляться документом «Прайслист» (рис. 2.20) с указанием списка товаров, сгруппированного по категориям, ценам и минимальной спецификации.

Товары (объект) (Заказанные товары]. Рис. 2.19. Добавление информационных потоков для функции «Представление каталога товаров» .

Рис. 2.20. Пример формы документа «Прайс-лист» .

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

Наибольший интерес для текущего рассмотрения представляет таблица со списком товаров. Ее структура позволяет определиться с набором атрибутов каждого товара. Все атрибуты, указанные в таблице, поскольку ключевым элементом документа является товар, относятся именно к товару, а не к какому-либо другому информационному объекту. В нашей исходной структуре информационного объекта «Товар» были указаны атрибуты «Артикул», «Наименование» и «Цена» (см. рис. 2.20). В процессе анализа текущего документа выявляется, что товары должны еще характеризоваться атрибутом «Спецификация», который будет описывать детальные особенности каждого товара. Этот атрибут должен найти отражение в соответствующем бизнес-элементе «Товар», который должен представляться основным атрибутом информационного объекта «Каталог товаров» .

Также, в документе наблюдается группировка товаров по категориям. Здесь стоит остановиться на двух особенностях этой характеристики документа: особенности представления категорий товаров и отношение категории к товару.

С точки зрения представления состава категорий товаров, следует, что в документе категории товаров выстроены в иерархическую (древовидную) структуру. Проанализировав в предметной области полный перечень категорий товаров, можно сделать вывод о точной структуре, которая может быть представлена деревом или сетью, что наложит определенные ограничения на структурирование объекта и процедуры его обработки в базе данных. Предположим, что состав категорий товаров представляется древовидной структурой типа «Дерево», а это значит, что каждый элемент более низкого уровня должен ссылаться на элемент предыдущего уровня. Именно эту особенность и нужно отразить в составе информационного объекта «Категория товаров» (рис. 2.21).

Рис. 2.21. Пример структуры информационного объекта «Категория товаров» .

В этой структуре видно, что категория товаров является классификатором наименований, сгруппированных в иерархию (дерево), что реализуется атрибутом «Родитель категории», который своим значением должен ссылаться на категорию предыдущего уровня. Естественно, что для категории первого уровня родительского элемента нет, и данный атрибут должен предполагать отсутствие какого-либо значения.

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

Рис. 2.22. Атрибутивный состав информационного объекта «Каталог товаров» .

Определяя атрибутивный состав этого информационного объекта, мы основываемся на возможных структурах документов «Прайс-лист» или «Каталог товаров». Они могут дать детальное представление о возможном представлении каталога товаров, что и было проведено в процессе формирования атрибутивного состава информационных объектов «Каталог товаров», «Товар» и «Категория товаров» .

Процесс преобразования потребностей клиента в каталог товаров (рис. 2.23) является функцией детализации и рассматривает задачи, но работе с данными. В связи с этим основными элементами, которые необходимо анализировать, являются структуры и потоки данных. Именно эго понимание процесса требует от разработчика введения в модель процесса таких элементов, как «Хранилище», где будут показываться элементы данных, необходимые для работы соответствующей задачи.

В результате детализации в модели бизнес-процесса выделяются новые функции (задачи), которые не меняют качество продукта/услуги, т. е. являются вспомогательными, но при этом являются объективно необходимыми для выполнения бизнес-процесса. Эти функции (задачи) формируют единицу процесса в работе пользователя с информационной системой для формирования необходимых информационных сведений с целью реализации основного бизнес-процесса (рис. 2.24).

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

вспомогательная функция (задача) должна отражать комплекс операций для достижения поставленной цели;

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

Рис. 2.23. Процесс формирования каталога товаров.

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

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

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

Рис. 2.24. Детализация функции «Представление каталога товаров» .

Учитывая соответствующие особенности работы пользователя с информационной системой и практически невозможное правильное и точное указание наименования категории товаров в текстовом виде, используемых в магазине, разработчик должен определить способ работы с информационным объектом «Категория товаров», когда необходимо выбрать определенные категории для последующего использования в информационных потребностях пользователя. Таким образом, мы понимаем, что для представления категорий товаров на экране пользователя в удобном для работы виде необходимо иметь справочник (классификатор) категорий товаров, а анализ структуры документа «Прайс-лист» требует представления этого справочника (классификатора) в иерархическом (древовидном) виде.

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

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

Вспомогательные процессы не относятся к бизнес-процессам предметной области, поскольку не формируют нового качества конечного продукта/услуги, но они объективно необходимы для эффективной работы с данными, и их первоочередная реализация формирует окружение вспомогательной функции бизнес-процесса. Аналогично термину «Вспомогательный процесс» в рамках дерева функций такие процессы обозначаются термином «Вспомогательная функция» (рис. 2.25).

Рис. 2.25. Отражение вспомогательной функции.

Выделив вспомогательную функцию «Ведение справочника категорий товаров», разработчик определяет его структурное наполнение. В рассматриваемом примере мы ранее уже определили эту структуру (см. рис. 2.21). Эта структура, учитывая особенность представления соответствующих данных, содержит атрибут «Родитель категории», который позволяет связать все категории в иерархическую структуру.

В другой функции рассматриваемого дерева «Формирование списка доступных товаров» набор вспомогательных процессов будет немного больше, поскольку для корректной обработки данных необходимо нс только обладать сведениями о товарах, но также об их распределении по категориям магазина, что отражено в структуре данных «Каталог товаров» (см. рис. 2.22). Поэтому в дереве функций появится вспомогательная функции «Ведение справочника товаров», а уровнем ниже — «Ведение справочника категорий товаров», иллюстрируя, что при ведении состава имеющихся на складе товаров необходимо обладать справочником категорий товаров.

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

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

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

Рис. 2.26. Детализация и уточнение функции «Формирование списка доступных товаров» .

Определение выполняемых операций важно для понимания действий, которые возможны при работе с соответствующим информационным объектом. Например, при работе с каталогом товаров отсутствует операция, но удалению товаров. Эго определяется на основе анализа предметной области, где удаление сведений о товаре невозможно ввиду того, что товар уже участвовал в процессе продажи или сведения о нем зафиксированы в других информационных объектах (например, в информационном объекте «Заказ»).

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

• • на верхних уровнях размешаются бизнес-процессы, направленные па изменение качества (состояний) продукта/услуги;
• • ниже бизнес-процессов размещаются вспомогательные бизнес-функции, являющиеся составной частью бизнес-процессов;
• • на нижних уровнях размещаются независимые вспомогательные процессы, которые обеспечивают выполнение бизнес-процессов и бизнесфункций.

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

• [1] Подобная технология допустима, но она приводит к появлению большого количества сущностей, которые нужно нормализовывать, либо к появлению единой сущности о большом количестве атрибутов, что также требует большой нормализации. Эти технологии будут рассмотрены в рамках классического подхода к моделированию базы данных.
• [2] Представление бизнес-элементов в среде моделирования базы данных зависит от технологии передачи сведений из бизнес-процессов в модель базы данных.
• [3] Термин «Хранилище данных» в программном средстве IBM WebSphere Business Modeler отличается от такого же термина в теории баз данных