Проектування інформаційних систем. Частина 4. Етапи розробки проекту: заключні стадії проектування, специфікації функцій, Комерція, Різне, статті

Частина 3


Зміст



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


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


Обробка ієрархії функцій


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


Добре, якщо при описі функції аналітик вкаже в дужках той об’єкт в ER-моделі (сутність і атрибут), про який йде мова, наприклад «вибрати товари в накладній зі списку товарів (ITEMS), що зберігаються на складі (STORE) ». Якщо подібних вказівок немає, це стане хорошим вправою для приймання звітів аналітиків; заодно і переконайтеся, що ви правильно розумієте один одного. Паралельно перевірте, чи є сутності, які не використовуються ні в одній функції, – це допоможе зробити матрицю «функції-атрибути», що відображає факт використання у функціях атрибутів сутностей.


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


Деякі групи модулів присутні в будь-якому проекті:



Один із прийомів побудови розширюваних систем полягає в створенні незалежності двох шарів: обробки запитів і інтерфейсу, наданого користувачеві. Можна спеціально кодувати кожен запит даних, наприклад ім’ям функції і номером або як-небудь інакше. Текст SQL-запиту прихований від розробників інтерфейсів; вони мають доступ тільки до повертається запитом безлічі – коду помилки або вибірці. Формат коду помилки та вибірки фіксується. Це дозволяє проектувальникам схеми бази даних змінювати як її, так і сам SQL-запит, однак ці зміни не відображаються на процесах створення інтерфейсів. Аналогічна незалежність реалізується для шару функцій, що забезпечують виклики інтерфейсу, наданого СУБД для виконання запитів. Цей шар функцій може використовувати виклики як native-інтерфейсу СУБД, так і стандартних інтерфейсів, наприклад ODBC.


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


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


Управління вихідним кодом


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


Контролю піддається не тільки власне код модулів, але і код скриптів генерації схеми бази даних, а також власне схема бази даних, яка може зберігатися у вигляді версій бінарних файлів, експортованих у внутрішній формат СУБД схем баз даних. Справа проектувальників – передбачити наявність таких механізмів розробки, справа прикладних програмістів – дотримуватися встановлених правил групової розробки. Часто провідні виконавці проектів не довіряють системам контролю вихідного коду зливати правки у вихідних текстах автоматично і частково або повністю контролюють цей процес. Ця перестраховка у багатьох випадках себе виправдовує.


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


10.01.2000 Ivanov: authorization bug fixed (found by Petrov)


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


Функції, структури, найбільш важливі змінні повинні супроводжуватися коментарями. Уникайте незрозумілих назв виду K1, Function10.


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


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


Розміщення логіки обробки


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


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


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


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


Нижче наведемо кілька правил, переданих аналітиками, і класифікуємо їх. Справа в тому, що при проектуванні групи правил не повинні перемішуватися. Отже:



  1. Тільки керівник може санкціонувати виплату винагороди.

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


  2. Оновлення записів про платежі заборонено.

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


  3. Всі коди валют повинні розкриватися, рядом з кодом вказується повна назва валюти.

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


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

    Подібні правила часто описуються аналітиками. Насправді тут два правила в одному, і їх треба розділити. Перше свідчить про те, що в бухгалтерських книгах не повинно бути проводок, зроблених в неділю. Це правило даних. Воно може бути реалізоване обмеженням check. Друге правило – для процесів. Воно пояснює, як відкоригувати дату: щоб дата бухгалтерської проводки була правильною для «неділі», потрібно додати один день. Це дозволяє уникнути випадку, коли в додатку з’являється оператор insert зі свідомо відкиданими даними. Обробку такої ситуації можна надати збереженої процедури, якщо її мова досить потужний і припустимі виклики зовнішніх функцій (в даному випадку перевірка дня тижня) або є вбудована функція обробки календаря. Якщо ж рішення у вигляді збереженої процедури неможливо, то це перетворення має виконати сам додаток (виклик бібліотечної функції або відповідна організація об’єктів – як більше подобається). Інше рішення такого завдання – додавання похідного атрибута. Замість одного атрибута, що зберігає дату, отримуємо два: один зберігає реальну дату, другий – відкориговану для «неділі»; останній є похідним. Це допустимо, якщо подібна денормализация не тягне за собою багато аномалій модифікації.


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

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


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


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


Слід зазначити, що багато проблем в інтерфейсах користувачів створюють самі проектувальники, якщо вони неправильно вибирають макет і не враховують різниці поведінки системи на макеті і на реальних даних. Найбільш часта помилка проектування інтерфейсу – відображення даних у формі для редагування і блокування їх засобами СУБД до тих пір, поки користувач не натисне кнопку OK. Ще одна поширена помилка проектування інтерфейсу – обробка тривалих процесів, коли користувач повинен чекати відповіді на запит. Більшість проектувальників не передбачають єдиного виклику функції-обробника події очікування відповіді. На макеті запит може проходити миттєво, а у випадку реальних даних це може становити кілька хвилин. Якщо обробка очікування відповіді не передбачена (хоча б у вигляді елементарного повідомлення «почекайте, йде обробка даних»), то користувач думає, що додаток «зависло».


З точки зору логіки розташування правил вони повинні бути реалізовані так:



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


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


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


При роботі декількох користувачів з одними і тими ж об’єктами даних проектувальникам доводиться вирішувати завдання спільного редагування документів, наприклад оформлення замовлення. Клієнт не завжди точно визначає перелік товарів та їх кількість, а тому оформлення замовлення може вимагати деякого часу (і воно більше, ніж чистий час заповнення екранної форми оператором). Проектувальники допускають поширену помилку рішення інтерфейсу користувача для таких завдань: в екранній формі відображається введення позицій замовлення, які вибираються з довідників; вибрані дані блокуються до тих пір, поки оператор не натисне OK. Це призводить до виникнення феномена «конвою». А саме – кілька операторів після натискання OK починають чекати вирішення конфліктів засобами СУБД, в той час як велика кількість конфліктів спровокував саме інтерфейс. Справді час редагування форми набагато перевершує час обміну даними програми користувача і СУБД, з’єднання з СУБД простоює до 99% часу – тобто чекає запиту, тоді як блокування даних залишається. Чим довше час блокування, тим більше вірогідність конфлікту. Тут у деяких проектувальників виникає ідея звинуватити СУБД у всіх гріхах: вона ж блокує, а ми ніби й ні при чому. Припустимо, що СУБД не блокує редаговані дані, і вони вступають в силу тільки після натискання кнопки OK. Це, звичайно, добре, але протягом часу редагування інший користувач міг змінити ті ж дані і зафіксувати свої зміни. СУБД транзакцію другого користувача вже не пропустить – це типово для стратегії оптимістичних блокувань. Виникає питання: якщо й так погано, і так недобре, що робити? Проблема – в невірному взаємодії інтерфейсу і обробки даних. Транзакція в будь СУБД починається або явно, або за фактом першого запиту даних. При описаному вирішенні інтерфейсу транзакція виявляється занадто довгою. Адже коли йде формування списку замовляються товарів, виконуються запити до даних і транзакція вже розпочато. Можна примусово розірвати операцію формування замовлення і його підтвердження. Тут використовують стандартні методи визначення зон ризику: так, у випадку замовлення товару це вхід в зону потенційної нестачі (наприклад, замовили 90% товару, наявного на складі, – це слід відзначити як сигнал потенційного ризику продажу товару два рази). По кнопці OK виконується підтвердження раніше зарезервованого товару і в результаті ймовірність конфлікту знижується.


Аналогічно вирішується завдання одночасного редагування двома користувачами одного документа. Зміни користувача (які він зробив в екранній формі) запам’ятовуються в спеціальному буфері даних; те, що він спочатку отримав для редагування, також запам’ятовується в буфері початкових даних. При натисканні кнопки OK виконується спроба зафіксувати зміни користувача. На рівні правил даних (дозвіл конфліктів транзакцій) виконується перевірка відсутності зафіксованих іншим користувачем змін. Якщо дані були кимось змінені під час редагування, то користувач отримує попередження про це. Йому може бути запропоновано переглянути зміни, які перебувають на даний момент в базі даних, і залежно від цього зберегти свої зміни поверх або відмовитися від них. Природно, це не вимагає від користувача повторного заповнення всієї форми (що дуже дратує користувачів).


Трирівнева архітектура


Додаток поділяється на три частини: 1) управління інтерфейсом користувача; 2) виконання правил обробки даних; 3) виконання функцій зберігання та вибірки даних.


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


Сучасні СУБД дозволяють реалізовувати ПО проміжного шару як за допомогою моніторів транзакцій (CICS, Enchina, Tuxedo тощо), так і на самому сервері баз даних у вигляді збережених процедур і пакетів (частково або повністю). В цьому випадку код, який реалізує інтерфейс користувача, не містить викликів пропозицій SQL, вони «заховані» у код пакета або збереженої процедури (тут можна говорити про інкапсуляції, що деякі автори й роблять). У таких випадках для вирішення користувальницького інтерфейсу застосовують рекомендовані, а не обов’язкові перевірки правил. Дані при цьому блокуються (вони взагалі не пов’язані зі сховищем даних) до тих пір, поки користувач не захоче зафіксувати свої зміни (кнопка OK), а власне зміни передаються атомарної транзакцією. Це дозволяє ефективно використовувати монітори транзакцій. Подібні рішення рекомендовані для OLTP.


Метрики генерації модулів


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


У більшості проектів оцінку часу розробки виробляють двічі:



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


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



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


Мегамодулі


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


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


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


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


Макети


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


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


Інше призначення макетів – перевірити проектні рішення. Для цього годяться виявлені на етапі аналізу критичні ділянки системи. Добрими варіантами будуть кілька складних звітів; частина OLTP, частина OLAP. Це дозволить залучити до процесу проектування групи тестерів, для того щоб вони перевірили продуктивність системи.


Опис


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


Опис екранних форм і звітів повинно містити:



Опис пакетних процесів повинно містити:



Обробка помилок


Обробка помилок – це одна з підсистем, яка часто псує життя проектувальникам. Користувачі вимагають зрозумілих повідомлень про помилки. Їм не сподобається, якщо при спробі видалити постачальника інформаційна система видасть повідомлення виду «SQL0532N a parent row cannot be deleted because the relationship CLIENT_ restricts deletion» замість того, щоб повідомити про неможливість видалення постачальника, якщо є факти поставки ним товару на склад.


Рекомендується зробити кілька рівнів обробки помилок. Перший рівень доступний в шарі модулів, що відповідають безпосередньо за виклики SQL. Цей шар обробляє коди помилок, що передаються інтерфейсом викликів СУБД. Відомо, що коди помилок, детектуючі одне і те ж порушення обмежень даних, в різних СУБД різні. Тому, якщо ваша пропозиція має хоча б ймовірність роботи з декількома СУБД, вам доведеться інтерпретувати коди повернення СУБД і побудувати матрицю відповідності коду повернення СУБД та коду помилки, використовуваного в підсистемі обробки помилок. Ніякі модулі, крім інтерпретатора кодів, не повинні мати доступу до кодів повернення СУБД. Вся обробка помилок в інформаційній системі повинна будуватися на внутрішніх кодах повернення. Безліч цих кодів може розширюватися, але значення кодів змінювати не можна. Потрібно проаналізувати, в якому форматі СУБД повертає код. Це може бути:



Внутрішня помилка може складатися з трьох компонентів:



Перші два компоненти забезпечують підтримку стандарту, останній дозволяє використовувати цю ж підсистему обробки помилок для роботи всіх підсистем. Слід зазначити, що деякі СУБД повертають код помилки операційної системи у разі збоїв створення файлів, читання сторінок і т.п. Таким чином, подібна структура може забезпечити достатню універсальність обробки помилок. Тип помилки – помилка СУБД або помилка певного компонента інформаційної системи – буде контролюватися за допомогою коду sqlstate. Як правило, sqlcode – це interger, sqlstate – це char (8) (довжина вирівняна на 4, що слід робити, наприклад, для RS/6000, SUN SPARC, ALPHA, SGI), oscode – це integer. Наприклад, код -532 інтерпретується в (-906, ‘23001 ‘, 0).


Другий шар обробки помилок – це контекстна інтерпретація внутрішнього коду повернення. З кожним інтерфейсним модулем може бути зіставлений деякий набір параметрів інтерпретації коду повернення. Наприклад, для модуля редагування списку постачальників код (-906, ‘23001 ‘, 0) відповідає рядку повідомлення «не можна видалити постачальника, оскільки є пов’язані з ним поставки товару». За контексту цього винятку можна на вимогу користувача показати список поставок даного постачальника.

Частина 5


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


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

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

Ваш отзыв

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

*

*