Аналіз програмного забезпечення для документообігу

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

Програми для автономного друку дозволяють роздруковувати файли на принтері паралельно з виконанням іншої роботи на комп'ютері.

Сучасні системи програмування для персональних комп'ютерів зазвичай надають користувачеві досить потужні і зручні засоби для розробки програм. У них входять:

1. Компілятор, що здійснює  перетворення програм на мові  програмування в програму машинних  кодах, або інтерпретатор, який здійснює  безпосереднє виконання тексту  програми на мові програмування  високого рівня.

2. Бібліотеки програм, що  містять заздалегідь підготовлені  програми, якими можуть користуватися  програмісти.

3. Різні допоміжні програми, наприклад відладчики, програми  для отримання перехресних посилань.

Програма - це запис алгоритму розв'язання задачі у вигляді послідовності команд або операторів мовою, яку розуміє комп'ютер. Кінцевою метою будь-якої комп'ютерної програми є керування апаратними засобами [4, c. 85].

Для нормального розв'язання задач на комп'ютері потрібно, щоб програма була налагоджена, не потребувала доопрацювань і мала відповідну документацію.

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

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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

РОЗДІЛ 2

АНАЛІЗ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ДЛЯ ДОКУМЕНТООБІГУ

 

2.1. Аналіз програмного  забезпечення

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

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

Обов'язки архітектора:

• координація і керівництво процесом аналізу і проектування;
• визначення структури кожного архітектурного уявлення;
• здійснення архітектурного аналізу.

Обов'язки розробника:

• аналіз варіантів використання (їх реалізація);
• визначення обов'язків, поведінки, властивостей класів і зв'язків між класами;
• аналіз одного або декількох пакетів або підсистем [11, c. 65].

Розробник БД відповідає за модель даних (схему БД).

Рецензент оцінює рішення, прийняті в ході процесу і створені робочі продукти (документи).

Об'єктно-орієнтований аналіз включає два види діяльності:

• архітектурний аналіз;
• аналіз варіантів використання.

Архітектурний аналіз виконується архітектором системи і включає:

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

Угоди моделювання визначають:

• використовувані діаграми і елементи моделі;
• правила їх застосування;
• угоди з іменування елементів моделі;
• організацію моделі (пакети).

Угоди фіксуються у документі «Керівні вказівки з проектування» (Design Guidelines). Приклад угод:

1) Імена варіантів використання  повинні бути короткими дієслівними  фразами.

2) Для кожного варіанту  використання повинен бути створений  пакет Use-case Realization, який включає:

а) принаймні, одну реалізацію варіанту використання;

б) діаграму “View Of Participating Classes” (VOPC).

3) Імена класів повинні  бути іменниками, які відповідають, по можливості, поняттям предметної  області;

4) Імена класів повинні  починатися із великої букви;

5) Імена атрибутів і  операцій повинні починатися  з малої букви;

6) Складені імена повинні  бути суцільними, без підкреслень, кожне окреме слово повинне  починатися із великої букви.

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

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

Проектні механізми: враховують деякі деталі середовища реалізації, без прив'язки до конкретного середовища (наприклад, вибір між РСУБД і ООСУБД).

Механізми реалізації: залежать від конкретної технології, мови програмування, постачальника (Oracle, Sun або Microsoft).

Приклади механізмів аналізу:

1. Стійкість (persistency): елементи  моделі, які повинні зберігати  свій стан протягом тривалого  часу повинні бути визначені  як стійкі (для кожного стійкого  елемента визначаються його розмір  і кількість об'єктів, які зберігаються, терміни зберігання, механізми і  частотні характеристики доступу).

2. Інтерфейс з успадкованими  системами (legacy interface) - до цього механізму відносять всі елементи моделі, відповідальні за інтерфейс з успадкованою системою.

3. Безпека (рівні, правила, привілеї) - елементи, які забезпечують контроль доступу до системи.

4. Розподіл - елементи, які повинні бути розподілені по вузлах мережі [7, c. 32].

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

Пошук абстракцій за списком категорій:

1. Фізичні або матеріальні  об'єкти.

2. Процеси (транзакції) і  події.

3. Ролі людей, організації.

4. Абстрактні поняття.

Визначення абстракцій з текстових описів - виділення іменників з описів (наприклад, варіантів використання) і їх вибір як «кандидатів» на роль абстракцій.

Наступним етапом є формування початкового представлення архітектурних рівнів. Архітектурні рівні утворюють ієрархію рівнів представлення будь-якої великої системи. Майже у будь-якій системі можна виділити наступні рівні:

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

2. Бізнес-рівень, який включає  набір компонентів, специфічних  для конкретної предметної області.

3. Проміжний (middleware), куди входять незалежні вд платформи сервіси.

4. Системний, містить компоненти  обчислювальної і мережевої інфраструктури.

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

1. Рівні (Layers) - спосіб декомпозиції застосування на набір шарів, які відповідають різним рівням абстракції.

2. Модель-представлення-управління (Model-view-controller, M-V-C) - розділення застосування на три частини: дані і бізнес-правила; представлення для користувача; обробку даних.

3. Канали і фільтри (Pipes and filters) - шаблон архітектури системи для потокової обробки даних 

Зразок «Канали і фільтри» вирішує наступну проблему: Потрібно забезпечити перетворення безперервних потоків даних. При цьому перетворення інкрементні і наступне може бути почате до закінчення попереднього. Є, можливо, декілька входів і декілька виходів. Надалі можливе додавання додаткових перетворень.

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

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

1. граничні класи, які  є посередниками при взаємодії  із зовнішніми об'єктами.

2. Класи-сутності, які є  основними абстракціями (поняттями), розроблюваної системи.

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

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

1. Інтерфейс користувача (обмін інформацією з користувачем, без деталей UI - кнопок, списків, вікон).

2. Системний інтерфейс і апаратний інтерфейс (використовувані протоколи, без деталей їх реалізації).

Всі створені при аналізі даного варіанту використання класи аналізу поміщаються на діаграму VOPC (View Of Participating Classes).

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

1.Знання:

• наявність інформації про дані або обчислювані       величини;
• наявність інформації про зв'язані об'єкти.

2.Дія:

• виконання деяких дій самим об'єктом;
• ініціація дій інших об'єктів;
• окоординація дій інших об'єктів.

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