- •VIII. Розробка інтернет-програм
- •IX. БдБ і БдС системи
- •X. Реалізація
- •XI. Тестування
- •Введення в розробку програмного забезпечення
- •1. Складність інформаційних систем
- •2. Розробка програмного забезпечення
- •Криза програмного забезпечення
- •4.Концептуальне моделювання
- •Життєві цикли програмного забезпечення
- •Модель водоспаду
- •2. Модель водоспаду із зворотнім зв'язком
- •Документоване виконання
- •Прототипування
- •Покрокова розробка
- •7.Модель спіралі
- •III. Етапи розробки програмного забезпечення
- •1. Стратегічний етап
- •Етап визначення вимог
- •2.2. Нефункціональні вимоги
- •4. Етап проектування
- •5. Етап реалізації
- •6. Етап тестування
- •7. Етап установки
- •8. Етап підтримки
- •IV. Стратегічний етап
- •1. Дії на стратегічному етапі
- •2. Співпраця з клієнтом
- •3. Область дії і контекст проекту
- •4. Стратегічні рішення
- •5. Оцінка різних варіантів рішеннь
- •6. Оцінка вартості рішень
- •7. Чинники успіху
- •8. Результати стратегічного етапу
- •9. Короткий звіт
- •V. Розпізнавання вимог і документація
- •1. Складнощі у формулюванні вимог
- •2. Методи ідентифікації вимог
- •3. Методи опису вимог
- •4. Типи вимог
- •5. Перевірка вимог
- •6. Документ з вимогами
- •2. Аналітична модель
- •3. Дії на етапі аналізу
- •4. Функціональна декомпозиція
- •5. Методологія, що використовується в створенні аналітичної моделі
- •6. Документація вимог
- •7. Аналіз чинників успіху
- •8. Короткий звіт
- •VII. Етап проектування
- •1. Цілі проектування
- •Малюнок 7.2.1. Етап проектування.
- •2. Специфікація результатів аналізу
- •3. Дизайн інтерфейсу
- •4. Структуровані схеми/діаграми
- •5. Складова організації даних
- •6. Оптимізація проекту
- •7. Фізична структура системи
- •8. Правильність і якість проекту
- •9. Нефункціональні вимоги на етапі проектування
- •10. Результати етапу проектування
- •11. Детальний документ проекту
- •2. Стандарти, правила і порядок здійснення дій проекту:
- •12. Короткий звіт
- •VIII. Розробка інтернет-програм
- •1. Специфікація інтернет-програми
- •2. Методи розробки інтернет-програм
- •3. Об'єктно-орієнтована гіперсередовищна модель розробки (oohdm)
- •4. Метод розробки веб-сторінок (wsdm)
- •5. Мова веб-моделювання (WebMl)
- •Формулювання вимог
- •Проект структури даних
- •Гіпертекстовий проект
- •IX. Бдб і бдс системи
- •1. Електронний бізнес
- •2. Інтернет-бізнес і електронний ринок.
- •3. Інтернет-магазин
- •4. Модель електронного бізнесу
- •1.Модель брокера
- •2.Модель, яка задовольняє індивідуальним потребам
- •3.Модель контактів
- •5. Платежі
- •6. Безпека
- •8. Моделювання систем бдб і бдс
- •9. Багатошарова архітектура програм
- •9. Cервіс-орієнтована архітектура (соа)
- •10. Короткий звіт
- •X. Реалізація
- •1. Характеристики етапу реалізації
- •2. Надійність програмного забезпечення
- •3. Похибка
- •4. Транзакції
- •5. Середовище реалізації
- •6. Чинники успіху і результати етапу реалізації
- •7. Короткий звіт
- •XI. Тестування
- •1. Етап тестування
- •2. Перевірка
- •Малюнок 11.3.1. Модель V-тестування.
- •3. Перегляди
- •4. Аудит
- •5. Інспекції
- •6. Види тестів
- •7. Процес тестування
- •8. Тестування надійності
- •9. Типи тестів на знаходження помилок
- •10. Програми-інструменти
- •11. Статичні тести
- •12. Підрахунок кількості помилок
- •13. Чинники успіху, успіх тестування
- •14. Короткий звіт
- •XII. Оцінка програмного забезпечення
- •1. Простановка розмірів проекту
- •2. Оцінка складності в проектах
- •3. Ефекти масштабування
- •4. Оцінка вартості програмного забезпечення
- •5. Конструктивна вартісна модель (cocomo)
- •6. Балова функціональна оцінка
- •7. Метод випадкового використання
- •8. Короткий звіт
- •XIII. Управління конфігурацією пз і версіями
- •1. Управління конфігурацією пз
- •2. Елементи конфігурації пз
- •3. Угода позначень
- •4. Зберігання елементів конфігурації
- •5. Перегляди
- •7. План управління конфігурації пз
- •I Вступ
- •II Управління
- •III Визначення конфігурації
- •IV Управління конфігурацією
- •4. Модель якості iso-9126
- •5. Управління якістю
- •6. Стандарти якості
- •7. Незрілість і зрілість виробництва
- •8. План гарантії якості пз (sqap)
- •9. Короткий звіт
- •XV. Управління проектом програмного забезпечення
- •1. Завдання управління проектом
- •2. Працівники виробництва програмного забезпечення
- •3. Характеристика хорошого розробника програмного забезпечення
- •4. Робота в команді
- •5. Управління підприємством по виробництву програмного забезпечення
- •6. Розвиток компанії по розробці програмного забезпечення
- •7. Документація проекту
- •8. Визначення продуктивності
- •9. Складання графіків проекту
- •10. Завдання управління проектом
- •11. Інтерфейс проекту
- •12. Планування проекту
- •13. Управління ризиком
- •14. Вимірювання процесів і продуктів
- •15. Короткий звіт
3. Похибка
Ніяка техніка не гарантує, що програма не матиме помилок. Похибка помилки означає, що програма працюватиме нормально навіть коли вона матиме помилки.
Тому програма повинна:
-
виявляти помилки;
-
відновлюватися після помилки, коректно завершуватися;
-
проводити корекцію помилок, тобто вносити зміни, щоб позбавитися від помилки.
Важливо провести діагностику помилки. Рядок коду, в якому відбулася помилка, повинен бути визначений.
Є два основні методи автоматичного виявлення помилок:
-
Перевірка коректності даних. Метод складається зі вставки додаткових рядків в код для того, щоб перевірити коректність даних.
-
Порівняння різних версій модулів.
Порівняння різних версій модулів
Порівняння різних версій модулів дає удосконалення надійності. Це застосовується тільки в особливих випадках, оскільки це вимагає великих інвестицій. Це використовується тільки для надзвичайно важливих програм.
Багатоваріантне програмування може бути реалізоване декількома способами:
Перший з них називається n-версії. Він розробляється n незалежними програмістами. Програми виконуються паралельно і результати порівнюються PCU. У разі розбіжності PCU вибирає правильний результат, наприклад, "голосування" використовується для ухвалення рішень. Службові дані для таких обчислень є важливим чинником. Проблема критично важлива для таких систем, як системи реального масштабу часу (Real Time Systems, RTS), для яких потрібно брати до уваги час реакції, наприклад, на погодні умови або кут нахилу літака.
Характеристики n-рівневого рішення паралельні, з одночасним відкриттям операцій над загальними даними декількома незалежними модулями.
Мал. 10.4.1.
Інше рішення - це програмування з допоміжними модулями. Метод припускає існування двох модулів, один з яких активний, а інший використовується для перевірки результатів активного модуля. Якщо виявляється будь-яка некоректність, додатковий операційний модуль замінює базовий модуль. Існують різні версії паралельних рішень.
Мал. 10.4.2
4. Транзакції
Транзакція - послідовність виконуваних операцій, які не може бути розділені і є одним цілим.
Транзакція складається з наступних операцій:
-
читання даних x транзакцією T,
-
запис даних x транзакцією T,
-
відміна транзакції T,
-
ухвалення транзакції T.
Транзакції використовуються для компактності і паралельних операцій.
Якщо виконуються багато процесів, компактність може не дотриматися і можуть виникнути помилки.
У таблиці 10.5.1. показана схема роботи двох процесів А і B, які використовують загальні дані.
Таблиця 10.5.1.
У Таблиці 10.5.1. показано два паралельні процеси, які не порушують компактність.
Таблиця 10.5.2.
У таблиці 10.5.2. показано два процеси, які порушують компактність.
Блок В не компактний. Є два процеси, які при незалежному виконанні дадуть результат 11. Відсутність синхронізації приведе до того, що один з процесів не буде оновлений.
Приклад: ми маємо 4 автори, які оновлюють тест. Якщо немає ніякого протоколу щодо оновлень, деякі виправлення можуть бути втрачені.
Транзакції роблять можливою підтримку сумісності процесів. Ручна синхронізація або угоди не потрібні.
Транзакції захищають від не повних виконань, які можуть з'явитися після збоїв.
Давайте представимо банківську систему з наступними операціями над рахунками клієнта F.
-
Клієнт читає магнітну картку і авторизується
-
Клієнт оголошує суму
-
Рахунок перевіряється
-
Залишок на рахунку зменшується на запрошувану суму
-
Посилається замовлення передачі
-
Касир знімає суму з рахунку
-
Касир проводить оплату
Питання полягає в тому, що трапиться, якщо між операцією 4 і 5 відбудеться відключення електрики. Рахунок зменшиться, клієнт не отримає грошей, фактичні дані втрачаються, директор скаже, що заяву слід писати електростанції, клієнт не погодиться і погрожуватиме позивом до суду і т.п.
Транзакції гарантують компактність даних і захищають проти апаратного збою, помилок ПЗ, проблем з персоналом і т.д.
Постулати ACID
Транзакція гарантує відновлення до стану перед виникненням помилки. Це - основна техніка для забезпечення надійності програмного забезпечення, що працює з базами даних.
Під транзакціями маються на увазі їх наступне властивості:
-
Атомарність – у всіх транзакціях виконується або одна операція, або нічого.
-
(C) Цілісність – якщо транзакція увійшла до цілісної бази даних, то поле її бази даних повинна теж залишитися цілісною.
-
Ізоляція – транзакція не знає про інші транзакції і не втручається в їх дії. Дії, що виконуються однією транзакцією, не повинні бути видимі іншим, поки не будуть отримані результати.
-
(D) Стійкість – після того, як транзакція завершиться, результати записуються на жорсткий диск і не можуть бути змінені випадковим чином, наприклад, відключенням електрики.
Транзакції в SQL
У SQL кожна транзакція починається з почати транзакцію (BEGIN TRANSACTION), і закінчується операцією фіксувати(COMMIT), що позначає правильне закінчення, або відкат (ROLLBACK) (або відміна (ABORT)), означає повернення до початкового стану (або відміну) транзакції.
Такі команди, як вибрати, вставити, відновити, видалити, створити запускають транзакцію, якщо вона ще не була запущена.
Транзакція виконується, поки виконуються команди фіксувати (підтверджуюча) або відкат(що перериває або повертає). Транзакція може виконувати такі команди, як видалити, створити, вставити, видалити, створити і т.д.
Приклад транзакції з командами відміна і фіксувати показаний на малюнку:
Мал. 10.5.3. Приклад використання транзакцій.
Застосування блокування і проблеми, пов'язані з ним
Транзакції вимагають застосування спеціальних модулів (планувальників) і протоколу обробки транзакциій.
Щоб уникнути проблем з розподіленою обробкою використовуються блокування.
Існує два типи блокувань:
Блокування X-типу – повністю блокує доступ до транзакції
Блокування S-типу - це блокування вирішує режим "тільки читання", але транзакцію не можна модифікувати.
У реляційній базі даних найчастіше використовується протокол двофазного блокування 2PL.
Правила приведені нижче:
-
Якщо операції pi(x) можуть виконуватися, блокування застосовується на транзакцію Ti і операція виконується. Якщо операція не може виконуватися, вона поміщається в чергу.
-
Видалення блокування виконується після завершення транзакції.
-
Якщо блокування було видалене з транзакції, транзакцію вже не можна заблокувати.
Згідно правилам є дві фази виконання транзакцій. У першій фазі ставляться блокування, а в другій вони віддаляються. Перша фаза довша другої.
Мал. 10.5.4. Протокол 2PL.
Застосування блокування може призвести до взаємного блокування і зависання. Використання блокування вимушує транзакцію дочекатися звільнення ресурсу. Давайте розглянемо три транзакції:
Транзакція А блокує ресурс X і вимагає доступу до ресурсу Y. Транзакція B блокує доступ до ресурсу Y і запрошує доступ до ресурсу X. Виходить взаємоблокування, і жодна з транзакцій не може завершитися.
Приклади блокувань показані на малюнку:
Мал. 10.5.5. Взаємоблокування транзакцій.
Мал. 10.5.6. Взаємоблокування транзакцій.
Взаємоблокування є серйозною проблемою і може вплинути на результат роботи.
Методи боротьби з взаємоблокуваннями:
Метод 1.
Виявлення взаємних блокувань і переривання циклу. Після виявлення взаємних блокувань слідує створення графа очікування і його транзитивне завершення (складність більша, ніж n*n). Переривання циклу відбувається шляхом видалення однієї з конфліктуючих транзакцій і її повторним запуском. Вибір грунтується на різних критеріях: остання, з найменшим робочим навантаженням, з низьким пріоритетом.
Метод 2.
Уникнення взаємних блокувань. Є багато таких методів, наприклад:
Попередній запит ресурсу: перед початком кожна транзакція визначає свої потреби. Зміни не вносяться. Недолік - падіння ефективності паралельного обчислення.
Чекай-помри (wait-die): якщо транзакція намагається дістати доступ до заблокованого ресурсу, вона відміняється. Це не застосовується до діалогових систем, оскільки користувач може бути збентежений потребою багатократного введення даних. Це зменшує продуктивність.
Часова відмітка і розбиття транзакцій
У обробках транзакцій застосовуються схеми, засновані на впорядкуванні до потрібної тимчасової відмітки. Кожній транзакції привласнюється унікальна часова відмітка, коли вона запускається. Часова відмітка визначає свою позицію в часовій послідовності в процесі виконання транзакцій. Впорядковування часових відміток засноване на конфліктах операцій і є дуже просте:
Запит транзакції на запис об'єкту буде допустимий тільки якщо об'єкт був прочитаний і записаний востаннє попередніми транзакціями. Запит транзакції на читання об'єкту можна відбутися тільки якщо об'єкт був востаннє записаний поперендньою транзакцією.
Це правило припускає, що є тільки одна версія кожного об'єкту, і обмежує доступ до транзакції за один раз. Якщо кожна транзакція має свої власні версії об'єктів, то багато транзакції можуть звернутися до об'єкту одночасно.
Проблема блокування також має відношення до розбиття. Розбиття проводиться тоді, коли визначено, яка транзакція повинна бути неподільною, щоб її не можна було заблокувати.
Розглядатися наступні рівні:
-
база даних,
-
відносини,
-
записи,
-
елементи запису,
-
індивідуальний атрибут,
-
фізичні аспекти пам'яті.
Великі частини розбиття можуть забезпечити захист, але вони мають не багато паралельних процесів. Маленькі ж вимагають багато блокувань і обслуговування.
Вірогідність системного відновлення від операційної аварійної відмови є тільки завдяки представленню операційного словника, в якому зареєстровані дані. Обробка транзакцій вимагає додаткового робочого навантаження і використання системи.
Принципи використання транзакційного словника і його реалізація на MS SQL знаходиться на CD-диску.
Нижче перераховані найважливіші механізми відновлення системи:
Мал. 10.5.7. Механізми відновлення після аварійної відмови.