Методологія структурного аналізу і проектування SADT. Глава 5

Глава 5. Більш глибокі концепції діаграм



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


5.1. Дуги мають різний зміст



У SADT дуги зображують об'єкти. Ми підкреслюємо тут термін "об'єкти", оскільки, на відміну від традиційних діаграм потоків даних з систем програмного забезпечення, SADT-діаграми містять дуги, що зображують велике різноманіття об'єктів. На рис. 5-2 діаграма виготовити нестандартну деталь містить дуги, що зображують плани, верстати, інструменти, сировина, документи, технічні креслення, готові деталі, усні вимоги та оцінки. Точний опис системи має містити таке різноманіття об'єктів для адекватного пояснення її роботи як на рівні деталей, так і на рівні її навколишнього середовища. Здатність SADT зображати різноманіття об'єктів за допомогою дуг випливає з того, що SADT є методологією опису систем самого загального призначення, а не тільки програмного забезпечення. Щоб допомогти аналітикам і експертам у розумінні й описі того, як різні об'єкти пов'язані один з одним, у графічний мова SADT введено два типи об'єктів: об'єкти, перетворені системою, та об'єкти, що керують виконанням цих перетворень. У SADT вони називаються відповідно входами та управліннями.


5.2. Дуги можуть бути декомпозирована



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


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

Рис 5-1. SADT-діаграма, що містить розгалуження та доповнення дуг


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


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


5.3. Дуги можуть бути "поміщені в тунель"



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

Рис. 5-2. Тунельні дуги дозволяють "заховати" деякі подробиці і показати необхідні деталі


іншій частині моделі або безпосередньо ззовні. На діаграмі ЕМЦ/А1 (рис. 5-2) дуга незайнятий робітник має початок, що виходить з тунелю. Тому ця дуга не з'являється на діаграмі ЕМЦ / АТ. Кінець входять в тунель дуг з невідомим приймачем полягає в дужки для вказівки, що ці дуги або йдуть в іншу частину моделі, або безпосередньо виходять з моделі, або не розглядаються більше. Наприклад, дуга механізму для блоку 2 на діаграмі ЕМЦ / АТ має входить в тунель кінець і тому не з'являється на діаграмі ЕМЦ/А1. Термін "тунель" є тут цілком відповідним, оскільки можна представляти собі вхідну в тунель дугу як би "йде під землю".


"Тунельні" позначення були введені в SADT після декількох років інтенсивного використання цієї методології в ряді областей. Досвід показав, що при описі складних систем потрібна велика кількість дуг для коректного та докладного представлення системи. Часто ці дуги можуть бути об'єднані, але іноді важливі об'єкти системи, не показані раніше на більш високих рівнях ієрархії моделі, з'являються при описі нових деталей. Крім того, ці деталі звичайно не настільки важливі, щоб їх показувати на більш високих рівнях моделі. "Тунельні" позначення використовуються для того, щоб уникнути хаотичного заповнення небажаними подробицями діаграм високого рівня. Ці позначення дають можливість управляти появою необхідних деталей, не заплутуючи більш загальні описи батьківських діаграм. Рис. 5-2 дає хороший приклад використання тунельних дуг, що дозволяють уникнути появи небажаних деталей на верхніх рівнях моделі. Дуга незайнятий робочий діаграми ЕМЦ/А1 потрібно на рівні блоку керувати виконанням завдання, але проходження цієї дуги по верхніх діаграм, включаючи діаграму виготовити нестандартну деталь, могло б тільки заплутати їх зміст. Так як дуга незайнятий робочий недоречна на діаграмі АТ, вона поміщена в тунель. Крім того, "тунельні" позначення допомагають приховувати відомості, необхідні тільки для верхніх рівнів моделі. Це мінімізує ймовірність захаращення діаграм-декомпозицій необов'язковою інформацією. Дуги з ув'язненими в дужки кінцями виконують ці завдання, оскільки вони не розглядаються як частина кордону при торканні ними блоку і, отже, не переносяться на діаграму, декомпозірующую цей блок. На рис. 5-2 показано, як за рахунок приміщення дуг механізмів у тунель вдається уникнути захаращення декомпозиції діаграми виготовити нестандартну деталь неінформативними або очевидними дугами механізмів, що стосуються всіх блоків. Вони заплутали б декомпозиції, не додавши ніякої нової інформації. Це дуже сильно гальмувало б справа, тому неінформативні дуги приховують біля кордону блоку.


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


5.4. Різниця між вхідними дугами і дугами управління



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


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

Рис. 5-3 Відділення входів від управлінь


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


Точно визначивши, що креслення управляє блоком зібрати, аналітик не робить більше ніяких припущень. Це створює сприятливу ситуацію для більш сильних тверджень. Наприклад, дуга управління на рис. 5-3 могла б мати мітку креслення і особливі вказівки, які означають, що креслення є стандартним керівництвом при складанні. Особливі вказівки також повинні враховуватися при складанні навіть у виняткових випадках. Без дуг управління SADT опис системи неможливо було б інтерпретувати настільки легко і точно. Різниця між вхідними дугами і дугами управління – дійсно потужний засіб графічного мови SADT.


5.5. Дуги механізмів визначають способи реалізації функцій



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


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


Механізми (на діаграмі) визначають хто буде виконувати конкретні функції. Як зазначено на рис. 5-2, дуги механізмів на діаграмі виготовити нестандартну деталь уточнюють, що головні функції експериментального механічного цеху будуть виконуватися представниками трьох типів персоналу: майстром, оператором, контролером. Це свідчить про спільне виконання функції різними фахівцями. Іншими словами, кілька дуг механізмів, що стосуються блоку, можуть представляти скоординовану діяльність.


Механізми можуть також вказувати, що одні функції підтримують


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

Рис. 5-4. Одні функції моделі підтримують виконання інших функцій


5.6. Зворотній зв'язок з управління та по потоку даних



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


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


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


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


5.7. Резюме



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


Додаткова література



Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*