Інформаційні системи і технології на підприємствах - Плескач В.Л. -
Класифікація САSЕ -засобів

Зупинимося на двох найбільш відомих варіантах класифікації САSЕ -засобів: за типами і категоріями. Класифікація за типами відображає функціональну орієнтацію САSЕ-засобів на ті чи інші процеси ЖЦ і включає такі типи:

o засоби аналізу і проектування, призначені для побудови й аналізу моделей діяльності підприємства, моделей проектної системи. До них належать BPwin, Silverrun, Oracle Designer, Rational Rose, Paradigm Plus, Power Designer, System Architect. Результатом таких засобів є специфікації компонентів системи та їхніх інтерфейсів, алгоритмів і структур даних;

o засоби проектування БД, що забезпечують моделювання даних і генерацію схем баз даних для найбільш розповсюджених СУБД. До них відносять Silverrun, Oracle Designer, Paradigm Plus, Power Designer. Найбільш відомий - ERwin;

o засоби управління вимогами, що забезпечують комплексну підтримку вимог до створюваної системи. Прикладами таких засобів є RequisitePro, DOORS - Dynamic Object Oriented Reqiurements System;

o засоби управління конфігурацією ПЗ - PVCS (Merant), ClearCase (Rational Software);

o засоби документування. Найбільш відомим із них є SoDA - Software Document Automation - для автоматизованого документування ПЗ (Rational Software);

o засоби тестування. Найбільш відомим засобом є Rational Suite TestStudio (Rational Software) - набір продуктів для автоматичного тестування застосувань;

o засоби керування проектом - Open Plan Professional (Welcom Software), Microsoft Project;

o засоби реверсного інжинірингу, що призначені для перенесення ПЗ у нове середовище. Вони забезпечують аналіз програмних кодів і схем баз даних і формування на їх основі різних моделей та проектних специфікацій. Засоби аналізу схем БД і формування ERD входять до складу таких CASE-засобів, як Silverrun, Oracle Designer, Power Designer, Erwin. Аналізатори програмних кодів є у складі Rational Rose, Paradigm Plus.

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

o концептуальне;

o архітектурне;

o технічне;

o детальне.

Концептуальне проектування полягає в уточненні розуміння й узгодженні деталей вимог; архітектурне проекту' вання - у визначенні головних структурних особливостей ІС; технічне проектування - у відображенні вимог середовища функціонування і розроблення ІС та у визначенні всіх конструкцій як композицій компонент; а детальне проектування - у визначенні подробиць функціонування та зв'язків для всіх компонент системи.

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

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

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

o помилки користувача при зверненні до системи чи під час підготовки даних;

o непередбачені обставини, не виявлені під час тестування;

o випадкові збої обладнання.

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

Щоб поновити працездатність системи, слід виконати один із наведених нижче варіантів робіт:

o поновити стан системи, що передував винятковій ситуації, і спробувати застосувати іншу стратегію виконання послуги;

o поновити попередній стан системи, внести необхідні корективи і повторити виконання послуги за старою стратегією;

o поновити попередній стан системи, сформувати повідомлення про помилку й зупинити систему в очікуванні реакції користувача.

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

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

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

Технології проектування ІС: канонічна та індустріальна. Остання буває представлена автоматизованим проектуванням або через типове проектування.

Типові способи обробки виняткових ситуацій:

o подвійне обчислення й порівняння результатів або їх контрольних сум, утому числі виконаних на різних процесорах;

o таймери, що визначають часові інтервали фіксації поточного стану;

o додаткові перевірки коректності даних, які передають зовнішні системи або окремі компоненти однієї системи.

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

3.3. Тестування програм та систем
3.4. Помилки та причини їх появи на етапах життєвого циклу
Команда тестувачів
3.5. Аналіз якості програмного забезпечення
3.6. Повторне використання компонентів ІС
Менеджмент розроблення ІС
3.7. Методологія створення ІС
Процеси життєвого циклу ІС
Етапи створення ІС
Документація на розроблення ІС