Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

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

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

Однією з основних проблем в цьому процесі є визначення місця, коли варто припинити подальший розгляд і перейти до уточнення потоків даних з іншої точки зору. Щоб визначити етап, коли це варто зробити, визначимо деякі додаткові поняття: бізнес об'єкт, основний інформаційний об'єкт, допоміжний інформаційний об'єкт. Саме ці поняття дадуть можливість точно ідентифікувати функції, пов'язані з рівнем декомпозиції (декомпозіціонние точка зору) або до рівня допоміжної обробки (характеристична точка зору).

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

По суті, коли мова йде про розгляд предметної області з декомпозіціонние точки зору, розробник відштовхується від матеріальних потоків, а точніше - від інформаційного опису процесу створення

продуктів / послуг. В рамках різних методологій проектування цей процес може представлятися різними моделями, але у всіх них єдина ідея - показати послідовність зміни стану продукту / послуги. Саме цей продукт / послуга і представляється бізнес-об'єктом, відомості про який є основними в базі даних, заради накопичення, зберігання і обробки яких вона і створюється.

Розглядаючи наскрізний приклад "Електронний магазин" на початковому етапі розробки, виділимо продукти / послуги:

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

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

image43

Мал. 2.4. Дерево продуктів / послуг

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

Під основним інформаційним об'єктом розуміється бізнес-елемент, що представляє бізнес-об'єкт предметної області у вигляді інформаційної структури, що включає необхідні описи, інші бізнес-елементи і атрибути.

Розуміючи, що бізнес-об'єкт в інформаційному поданні повинен бути представлений відповідним бізнес-елементом, розглянуте раніше дерево продуктів / послуг можна представляти в якості базової інформаційної структури, що відображає основні інформаційні елементи, які повинні в моделях і базі даних представитися відповідними поданнями (сутності, таблиці ). Кошти, виділені при розгляді продуктів / послуг інформаційні об'єкти згодом будуть підтверджені існуючими в предметної області документами, де кожен з об'єктів є прямим на нього зазначенням (атрибутом) або комплексом атрибутів, що характеризують відповідний інформаційний об'єкт (рис. 2.5).

image44

Мал. 2.5. Дерево основних інформаційних об'єктів


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

Під допоміжним інформаційним об'єктом розуміється бізнес- елемент, який представляє інформаційний елемент предметної області, який може розглядатися як самостійний об'єкт і об'єктивно необхідний для опису основного інформаційного об'єкта.

Будь-який інформаційний об'єкт предметної області в реальному житті, як правило, видається матеріальним об'єктом, а якщо йдеться про виробництво матеріального продукту. Однак, в разі, коли в предметної області формується нематеріальний продукт (наприклад, "Нарада", "Розклад" і т.д.) або виявляється послуга, то інформаційні об'єкти будуть часто представлятися нематеріальними елементами. Коли ж мова йде про допоміжних інформаційних об'єктах, то вони дуже часто представляються нематеріальними об'єктами предметної області (наприклад, "Дисципліна", "Клас небезпеки", "Статус студента" і т.д.).

Ці допоміжні елементи можуть бути виділені з документів, які використовуються в предметної області, а також в процесі декомпозиції бізнес-процесів, поряд з чим вибудовується комплекс допоміжних процесів, які теж дозволяють виділити допоміжні інформаційні об'єкти, які для них є основними (ключовими) об'єктами. Такий підхід до розгляду предметної області не тільки дозволяє виділити в базі даних функціональні області, а й на початковому етапі розробки визначитися з базовими структурами даних, принципово важливих для реалізація інформаційної системи.

Так, для розглянутого прикладу основним продуктом виділений "Товари", але він, будучи також інформаційним об'єктом, є складовою частиною нематеріального об'єкта "Замовлення", який видається більш важливим елементом з точки зору реалізації бізнес-процесу, оскільки клієнти для придбання товарів реалізує цю функцію не для кожного товару окремо, а для сукупності товарів, що утворюють об'єкт "Замовлення". Цей об'єкт буде інформаційної характеристикою матеріального об'єкта "Товари" і, фактично, стане основним елементом при розгляді бізнес-процесу. В результаті моделювання бізнес-процесів був сформульований бізнес-процес "Управління реалізацією товарів" (рис. 2.6), що передбачає, в інформаційному плані, формування і реалізацію замовлень, що отримуються з сукупності товарів як інформаційних об'єктів.

image45

Мал. 2.в. Бізнес-процес "Управління реалізацією товарів"

Як очевидно з бізнес-процесу, для реалізації поставленого завдання необхідно виконати три під процесу (функції): "Замовлення товару", "Збір замовлення" і "Реалізація товару". Кожен з підпроцесів реалізує завдання обробки даних про одне основному об'єкті предметної області. Як правило, ключовим (основним) об'єктом є той об'єкт, який виходить в результаті виконання функції. Таким чином, для першого подпроцесса ключовим об'єктом буде "Товари" в стані "Замовлені товари", для другого подпроцесса - об'єкт "Товари" в стані "Товари для доставки", а для третього подпроцесса - об'єкт "Товари" в стані "Доставлені товари" .

Матеріальний об'єкт "Товари" в процесі реалізації діяльності змінює свій стан, що відображено в бізнес-процесі, і в міру цих змін наповнюється поруч інформаційних параметрів. До таких інформаційних об'єктів на початку бізнес-процесу відноситься "Потреба в товарах", який починає визначати ту сукупність товарів, які повинні бути придбані клієнтом (покупцем) і перетворитися в інформаційний об'єкт "Замовлення". Цей об'єкт можна розглядати одним з основних інформаційних об'єктів, що визначає всі необхідні характеристики для реалізації товарів клієнту (покупцеві). Після закінчення виконання бізнес-процесу інформаційним об'єктом, що характеризує доставлені товари, є реалізований замовлення, що включає в себе не тільки сам замовлення, але деякі інші характеристики.

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

image46

Мал. 2.7. Дерево функцій контекстного рівня


Зазначене подання визначає декомпозіціонние розгляд бізнес-процесу, ілюструючи функціональні області, які будуть реалізовуватися на рівні бази даних, обробляючи тільки ті інформаційні елементи, які для них об'єктивно необхідні.

Щоб розуміти інформаційне наповнення кожної функції бізнес-процесу, необхідно визначитися з оточенням цих функцій, де будуть відображені нс тільки вхідний і вихідний, а також додаткові інформаційні джерела (документи) і виконавці функції (рис. 2.8).

При аналізі оточення функції в процесі розробки інформаційної системи розглядається досить велика кількість елементів: ініціює і результуюча подія, реалізований продукт, виконавці функції, що впливають, декомпозіціонние і допоміжні функції, що входять і виходять документи, інформаційні об'єкти в якості джерел і споживачів відомостей. Однак з метою побудови моделі бази даних найбільший інтерес представляють елементи інформаційного характеру, до яких належать документи та інформаційні об'єкти. Поряд з ними досить важливим і корисним є виділення виконавців функції, які беруть участь в її реалізації. У зв'язку з вищесказаним розробнику потрібно чітко розуміти сутність кожного інформаційного елемента з оточення функції (табл. 2.1).

image47

Мал. 2.8. Оточення функції "Управління реалізацією товарів"

Таблиця 2.1

Опис інформаційних елементів з оточення функції "Управління реалізацією товарів"

п / п

І інформаційний елемент

опис

структура

1

Потреба в товарах

Інформаційний потік, що відображає необхідність в придбанні товарів магазину. Звісно ж як запиту до каталогу товарів магазину

Категорія товару

Характеристики

товару

ціновий діапазон


п / п

інформаційний

елемент

опис

структура

2

Реалізований

замовлення

Інформаційний потік, що містить відомості про товари, зазначених у реалізованому замовленні, і супровідних документах

Дата реалізації Сума реалізації Товари замовлення

3

запит клієнта

Електронний документ клієнта, що представляється запитом до інформаційної системи по типу питання "Чи є потрібний товар в магазині?"

4

Касовий чек

Документ, що відображає відомості про сплачену суму і інших платежах відповідно до законодавства

5

Товарний чек

Документ, який містить відомості про придбані товари із зазначенням кількості, ціни за одиницю та вартості. Документ містить ряд додаткових атрибутів, що характеризують клієнта і магазин

6

Специфікація

товарів

Документи, що містять відомості про технічні характеристики придбаних товарів

7

гарантійні

документи

Документи, що містять відомості про правила гарантійного ремонту і його строки


Оскільки дана функція є функцією верхнього рівня і підлягає декомпозиції, то цілком природним виявилося поява двох інформаційних об'єктів, що розглядаються в її реалізації. Зазвичай, коли функція є досить простий, особливо при розгляді допоміжних функцій, кількість основних інформаційних об'єктів не перевищує одного і в багатьох випадках повторюється в інших функціях. Однак таке дублювання інформаційних об'єктів в різних функціях не є проблемою, оскільки кожна функція буде розглядати тільки ті атрибути інформаційних об'єктів, які їй об'єктивно необхідні. В результаті такого розгляду, у міру збільшення розглянутих функцій, окремі інформаційні об'єкти будуть нарощуватися новими атрибутами, які необхідні для повноцінного зберігання відомостей в базі даних.

Первинний аналіз інформаційних об'єктів грунтується на виділенні інформаційних характеристик (атрибутів), необхідних для того, щоб розуміти інформаційне наповнення цього об'єкта. В якості таких інформаційних характеристик можуть виступати прості атрибути, а можуть представлятися структурними елементами, що подаються в якості самостійного інформаційного об'єкта предметної області, для якого ще не визначена функція обробки.


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

Розгляд інформаційних характеристик є досить поверховим уявленням інформаційного об'єкта і не дає повної атрибутивної картини, але при цьому дозволяє на початку розробки бази даних скласти деякий перелік інформаційних об'єктів, які можуть знадобитися, щоб в кінцевому рахунку реалізувати інформаційну систему. Цілком може скластися така ситуація, що деякі зазначені інформаційні об'єкти або атрибути не будуть затребувані, але це можна буде зробити, тільки проаналізувавши документи і провівши моделювання інформаційних потреб користувачів. Однак уже зараз можна істотно обмежити перелік цих інформаційних об'єктів і атрибутів, представляючи ті запити (інформаційні потреби), які можуть виникнути у користувача при використанні інформаційної системи.

Як простий атрибута розглядається характеристика інформаційного об'єкта, яка може бути визначена простим типом даних і не підлягає подальшому поділу на складові.

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

Однак, в деяких випадках виникає складна ситуація у визначенні типу інформаційного елемента. Наприклад, рядок адреси " 127083, г. Москва, у л. Верхня Маслівка, д. 21, кв. 2" може представлятися простим типом, а може - структурним елементом. Виникає питання: "Як визначити, який з варіантів варто розглядати?" Звичайно, все залежить від потреб обробки даних в базі даних. У разі, коли адреса є все лише неподільної характеристикою об'єкта та в процесі роботи з ним немає необхідності виділяти ні будинок, ні вулицю, ні місто, ні індекс, то ці відомості будуть описуватися простим атрибутів - текстовий рядок. Але в разі коли в процесі роботи з інформаційною системою, наприклад, необхідно буде вибрати товари, що доставляються в місто Москву, то виникає необхідність характеризувати адресу доставки структурним елементом, виділяючи в якості окремого атрибута характеристику "Місто".

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


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

Так, в розглянутому прикладі інформаційний об'єкт "Реалізований товар" описаний поруч характеристик, які дозволяють охарактеризувати його ключові властивості. Визначення цих характеристик ґрунтується не тільки і не стільки на умовиводах розробника, скільки на аналізі документів (електронних і друкованих), які беруть участь в реалізації даної функції. Наприклад, характеристика "Клієнт" виділена з документа "Товарний чек", де відображені відомості про покупця товарів. Назва атрибута визначається термінологією предметної області і має давати вичерпну інформацію про зазначений інформаційному об'єкті. Варто звернути увагу на те, що при описі характеристик реалізованого замовлення характеристика "Клієнт" не розглянули на рівні простих атрибутів. Звичайно, документ дає уявлення про атрибутивном складі даного інформаційного об'єкта, але для реалізованого замовлення не має значення складу характеристик, якими буде описуватися клієнт. Важливо, що об'єкт "Клієнт" всім його атрибутивною складом повинен бути присутнім в об'єкті "Реалізований замовлення" і описувати фізична або юридична особа, яка придбала зазначені в документі "Товарний чек" товари.

В результаті розгляду об'єкта предметної області "Потреба в товарах" розробником були виділені атрибути: "Категорія товару", "Характеристики товару", "Ціновий діапазон". Оскільки інтервальний тип даних доступний не у всіх СУБД, то варто задуматися над використанням атрибута "Ціновий діапазон" і визначитися з його застосуванням в базі даних. Можливо, варто це атрибут розділити па два простих атрибута - "Початкова ціна" і "Кінцева ціна", що в розглянутому прикладі і буде зроблено.

Використовуючи інструментарій опису бізнес-елементів в IBM WebSphere Business Modeler, визначимо атрибутивную структуру об'єкта "Потреба в товарах" (рис. 2.9).

Потреба в товарах

image48

Мал. 2.9. Базове атрибутивное опис об'єкта "Потреба в товарах"

Як очевидно з прикладу, два останніх атрибута: "Початкова ціна" і "Кінцева ціна", - описуються типом "Ціле", тобто цілочисельним типом даних, оскільки значення цих атрибутів визначають грошову характеристику, але не вимагають високої точності, що дозволяє обмежитися для зручності роботи з даними саме цілочисельними типами даних.

Складніша справа з двома іншими атрибутами, оскільки вони не представляються простим елементом і їх опис типом "Текст" не є абсолютно логічним. Проте, для атрибута "Категорія товару" (рис. 2.10), якщо спочатку невідомо, що це буде фіксований набором значень довідник (класифікатор) або його значення буде вводитися вручну користувачем інформаційної системи з клавіатури, то використання такого типу даних може бути виправданим . Однак, в даному випадку, таке пояснення не є логічним, оскільки список категорій товару для магазину є завжди обмеженим набором фіксованих значень і його коригування виконується досить рідко, то його можна розглядати в якості класифікатора, і це призводить до необхідності визначення даного атрибута бізнес-елементом в моделі бізнес-процесів.

image49

Мал. 2.10. Атрибутивне опис об'єкта "Потреба в товарах"


У підсумку, для атрибута "Категорія товару" необхідно визначити тип даних, який посилається на створений бізнес-елемент "Категорія товарів". Его, при переході до моделювання даних, призведе до появи суті "Категорія товарів", яка буде використовуватися і розглядатися в базі даних класифікатора відповідного об'єкта.

З атрибутом "Характеристики товару" ситуація складніша, оскільки він передбачає розгляд безлічі різних характеристик, якими може описуватися товар, і аналіз предметної області показує, що для кожної категорії товару перелік цих характеристик може бути різним, що не дозволяє цей атрибут описати конкретним об'єктом предметної області. У зв'язку цим залишимо поки даний атрибут з типом даних "Текст" як найбільш підходящим для його опису,

Однак повернемося до його розгляду пізніше, коли будемо вивчати категоризацію в моделюванні і універсальні конструкції, якими такий атрибут доцільно розглядати.

З другим інформаційним об'єктом ситуація набагато простіше, оскільки цей елемент також представляється матеріальним документом, що володіє фіксованим набором атрибутів. Виділяючи атрибути інформаційного об'єкта, важливо почати виділяти все дрібні атрибути, які не мають прямого відношення до даного об'єкту [1] . Щоб не створювати великої кількості атрибутів, варто вже на даному етапі розглядати атрибутивний складу об'єкта в збільшеному варіанті (рис. 2.11).

image50

Мал. 2.11. Атрибутивне опис об'єкта "Реалізований товар"

Як видно, атрибут "Товари замовлення" є згрупованими, оскільки теж є бізнес-елементом предметної області і передбачає наявність власного набору атрибутів. До того ж, на етапі виділення інформаційних об'єктів немає необхідності для даного об'єкта уточнювати, як характеризується об'єкт "Товари замовлення". Досить того, що розробник розуміє сутність цього об'єкта і відразу його представляє бізнес-елементом в моделі бізнес-процесів.

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

Розглянемо аналогічним чином декомпозіціонние функцію "Замовлення товару" (рис. 2.12), яка розглядає процес перетворення потреби клієнта в замовлення. При тому, що на рівні моделювання бізнес-процесів ми можемо розглядати потоки в матеріальному і в інформаційному плані, потрібно враховувати, що інформаційне уявлення є не що інше, як опис структури матеріального або інформаційного об'єкта. В інтересах подальшого побудови бази даних розгляд бізнес-процесів доцільно тільки з інформаційної точки зору.

У розглянутому для моделювання бізнес-процесів програмному засобі IBM WebSphere Business Modeler компонент моделювання "Бізнес-елемент" є тим самим інформаційним об'єктом, який дає можливість спланувати інформаційну структуру бізнесдеятельності (процесу) і уявити структури даних. Однак варто враховувати, що при перенесенні структур даних з IBM WebSphere Business Modeler в IBM InfoSphere Data Architect атрибути бізнес-елементів можуть бути перетворені в сутності моделі бази даних [2] . Це пояснюється тим, що бізнес-елементом в моделюванні бізнес-процесів представляється інформаційний об'єкт предметної області, группирующий всередині себе комплекс інформаційних структур, які формують сховище даних [3] як сукупність інформаційних об'єктів.

image51

Мал. 2.12. Процес "Замовлення товару"

При розгляді подпроцесса "Замовлення товару" виділяється три функції: "Представлення каталогу товарів", "Наповнення кошика товарів" і "Формування замовлення". Цей процес цікавий тим, що він включає в себе три різних твань функцій. Один тин функцій представляється функцією "Представлення каталогу товарів". Ця функція відноситься до функцій, які реалізують інформаційну обробку, і її подальший розгляд має вестися в рамках побудови діаграми потоків даних.

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

В результаті реалізації функції "Представлення каталогу товарів" формується інформаційний потік "Каталог товарів", що представляється в предметної області відповідним матеріальним і інформаційним об'єктом. Цей об'єкт ніяк не пов'язаний з інформаційним потоком "Потреба в товарах", що в діаграмі показано незалежними інформаційними потоками. Але входження потоку "Потреба в товарах" в цю функції обгрунтовано, оскільки вона визначає деякі базові характеристики для подання каталогу. Надалі каталог товарів може бути уточнений на основі тих же потреб клієнта, що відображено продовженням цього потоку в наступну функцію.

Другий тип функції представляється функцією "Наповнення кошика товарів", яка є циклічною, оскільки клієнт виконує одні й ті ж операції з вибору придбаних товарів та фіксування цього вибору в кошику товарів. Ця операція виконується до тих пір, поки клієнт не вирішить, що вибрав усі товари для замовлення і готовий перейти до формування замовлення. Такі функції передбачається декомпозировать далі.

Третій тип функції представляється операцією формування і публікації документа "Замовлення товару", з одночасним фіксуванням факту завершення формування інформаційного об'єкта "Замовлення".

Але повернемося на рівень вище до розгляду функції подпроцесса "Замовлення товару", оточення якої може бути представлено у вигляді схеми, показаної на рис. 2.13.

image52

Мал. 2.13. Оточення функції "Замовлення товару"


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

Таблиця 2.2

Опис інформаційних елементів з оточення функції "Замовлення товару"

п / п

інформаційний елемент

опис

структура

1

Потреба в товарах

Інформаційний потік, що відображає необхідність в придбанні товарів магазину. Звісно ж як запиту до каталогу товарів магазину

Категорія товару

Характеристики

товару

ціновий діапазон

2

замовлення

Інформаційний потік, що представляється документом "Замовлення товарів"

клієнт

Ваше замовлення

товари

3

запит клієнта

Сурогатний документ, що характеризує параметри вибірки товарів з каталогу

4

Специфікація

товару

Документ, що описує основні технічні параметри кожного товару

5

Каталог товарів

Документ, що містить перелік товарів за певними характеристиками із зазначенням ціни та додаткових параметрів, необхідних для визначення можливості його замовлення клієнтом

6

замовлення товарів

Документ, отриманий в результаті фіксування обраних товарів для подальшої доставки клієнту



Діаграма оточення функції "Замовлення товару" дає нам інформацію про те, що для її виконання необхідно використовувати інформаційний об'єкт "Потреба в товарах", який повинен охарактеризувати основні характеристики товарів, придбаних клієнтом. Цей інформаційний об'єкт ніяк в предметної області не представлений і є всього лише деякими думками клієнта, тому його структуру визначити на підставі документів не представляється можливим, крім варіанту створення сурогатного документа, представивши характеристики, за якими будуть вибиратися товари з каталогу.

Іншим інформаційним об'єктом для функції "Замовлення товару" є результат виконання функції, що представляється документом "Заказ" (рис. 2.14) і відповідним бізнес-елементом.

image53

Мал. 2.14. Форма документа "Замовлення"


Цей бізнес-елемент однозначно, за результатами аналізу предметної області, співвідноситься з документом "Заказ" і характеризується всіма атрибутами, які в цьому документі присутні. Однак внесення всіх атрибутів документа в якості атрибутів інформаційного об'єкта "Замовлення" не є абсолютно правильним рішенням. Таке можливо, але це призведе до необхідності додаткової нормалізації, отриманої в логічної моделі відповідної сутності. Таке атрибутивное уявлення інформаційного об'єкта використовується при класичному підході до розробки баз даних.

Оскільки в сучасній розробці баз даних ми використовуємо не тільки документ як джерело інформації про інформаційні об'єкти, але і відомості, отримані при моделюванні бізнес-процесів з виділенням бізнес-елементів, відповідних інформаційних об'єктів, то вже на цьому етапі можна виділити деякі атрибути, які не мають безпосереднього відношення до замовлення, але беруть участь в описі інформаційних об'єктів, які розглядаються атрибутами замовлення. Так, розглядаючи документ "Заказ", можна виділити ряд атрибутів (табл. 2.3).

Розбираючи зазначені в документі атрибути, неважко помітити, що є атрибут, який не має відношення ні до замовлення, ні до товарів, вказуються в замовленні. Цим атрибутом є "№ п / п". Його сенс обмежений таблицею списку товарів, що замовляються, завжди в кожному документі "Заказ" починається зі значення "1". Це дозволяє сказати, що такий

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

Таблиця 23

Опис атрибутів документа "Замовлення"

п / п

Атрибут

опис

Тип даних

1

Номер замовлення

Порядковий номер, що характеризує унікальність кожного замовлення клієнтів магазину: формується з декількох елементів: рік і місяць формування замовлення, порядковий номер замовлення в місяці. Елементи номера замовлення розділені знаком "-" (наприклад: 05-2014-0005)

символьна

рядок

2

дата замовлення

Дата, коли замовлення було створено і зафіксований в якості остаточно сформованого і не підлягає коригуванню

Дата

3

Місто

Місце (місто), в якому створюється замовлення, визначається місцем доставки замовлення

символьна

рядок

4

клієнт

Прізвище, ім'я та по батькові покупця, якому буде доставлятися замовлення

те ж

5

Постачальник

Найменування організації з організаційно-правовою формою, яка є магазином, які продають на замовлення товари

6

№ "/"

Порядковий номер позиції товару, що замовляється в поточному замовленні

Ціле число

7

Артикул

Код, що позначає основні характеристики зазначеного товару

символьна

рядок

8

Найменування

товару

Повне найменування товару, що купується

те ж

9

кількість

Кількість придбаного конкретного товару

I (елое число

10

Ціна

Грошова оцінка вартості одиниці конкретного товару

Дійсне число

І

сума

Грошова оцінка вартості зазначеної кількості конкретного товару

те ж

12

Загальна сума

Грошова оцінка вартості всіх зазначених в замовленні товарів

- "-

13

керівник

Прізвище та ініціали керівника магазину, що забезпечує реалізацію замовлення

символьна

рядок



Атрибут "Клієнт" нам відомий за попереднім розгляду предметної області. Цей атрибут раніше розглядався як бізнес елемента. Виникає питання: "Чи є атрибут" Клієнт "і бізнес-елемент" Клієнт "одним і тим же?" Відповідаючи на це питання, потрібно

визначитися зі змістом атрибута і бізнес-елемента. Атрибут "Клієнт" є характеризацію людини, який оформляє замовлення і яким це замовлення буде доставлений. З огляду на, що людиною, що набирає товар, що визначено змістом бізнес-елемента "Клієнт", є людина, яка буде товар отримувати, а точніше, з яким буде доставлятися товар, отримуємо, що смисли атрибута і бізнес-елемента ідентичні. Тому в описі бізнес-елемента "Замовлення", який відповідає документу "Замовлення", атрибут "Клієнт" (рис. 2.15) повинен бути пов'язаний з бізнес-елементом "Клієнт".

image54

Мал. 2.15. Додавання атрибута "Клієнт" в бізнес-елемент "Замовлення"


У складі документа є два атрибути, значення яких для розглянутої предметної області є очевидними, оскільки характеризують сам магазин. Цими атрибутами є "Постачальник" і "Керівник". Оскільки в нашому прикладі предметної області магазин один і керівник у нього теж один, то значення цих атрибутів можуть бути зафіксовані і використовуватися нс в базі даних, а в додатку.

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

image55

Мал. 2.16. Додавання відомостей про організацію в бізнес-елемент "Замовлення"


Атрибути "Артикул", "Найменування товару", "Ціна" мають відношення до товару, і з їх опису це очевидно. Тому дані атрибути варто об'єднати під одним елементом "Товар", який в бізнес-процесах буде представлятися бізнес-елементом.

Об'єднання атрибутів стало можливим на підставі поданого опису і розуміння того, що це основний продукт бізнес-процесу. Але в класичному підході до розробки бази даних це не є очевидним, і ми повинні були б весь набір атрибутів уявити атрибутами елемента "Замовлення", що призведе до необхідності нормалізувати цю сутність логічної моделі бази даних. Дія, яке ми виконали, об'єднавши атрибути, стало можливим тільки тому, що попередній аналіз бізнес-процесів вказав нам на існування даного бізнес-елемента, а також розуміння факту ідентичності сенсу сукупності атрибутів під назвою "Товар" зі змістом бізнес-елемента "Товар" .

Однак залишається питання про розміщення атрибутів "Кількість" та "Сума". Обидва атрибута, хоч і розміщені в таблиці опису кожної позиції товару і характеризують цю позицію, не можуть бути віднесені до характеристик товару, оскільки описують відомості про замовлення конкретного товару клієнтом. Тому ці атрибути мають відношення до зв'язці "Товар-Замовлення", що реалізовано, на поточному етапі розробки, в бізнес-елементі "Товари замовлення".

Першим атрибутом для товарів замовлення є об'єкт "Замовлення". Це досить просто пояснити. Якщо подивитися на документ "Заказ", то неважко помітити необхідність вказівки великої кількості товарів в рамках єдиного замовлення, що говорить про те, що сам замовлення, а саме його атрибути, характеризують замовляються клієнтом (покупцем) товари.

Саме тому атрибут "Замовлення", пов'язаний з об'єктом "Замовлення", з'явився в об'єкті "Товари замовлення" (рис. 2.17). До того ж, його наявність ще підтверджується самою назвою об'єкта - "Товари замовлення".

image56

Мал. 2.17. Додавання атрибутів по товару в бізнес-елемент "Товари замовлення"


Варто поглянути на атрибут "Сума" по рядках таблиці товарів, що замовляються. Цей атрибут є обчислюваним, форму якого передбачає перемножування значень атрибутів "Кількість" та "Ціна". Тут потрібно задуматися про можливості реалізації даної операції в СУБД. Звичайно, її можна реалізувати, коли користувач самостійно вкаже значення або його вирахує додаток. Але в СУБД є можливості реалізації обчислюваних полів. З огляду на цю особливість в момент моделювання бази даних і її реалізації, варто задуматися про те, як буде виконуватися даний обчислення. Поточна вистава не дозволяє використовувати можливості СУБД, оскільки атрибути "Кількість" та "Ціна" розміщені в різних бізнес-елементах і в моделі бази даних будуть знаходитися в різних сутності (таблицях), що за правилами роботи з обчислюваними полями в СУБД неприпустимо. Правила СУБД припускають, що для реалізації технології обчислюється значення для поля таблиці потрібно, щоб всі використовувані в обчисленні поля знаходилися в тій же таблиці, що і обчислюється поле.

Виходячи зі сказаного вище, дане поле поки збережемо в складі атрибутів бізнес-елемента "Замовлення", але запам'ятаємо, що обчислення його значення необхідно розглянути окремо в процесі моделювання бази даних і її реалізації в СУБД.

Залишився останній атрибут, який ще не був розглянутий, "Загальна сума". Цей атрибут має відношення до замовлення клієнта в цілому і передбачає обчислення вартості замовлення за всіма замовленими товарами. Використання атрибута буде грунтуватися на уточненні його сенсу. Якщо він передбачає відображення тільки сумарної вартості для звіту, то в бізнес-елемент включати даний атрибут не варто, оскільки реалізація

запитів але формуванню відповідного документа дозволить отримати потрібне значення. Якщо значення цього атрибута потрібно для подальшого застосування в сховище даних, щоб не виконувати постійні обчислення його значення, завантажуючи ресурси СУБД, то його можна включити до складу атрибутів бізнес-елемента "Товари замовлення".

Таким чином, в процесі розгляду бізнес-процесу і конкретної функції були виділені необхідні інформаційні об'єкти, відповідні бізнес-елементів.

Тут потрібно розуміти, що перехід від моделювання бізнес-процесів до моделювання даних в розглянутих нами програмних засобах може привести до появи тільки сутностей без їх атрибутивного наповнення. Тому якщо в процесі опису інформаційних об'єктів (бізнес-елементів) будуть представлені атрибути простих типів, то вони також будуть представлені сутностями моделі бази даних і над ними потрібно буде провести операції нормалізації.

У процесі аналізу функції нами був розглянутий документ, який є результуючим і визначає відомості, які повинні бути сформовані з бази даних або відомостей, що подаються користувачем через екранну форму. Деякі документи ми нс розглядали, оскільки відомості, що містяться в них, необхідні для виконання функцій нижчого рівня, де їх і варто проаналізувати. До того ж ці документи є результатом роботи допоміжних бізнес-процесів, які зараз нами не розглядаються.

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

image57

Мал. 2.18. Декомпозиція бізнес-процесу "Замовлення товару"


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

Дерево залежності функцій

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

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

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

В рамках розробки бази даних допоміжні процеси доцільніше розглядати у вигляді моделей потоків даних, де будуть відображатися об'єкти зберігання даних і функції їх обробки, необхідні для виконання основних бізнес-функцій. Важливо розуміти, що подібні моделі можуть подаватися в двох варіантах: деталізаціоіная модель потоків даних і умовно-незалежний допоміжний процес роботи з даними.

Деталізаціоіная модель потоків даних використовується, коли необхідно показати процес обробки даних для формування відомостей в бізнес-функції. З іменування моделі вже очевидно, що для формування такої моделі використовується метод деталізації функції (процесу). Цей процес дозволяє виділити допоміжні функції в дереві функцій, які, з одного боку, є частиною бізнес-процесу, а з іншого - відображають залежність бізнес-функції від виконання ряду завдань, необхідних для ефективного функціонування бізнес-процесу. Як і для бізнес-процесу, формулювання назв допоміжних функцій грунтується на знаннях про предметну область і використовується термінологія предметної області. Тому на даному етапі розгляду предметної області, так само, як і на попередньому етапі розгляду, питання про технології та механізми читання і збереження даних в базі даних не ставляться. Розгляд цих завдань (операцій) доцільно виконувати на етапі формування зв'язків між функціями, формуючи процеси обробки даних для реалізації інформаційних потреб користувачів в отриманні або збереженні даних.

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

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

Розглянемо бізнес-функцію "Представлення каталогу товарів" (рис. 2.19). Ця функція не підлягає подальшій декомпозиції, оскільки будь-яке її виконання ніяким чином нс змінить стан продукту "Товар", а тільки уточнить процес виконання. Тому подальше подання цієї функції у вигляді бізнес-функції недоцільно, а необхідно визначити потоки даних, які дозволять сформувати її реалізацію.

Щоб визначитися з потоками даних бізнес-функції, спочатку потрібно сформувати вхідний і вихідний інформаційні потоки. У цьому випадку на моделі бізнес-процесу додаємо вхідний потік "Потреба в товарах", який вже був сформований раніше. Також в якості вихідного потоку додаємо "Каталог товарів", який одночасно є вхідним потоком для функції "Наповнення кошика товарами".

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

image58

Товари (об'єкт) (Замовлені товари]

Мал. 2.19. Додавання інформаційних потоків для функції "Представлення каталогу товарів"

image59

Мал. 2.20. Приклад форми документа "Прайс-лист"

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

Найбільший інтерес для поточного розгляду представляє таблиця зі списком товарів. Її структура дозволяє визначитися з набором атрибутів кожного товару. Всі атрибути, зазначені в таблиці, оскільки ключовим елементом документа є товар, відносяться саме до товару, а не до будь-якого іншого інформаційного об'єкту. У нашій вихідної структурі інформаційного об'єкта "Товар" були вказані атрибути "Артикул", "Найменування" і "Ціна" (див. Рис. 2.20). У процесі аналізу поточного документа виявляється, що товари повинні ще характеризуватися атрибутом "Специфікація", який буде описувати детальні


особливості кожного товару. Цей атрибут повинен знайти відображення у відповідному бізнес-елементі "Товар", який повинен представлятися основним атрибутом інформаційного об'єкта "Каталог товарів".

Також, в документі спостерігається угруповання товарів за категоріями. Тут варто зупинитися на двох особливостях цієї характеристики документа: особливості подання категорій товарів і ставлення категорії до товару.

З точки зору представлення складу категорій товарів, слід, що в документі категорії товарів збудовані в ієрархічну (деревоподібну) структуру. Проаналізувавши в предметної області повний перелік категорій товарів, можна зробити висновок про точну структуру, яка може бути представлена ​​деревом або мережею, що накладе певні обмеження на структурування об'єкта і процедури його обробки в базі даних. Припустимо, що склад категорій товарів представляється деревовидної структурою типу "Дерево", а це означає, що кожен елемент нижчого рівня повинен посилатися на елемент попереднього рівня. Саме цю особливість і потрібно відобразити в складі інформаційного об'єкта "Категорія товарів" (рис. 2.21).

image60

Мал. 2.21. Приклад структури інформаційного об'єкта "Категорія товарів"


У цій структурі видно, що категорія товарів є класифікатором найменувань, згрупованих в ієрархію (дерево), що реалізується атрибутом "Батько категорії", який своїм значенням повинен посилатися на категорію попереднього рівня. Природно, що для категорії першого рівня батьківського елемента немає, і цей атрибут повинен припускати відсутність будь-якого значення.

Тепер розглянемо питання ставлення категорії товару до конкретного товару. Категорія товару повинна бути характеристикою товару, оскільки всі товари групуються за цими категоріями, а, отже, вона повинна бути атрибутом інформаційного об'єкта "Товар", що і буде відображено в складі інформаційного об'єкта "Товар", який є єдиною характеристикою каталогу товарів. В результаті "Каталог товарів" може бути представлений, як показано па рис. 2.22.


image61

Мал. 2.22. Атрибутивний складу інформаційного об'єкта "Каталог товарів"


Визначаючи атрибутивний складу цього інформаційного об'єкту, ми опираємося на можливих структурах документів "Прайс-лист" або "Каталог товарів". Вони можуть дати детальне уявлення про можливе подання каталогу товарів, що і було проведено в процесі формування атрибутивного складу інформаційних об'єктів "Каталог товарів", "Товар" і "Категорія товарів".

Процес перетворення потреб клієнта в каталог товарів (рис. 2.23) є функцією деталізації і розглядає завдання, але роботі з даними. У зв'язку з цим основними елементами, які необхідно аналізувати, є структури і потоки даних. Саме его розуміння процесу вимагає від розробника введення в модель процесу таких елементів, як "Сховище", де будуть показуватися елементи даних, необхідні для роботи відповідної задачі.

В результаті деталізації в моделі бізнес-процесу виділяються нові функції (завдання), які не змінюють якість продукту / послуги, тобто є допоміжними, але при цьому є об'єктивно необхідними для виконання бізнес-процесу. Ці функції (завдання) формують одиницю процесу в роботі користувача з інформаційною системою для формування необхідних інформаційних відомостей з метою реалізації основного бізнес-процесу (рис. 2.24).

При виділенні функцій (завдань) деталізації процесів існує певна небезпека - не почати виділяти операції інформаційної системи для виконання автоматичних робіт з даними. До таких операцій належать чотири основні: додавання нових даних, зміна і видалення існуючих даних, отримання (вибірка) збережених даних. Тому, щоб подібні ситуації не виникали, і розробник не сформував занадто деталізоване дерево функцій, необхідно дотримуватися деяких правил:

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

  • - Формулювання функції (завдання) не повинна містити фрази і словосполучення, що вказують на виконання простих операцій обробки даних (додавання, зміна, видалення, вибірка та ін.);
  • - Результатом виконання функції (завдання) повинен бути інформаційний потік, який надається в інформаційній системі візуалізованою формою (наприклад, екранна форма або її елемент).

image62

Мал. 2.23. Процес формування каталогу товарів


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

Як очевидно з моделі потоків даних, для реалізації першого завдання "Підготовка відомостей для формування каталогу товарів" необхідно використання даних зі сховища "Категорії товарів", яке характеризується інформаційним об'єктом "Категорія товарів". Використання цих даних обґрунтовується наявністю характеристики "Категорія товарів" та інформаційного об'єкта "Потреба в товарах". Реалізація цієї потреби вимагає надання користувачу інформаційної системи відомостей про те, які категорії товарів в базі даних існують.

Тут варто згадати той факт, що, розробляючи інформаційну систему, яка містить базу даних, необхідно постійно замислюватися про форми представлення даних користувачеві в екранних формах і необхідності зберігання в базі даних відповідних класифікаційних відомостей. Для цього необхідно добре розуміти психологічні особливості роботи користувача з інформаційною системою, серед яких можна виділити таку, що користувач прагне до мінімізації введення даних з клавіатури і максимальному використанню різних "вказівних" способів введення: комп'ютерна миша, сенсорна поверхня і ін.


image63

Мал. 2.24. Деталізація функції "Представлення каталогу товарів"


З огляду на характерні особливості роботи користувача з інформаційною системою і практично неможливе правильне і точне вказівку найменування категорії товарів в текстовому вигляді, використовуваних в магазині, розробник повинен визначити спосіб роботи з інформаційним об'єктом "Категорія товарів", коли необхідно вибрати певні категорії для подальшого використання в інформаційних потребах користувача. Таким чином, ми розуміємо, що для подання категорій товарів на екрані користувача в зручному для роботи вигляді необхідно мати довідник (класифікатор) категорій товарів, а аналіз структури документа "Прайс-лист" вимагає подання цього довідника (класифікатора) в ієрархічному (деревоподібному) вигляді .

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


Виділення допоміжних процесів, крім розуміння розробником факту використання окремих функцій і завдань, що реалізуються в цих процесах, дозволяє ще визначити першочерговість реалізації функцій при створенні інформаційної системи. Так, виділивши допоміжний процес "Ведення довідника категорій товарів", розробник інформаційної системи буде в першу чергу реалізовувати саме цю функцію, а потім, коли будуть визначені основні інструменти для роботи з цим довідником, приступить до реалізації інших функцій і процесів.

Допоміжні процеси не відносяться до бізнес-процесів предметної області, оскільки не формують нової якості кінцевого про- продукту / послуги, але вони об'єктивно необхідні для ефективної роботи з даними, і їх першочергова реалізація формує оточення допоміжної функції бізнес-процесу. Аналогічно терміну "Допоміжний процес" в рамках дерева функцій такі процеси позначаються терміном "Допоміжна функція" (рис. 2.25).

image64

Мал. 2.25. Відображення допоміжної функції


Виділивши допоміжну функцію "Ведення довідника категорій товарів", розробник визначає його структурний наповнення. У розглянутому прикладі ми раніше вже визначили цю структуру (див. Рис. 2.21). Ця структура, враховуючи особливість подання відповідних даних, містить атрибут "Батько категорії", який дозволяє зв'язати всі категорії в ієрархічну структуру.

В іншій функції даного дерева "Формування списку доступних товарів" набір допоміжних процесів буде трохи більше, оскільки для коректної обробки даних необхідно нс тільки володіти відомостями про товари, але також про їх розподіл за категоріями магазину, що відображено в структурі даних "Каталог товарів" ( см. рис. 2.22). Тому в дереві функцій з'явиться допоміжна функції "Ведення довідника товарів", а рівнем нижче - "Ведення довідника категорій товарів", ілюструючи, що при веденні складу наявних на складі товарів необхідно володіти довідником категорій товарів.

Оскільки в розглянутому прикладі питання складського обліку товарів не розглядається, то вся інформація про товари на складі може вважатися довідником (класифікатором), який буде періодично поповнюватися окремими відомостями, необхідними для ефективної роботи магазину. Наприклад, в бізнес-елементі "Товар" повинні будуть з'явитися атрибути, що характеризують кількісні характеристики товару ( "Залишок на складі", "Кількість товару, що надійшов", "Кількість реалізованого товару" та ін.). Необов'язково, що атрибути будуть представлені саме в тому вигляді, як вони раніше були сформульовані. Деякі з них можуть бути представлені агрегованими відомостями в сховище даних для аналітичної обробки, деякі можуть залишитися атрибутами інформаційного об'єкта "Товар", деякі можуть бути розміщені в інші інформаційні об'єкти в результаті нормалізації моделі бази даних (рис. 2.26).

При побудові дерева функцій, особливо в частині відображення допоміжних процесів, принципово важливо правильно формулювати найменування процесу. Від цього залежить розуміння подальшого процесу обробки. Якщо в бізіес-процесі і бізнес-функції розглядається лінійно-розгалужених процес перетворення об'єкта з одного стану в інший і його можна вибудувати в суворій послідовності дій по безлічі напрямків реалізації (в залежності від мають місце умов), то для допоміжних процесів, коли вони володіють формулюванням "Ведення довідника ..." або аналогічної, процес виконання завдань визначається не послідовністю функцій, хоча вона, природно, в процесі присутній, а потребою у здійсненні відповідного завдання, і цей процес буде вже не лінійним, а представлятися групою незалежних функцій, пов'язаних в загальну реалізацію.

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

ні я допоміжних процесів розробник сформує структурований опис, яке може бути представлено у вигляді табл. 2.4.

image65

Мал. 2.26. Деталізація та уточнення функції "Формування списку доступних товарів"


Визначення виконуваних операцій важливо для розуміння дій, які можливі при роботі з відповідним інформаційним об'єктом. Наприклад, при роботі з каталогом товарів відсутній операція, але видалення товарів. Его визначається на основі аналізу предметної області, де видалення відомостей про товар неможливо з огляду на те, що товар вже брав участь в процесі продажу або відомості про нього зафіксовані в інших інформаційних об'єктах (наприклад, в інформаційному об'єкті "Замовлення").


структурований опис

п / п

процес

опис

інформаційний об'єкт

Що Їх операції

1

ведення

довідника

категорій

товарів

Наповнення та структуризація в дерево списку найменувань категорій товарів

Категорія

товарів

  • - Додавання категорії;
  • - Зміна назви категорії;
  • - Видалення категорії; структуризація категорій

2

ведення

довідника

товарів

Поповнення списку товарів для кожної категорії товарів

Каталог

товарів

  • - Додавання товару;
  • - Зміна характеристик товару;

категоризація товарів



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

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

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

  • [1] Подібна технологія допустима, але вона призводить до появи великої кількості сутностей, які потрібно нормалізувати, або до появи єдиної сутності про велику кількість атрибутів, що також вимагає великої нормалізації. Ці технології будуть розглянуті в рамках класичного підходу до моделювання бази даних.
  • [2] Представлення бізнес-елементів в середовищі моделювання бази даних залежить від технології передачі відомостей з бізнес-процесів в модель бази даних.
  • [3] Термін "Сховище даних" в програмному засобі IBM WebSphere Business Modeler відрізняється від такого ж терміну в теорії баз даних
 
<<   ЗМІСТ   >>