Методологія структурного аналізу і проектування SADT. Глава 19, Комерція, Різне, статті

Глава 19. Примітки на діаграмах і моделях



Мова блоків і дуг в SADT описує всі функції, і об’єкти системи і, отже дозволяє розкрити функціональне утримання системи. Однак іноді графіка функціональної SADT-моделі недостатньо описує, як саме діє система. Зверніть увагу, ми сказали “недостатньо”, а не “неточно”. Правильно створена перевірена функціональна SADT-модель точно описує функціональний зміст системи зі статичної точки зору, але цього може виявитися недостатньо для опису інших аспектів роботи системи та її поведінки, необхідних для повного розуміння того, як вона повинна функціонувати. Властивості системи та правила виконання її функцій – ось два найбільш загальних аспекту такого роду. Властивості – це чисельні і текстові описи характеристик функцій і даних системи. Дії визначають, що необхідно для того, щоб функції виконувались правильно, і які результати їх виконання. Використовуючи поняття властивостей і дій, SADT надає можливість уточнювати діаграму за допомогою приміток, що описують її динаміку. Записи таких приміток пожвавлюють модель.


19.1. Інформація про властивості


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


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


Не дивно, що розуміння системи буде не повним, поки не визначені властивості функцій і об’єктів. SADT вимагає, щоб властивості визначалися з використанням так званих “міток властивостей”. Мітка властивості – Це зауваження “з квадратом”, поєднане з блоком чи дугою за допомогою зигзагоподібної лінії і описує цю властивість. Описи не всіх властивостей конкретного блоку або дуги поміщаються на діаграму, а тільки тих, які прояснюють зміст діаграми. Наприклад, на рис. 19-1 показано, як використовуються мітки властивостей для опису стандартної частоти виконання функцій в ході виконання робіт з робочим комплектом. Ці мітки приєднані до блоків діаграми.


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

Рис. 19-1. Додавання міток, що описують властивості модельованої системи


19.2. Правила дії


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


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



[Модель /] блок * дію: передумови -> післяумови


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

Рис. 19-2. Функція, що має єдине правило дії


Для функції блок правило дії дія визначається так: якщо істинні передумови, виконується функція блок і робить істинними післяумови.
Як передумови, так і післяумови представляють собою логічні вирази, побудовані за допомогою ICOM-кодів, де кожен ICOM-код ідентифікує одиничну дугу управління, вхідні або вихідну дугу конкретного блоку. Логічні оператори AND, OR і NOT разом з дужками представляють засоби для запису різних складних логічних виразів. Наприклад, на рис. 19-2 показаний блок діаграми ЕМЦ/А2, у якого тільки одне правило дії. Це правило стверджує, що функції підготувати робоче місце необхідні вибране інструменти, верстати в цеху, креслення та вказівки, щоб робочий підготував обладнане робоче місце. Це приклад правила дії, яка стверджує необхідність участі всіх вхідних дуг, дуг управління і вихідних дуг в дії конкретного блоку.


Часто виникають ситуації, в яких для правильного дії блоку необхідно відсутність однієї або декількох дуг. Дуги, не беруть участь в конкретному дії, відзначаються горизонтальним штрихом (символізує NOT) над ICOM-кодом, якщо вони входять в передумова. Це означає, що об’єкти, які подаються цієї дугою, повинні бути відсутніми для того, щоб дія була виконана. Наприклад, дія 3 на рис. 19-3

Рис. 19-3. Функція, що має кілька правил дії


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


Зустрічаються також ситуації, коли тільки деякі з дуг використовуються в процесі дії для виробництва виходів. Якщо вхідні дуга або дуга управління не беруть участь у дії, вони просто опускаються в передумов. Аналогічно якщо тільки частина виходів блоку проводиться під час дії, то ICOM-коди для цих не створюваних виходів опускаються в постусловіем. Наприклад, відсутність 02 і 03 у дії 4 означає, що в процесі цієї дії виробляється тільки статус завдання.


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


19.3. Генерація правил дії


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


Дія кожного блоку описується таблицею істинності, що представляє собою декартовій твір всіх можливих поєднань присутності (відзначається за допомогою “true” або Т) та обов’язкового відсутності (відзначається за допомогою “false” або F) вхідних дуг, дуг управління і вихідних дуг. Кожен стовпець такої таблиці стає тоді потенційним правилом дії. (Іноді не має значення, чи приймає конкретна дуга участь у дії. У цих випадках видається розумним використання літери D. Проте запам’ятайте, що для повного відображення декартова твори потрібно істотне збільшення розміру таблиць.)


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


Таблиця 19-1. Всі можливі дії блоку “Підготувати робоче місце”


конкретна функція моделируемой вами системи.


19.4. Резюме


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


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


Dickover, M., and С. McGowan: “Software Design Using SADT”, SofTech Technical paper TP061, August 1977.
Mendelson, E.: Introduction to Mathematical Logic, Van Nostrand Reinhold, New York, 1964.
Martin, J., and C. McClure: Diagramming Techniques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, N.J., 1985.
Parnas, D.: “On the Criteria to be Used in Decomposing Systems into Modules”, CACM, December 1972.
Ross, D.: “An Essay on Activity Diagramming”, SofTech Technical Report no. 7104, November 1976.
Ross D.: “Structured Analysis (SA): A Language for Communicating Ideas”, IEEE Transactions on Software Engineering, vol. 3, no. 1, January 1977.
Schoman, K.: “SADT and PERT”, SofTech Deliverable no. CLIN#0-02AG, November 1977.
SofTech, Inc.: “The DWS/CS Emergency Preset Structured Specification”, Technical Paper no. 1083-1, August 1981.
Savith, W.: Abstract Machines and Grammars, Little, Brown, Boston, 1982.
Weinberg, G.: An Introduction to General Systems Theory, John Wiley, New York, 1975.
Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.


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


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

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

Ваш отзыв

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

*

*