Система реєстрації помилок в програмних засобах

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

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

Ще в недалекому минулому бізнес-додатки виконувалися на великих ЕОМ, що споруджували для звичайного службовця майже непереборні бар'єри на шляху до потрібної йому інформації. Однак з настанням персонального комп'ютера ситуація різко змінилася: доступні інструменти обробки та зберігання даних укупі з комп'ютерними мережами дозволили з'єднати комп'ютери не тільки всередині офісу, але і між підприємствами, відокремленими один від одного тисячами кілометрів. Одним з основних факторів, що сприяли такому зміни, було впровадження архітектури клієнт-сервер. Як зазначає Мімно, "Різкий перехід до архітектури клієнт-сервер на базі персональних комп'ютерів був викликаний перш за все вимогами бізнесу. Перед обличчям зростаючої конкуренції і прискорився циклу випуску нової продукції, виникла потреба у більш швидкому просуванні товарів на ринок, збільшення обсягу послуг, що надаються клієнтам, більш оперативному відстеження тенденцій розвитку ринку, загальному зменшенні витрат ". У цьому розділі ми розглянемо приклад інформаційно-керуючої системи (MIS, management information system) і покажемо, як об'єктно-орієнтована технологія пропонує єдину концепцію організації бази даних і розробки відповідної програми для архітектури клієнт-сервер.

Аналіз

За результатами системного аналізу можна виділити сім основних функцій системи:

- облік замовлень;

- прийом замовлень від клієнтів та відповіді на запити клієнтів про стан замовлень;

- ведення рахунків;

- напрямок рахунків клієнтам і відстеження платежів;

- прийом рахунків від постачальників і відстеження платежів постачальникам;

- відвантаження зі складу;

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

Архітектура клієнт-сервер

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

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

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

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

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

· механізми звернення - безпосередня робота з базою даних.

На архітектурні рішення впливає не тільки велика кількість стандартів. Мають значення і такі питання, як захист даних, продуктивність системи та її обсяг. Берсон пропонує архітектору кілька основних правил проектування додатку клієнт-сервер:

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

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

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

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

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

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

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

- полегшує перехід до відкритих систем. Треба виділити, однак, такі моменти ризику:

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

Моделі баз даних

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

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

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

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

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

- перша нормальна форма (1NF) Кожен атрибут є атомарному значення (нерозкладних атрибути).

- друга нормальна форма (2NF) Таблиця наведена в 1NF, і при цьому кожен атрибут цілком і повністю залежить від ключа (функціонально незалежні атрибути).

- третя нормальна форма (3NF) Таблиця наведена в 2NF, і при цьому жоден з атрибутів не надає жодних відомостей про інше атрибуті (взаємно незалежні атрибути).

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

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

SQL

При роботі з об'єктно-орієнтованою моделлю, де дані і форми поведінки з'єднані воєдино, користувачеві може знадобитися здійснити ряд транзакцій з таблицями. Він, наприклад, може захотіти додати в базу нового постачальника, виключити з неї деякі товари або змінити кількість наявного товару. Може також з'явитися необхідність зробити різні вибірки з бази даних, наприклад, переглянути список всіх продуктів від певного постачальника або отримати список товарів, кількість яких на складі недостатньо або надмірно з точки зору заданого нами критерію. Може, нарешті, знадобитися створити вичерпний звіт, в якому оцінюється вартість поповнення запасів до певного рівня, використовуючи найменш дорогих постачальників. Подібні типи транзакцій присутні майже в кожному додатку, що використовує реляційну базу даних. Для взаємодії з реляційними СУБД розроблено стандартну мову - SQL (Structured Query Language, мова структурованих запитів). SQL може використовуватися і в інтерактивному режимі, і для програмування. У нашій системі SQL-запити гратимуть роль абстракцій низького рівня. Користувачі навряд чи будуть розбиратися в SQL, адже ця мова не є частиною предметної області. Ми будемо використовувати SQL при реалізації програми. Складати свої SQL-пропозиції зможуть тільки досить досвідчені в програмуванні розробники інструментальних засобів нашої системи. Від простих смертних, які працюють із системою кожен день, мову запитів буде приховано. Відображення об'єктно-орієнтованого представлення світу в реляційне концептуально зрозуміло, але зазвичай вимагає досить стомлюючого опрацювання деталей.

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

Проектування

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

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

• конвеєри (pipes)

• віддалений виклик процедур (RPC)

• взаємодія клієнт / сервер через SQL.

Транзакція є основним високорівневим видом взаємодії сервера і клієнта, а також між клієнтами. На основі цього поняття можна виконувати конкретний аналіз варіантів використання. Принципово всі основні функції в системі складського обліку можуть розглядатися як транзакції. Для кожної транзакції визначається повний перелік операцій, які вона повинна виконати. Це означає, що для класу Transact ion необхідно визначити функції-члени, такі як attachoperation, які надають іншим об'єктам можливість об'єднати набір SQL-операторів для виконання в якості єдиної транзакції. Виконання транзакції дещо ускладнюється при роботі з розподіленими базами даних. Для роботи з даними, які розміщені на декількох серверах використовується так званий двофазний протокол завершення транзакцій. У цьому випадку агент, тобто об'єкт класу Transaction, розділяє транзакцію на кілька фрагментів і роздає їх для виконання різних серверів. Це називається фазою підготовки. Коли всі сервери повідомили про те, що готові до завершення, центральний агент транзакції передає їм усім команду commit. Це називається фазою завершення. Тільки при правильному завершенні всіх розділених компонент транзакції основна транзакція вважається завершеною. Якщо хоча б на одному сервері виконання операцій буде неповним, ми відкинемо всю транзакцію. Це можливо тому, що кожен екземпляр Transaction знає, як відкинути свою транзакцію.

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

Берсон звернув увагу на наявність кількох альтернативних моделей обробки подій:

- цикл обробки подій. У циклі проглядається черга подій і для кожної події викликається відповідна процедура обробки.

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

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

Розвиток проекту.

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

- модифікація або видалення даних про клієнтів; модифікація або видалення даних про продукти; модифікація замовлення; запити про клієнтів, замовлення та продукти.

- інтеграція всіх схожих транзакції, пов'язаних з постачальниками: створення замовлення та виписка рахунку.

- інтеграція всіх транзакцій,що залишилися, пов'язаних зі складом: складання звітів і виписка видаткових накладних.

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

- інтеграція всіх транзакції, що залишилися, пов'язаних з відвантаженням.

- інтеграція всіх транзакцій, що залишилися, пов'язаних з плануванням.

При загальному терміні проектування системи в 12-18 місяців необхідно кожні 3 місяці випускати робочий реліз програми. До закінчення терміну всі необхідні для роботи системи транзакції будуть охоплені.

Генератори додатків

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

Такий підхід дозволяє нам скористатися перевагами 4GL, зберігаючи ілюзію повністю об'єктно-орієнтованої архітектури. Крім того, мови четвертого покоління самі піддаються сильному впливу технології об'єктно-орієнтованого програмування і включають в себе прикладні інтерфейси для об'єктно-орієнтованих мов типу C++.

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

Супровід

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

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

- Надати можливість клієнтам працювати з системою по каналах зв'язку.

- Автоматично генерувати індивідуальні каталоги товарів для користувацьких груп або навіть окремих клієнтів.

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

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