Інформаційно пошукова система аптеки

Автор работы: Пользователь скрыл имя, 19 Декабря 2013 в 15:44, курсовая работа

Краткое описание

Мета курсового проекту – розробити архітектуру і компоненти програмного комплексу на основі методів стеганографії для захисту авторських прав.
Предметом розробки є програмний продукт програмного комплексу на основі методів стеганографії для захисту авторських прав.
Об’єктом розробки курсового проекту є інформаційна система, яка формує захист авторських прав на основі методів стеганографії.

Содержание

Вступ 5
1 Дослідження предметної області 6
1.1 Характеристика функціональної структури предметної області. 6
1.2 Аналіз останніх публікацій, досліджень та існуючих рішень. 8
1.3 Постановка задачі та перелік задач для реалізації. 11
2 Розробка архітектури програмної системи 13
2.1 Вибір типу архітектури та зразків проектування. 13
2.2 Опис декомпозиції. 15
2.3 Опис залежностей. 19
2.4 Опис інтерфейсу. 21
3 Детальне проектування. 23
3.1 Детальне проектування модулів. 23
3.2 Детальне проектування даних. 27
Висновки 29
Перелік посилань 30

Прикрепленные файлы: 1 файл

Zapiska.docx

— 284.69 Кб (Скачать документ)
    1. Вибір типу архітектури та зразків проектування.

 

 

Аналізуючи типи архітектури для  нашого ПП вибиремо репозиторну архітектуру, яка побудована головним чином навколо даних. Більшість таких систем призначені для обробки транзакцій по відношенню до баз даних. Зобразимо її на рисунку 2.1.

Рисунок 2.1 –  Репозиторна архітектура

 

Після вибору архітектури переходимо до аналізу та вибору зразків проектування. Для порівняння візьмемо такі зразки проектування, як Observer(Спостерігач) та Iterator(Ітератор)[3].

Observer – поведінковий шаблон проектування. Визначає залежність типу «один до багатьох» між об'єктами таким чином, що при зміні стану одного об'єкта всі залежних від нього сповіщаються про цю подію. Ціль шаблону – забезпечити реакцію потрібних елементів на зміни в джерелі даних. Шаблон Спостерігач реалізований в численних бібліотеках і системах, включаючи майже всі інструментарії графічних інтерфейсів користувача. Структура цього шаблону проектування зображено на рисунку 2.2[4].

Рисунок 2.2 –  Устрій шаблону проктування Observer

 

Iterator — шаблон проектування, належить до класу шаблонів поведінки. Надає спосіб послідовного доступу до всіх елементів складеного об'єкта, не розкриваючи його внутрішнього улаштування. Можна використовувати шаблон Ітератор у випадках:

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

Структуру цього шаблону зображена на рисунку 2.3.

Рисунок 2.3 –  Структура шаблону проектування Iterator

Проаналізувавши ці зразки проектування, найбільш краще підійде зразок  проектування Iterator(Ітератор), оскільки він задовольняє вимоги ПП.

    1. Опис декомпозиції.

 

 

Архітектура ПП по захисту авторських прав за допомогою методів стенографії зображена на рисунку А.1.

Вона складається з окремих  компонентів, кожен з яких може бути розміщений як на окремому, так і  на одному комп’ютері:

  • З’єднувач;
  • Шифрувальний компонент;
  • Клієнт;
  • Сервер бази даних.

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

Рисунок 2.4 – Діаграма варіантів використання процесів З’єднувача

Клієнтська частина ПП – це орієнтований на користувача компонент, основним завданням якого є представлення інформації користувачу, відображення його дій та підготовка завдань для планувальника задач З’єднувача. Діаграма варіантів використання процесів представлена на рисунку 2.5. Клієнт містить у собі графічний інтерфейс, який складається з таких модулів: основний модуль, модуль інтерфейсів функцій, модуль звітів та модуль візуалізаторів. Діаграми варіантів використання процесів цих модулів зображені на рисунках 2.6-2.7.

Рисунок 2.5 – Діаграма варіантів використання процесів Клієнтської частини ПП

Рисунок 2.6 – Діаграма варіантів використання процесів модуля інтерфейсів

Рисунок 2.7 – Діаграма варіантів використання процесів модуля звітів

 

Шифрувальний компонент відповідає за ініціалізацію, запуск функцій шифрування на виконання та отримання результатів. Він зберігає задачі і разом з ними вхідну інформацію по кожному проекту, з яким працює користувач на даний момент. Цей компонент за командою з З’єднувача запускає на виконання обчислювальне ядро моделі, перетворює вхідну інформацію до формату, необхідного ПП, зберігає результати шифрування. Вхідні дані можуть бути отримані через інтерфейс користувача ПП. Алгоритм шифрування показано на рисунку 2.8. Діаграма варіантів використання процесів Шифрувального компоненту зображена на рисунку 2.9.

Рисунок 2.8 –  Алгоритм шифрування Шифрувального компоненту

Рисунок 2.9 – Діаграма варіантів використання процесів Шифрувального компоненту

 

Необхідна ПП база даних може знаходитись  як локальному сервері баз даних, так і на інших серверах баз даних. Доступ до даних, їх оновлення, видалення чи редагування, резервне копіювання відбувається через завдання, які надходять до З’єднувача з Клієнта.

Стани ПП по захисту авторських прав методами стеганографії відображені на рисунку 2.10.

Рисунок 2.10 – Діаграма переходів станів ПП по захисту авторських прав методами стеганографії

 

    1. Опис залежностей.

 

 

З’єднувач – головний компонент, який управляє всіма компонентами. Він надсилає команди задачам до Шифрувального компонента, надсилає вихідні параметри та результати  до Клієнтської частини, отримує вихідні параметри та результати завдань із Шифрувального компонента (Рисунок 2.11).

Рисунок 2.11 – Залежність між З’єднувачем, Клієнтом та Шифрувальним компонентом

 

Основний модуль компонента Клієнт управляє такими модулями, як модуль інтерфейсів, модуль звітів та модуль візуалізаторів. Їх залежність зображена на рисунку 2.12.

Рисунок 2.12 – Залежність між модулями пакету Клієнт

 

Залежність між станами у ПП по захисту авторських прав методами стенографії існує. Кожен стан залежить від тих станів в які ПП може перейти з нього.

    1. Опис інтерфейсу.

 

 

Загальна діаграма опису інтерфейсів З’єднувача, Клієнта та Шифрувального компоненту зображена на рисунку А.2.

Опис інтерфейсу пакета З’єднувач. Інтерфейс є необов’язковим пакетом. У його складі знаходиться клас ModCon, який реалізує інтерфейс Con(Рисунок 2.13).

Рисунок 2.13 – Діаграма класів інтерфейсу пакету З’єднувач

 

Опис інтерфейсу пакета Клієнт. Інтерфейс користувача моделі є необов’язковим пакетом, який виконується на Клієнті у модулі інтерфейсів моделей (Рисунок 2.14). У складі цього пакета є 2 основні класи :

  • клас ModView, що реалізує інтерфейс IView та збору вхідних параметрів від користувача в зручній для нього формі, коректності введених даних;
  • клас ModUserInterface, що уточняє AbstractUserInterface та призначений для перетворення об’єктів даних на чисельні дані і навпаки, для виклику функцій Клієнта, створення об’єктів класу ModView, надання та збору з нього даних.

Рисунок 2.14 – Діаграма Класів інтерфейсу пакету Клієнт

 

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

  • клас ModWrapper, що реалізує інтерфейс IModWrapper та призначений для роботи з деревом датаітемів, тобто перетворення вихідних датаітемів на чисельні дані, необхідні шифрувальному ядру, створення вихідних датаітемів на основі отриманих результатів, генерування повідомлень. Цей клас є атрибутом класу Shifr і тому зберігається і виконується на Шифрувальному компоненті;
  • клас ModEntrPoints, який уточнює абстрактний клас AbstractEntrPoints, виконується в окремому процесі і відповідає за зв'язок  з ModWrapper та обмін з ним чисельними даними, а також за роботу з динамічною бібліотекою, яка є шифрувальним ядром.

Рисунок 2.15 – Діаграма класів інтерфейсу пакету Шифрувального компоненту

  1.  Детальне проектування.

    1. Детальне проектування модулів.

 

 

Загальний алгоритм роботи ПП представлено на рисунку А.3. Діаграма послідовності дій між пакетами Клієнт, З’єднувач та Шифрувальний компонент зображена на рисунку А.4.

Пакет З’єднувач. Клас Планувальника містить методи отримання вхідних даних і планування виконання завдання шифрування. Клас бази даних містить методи запиту та вибірки даних. Клас вікна Планувальник містить метод надсилання вхідних даних до Шифрувального компонента. Діаграма послідовності дій пакету З’єднувач зображена на рисунку 3.1, діаграма класів – на рисунку 3.2.

Рисунок 3.1 – Діаграма послідовності дій пакету З’єднувач

Рисунок 3.2 – Діаграма класів пакету З’єднувач

 

Пакет Клієнт. Клас головного вікна програми містить у собі метод запуску режиму введення даних та метод вибору типу шифрування. Клас вікна обробки даних містить 2 методи: перевірка на коректність даних та редагування даних, якщо вони введені невірно. Клас вікна шифрування містить метод вибору типу шифрування. Клас вікна виведення містить метод виведення результатів. Діаграма послідовності дій в даному пакеті зоюражена на рисунку 3.3, а діаграма класів – на рисунку 3.4.

Рисунок 3.3 – Діаграма послідовності дій пакету Клієнтської частини

Рисунок 3.4 – Діаграма класів пакету Клієнт

 

Пакет Шифрувальний компонент. Клас Проект має 2 методи : створення та збереження. Клас Модель містить метод ініціалізацій та метод запуску. Клас Результат містить метод виконання. Діаграма послідовності дій цього пакету зображена на рисунку 3.5, діаграма класів – на рисунку 3.6.

Рисунок 3.5 – Діаграма послідовності дій пакету Шифрувальний компонент

Рисунок 3.6 – Діаграма класів пакету Шифрувальний компонент

 

Модулі пакету Клієнт. Клас модуля інтерфейсів містить метод відображення інтерфейсу. Клас модуля візуалізаторів містить метод відображення у прийнятій формі. Клас модуля звітів має метод формування звітів. Діаграма послідовності дій зображена на рисунку 3.7, діаграма класів – на рисунку 3.8.

Рисунок 3.7 – Діаграма послідовності дій модулів пакету Клієнт

Рисунок 3.8 – Діаграма класів модулів пакету Клієнт

 

    1. Детальне проектування даних.

 

 

Для представлення даних використовується структура класів об’єктів даних(DataItem), які зберігають чисельні дані, метадані та відносини між ними (Рисунок А.5). Таке дозволяє відображати вхідні дані і результати шифрування за допомогою типових візуалізаторів.

Кожен об’єкт даних реалізує інтерфейс IDataItem, що визначає операції, підтримувані всіма об’єктами даних. Абстрактний класс AbstractDataItem реалізує спільні функції інтерфейсу, які, при необхідності, можуть бути перевизначені в його нащадках. Основні операції можна розділити на 2 групи:

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

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

Об’єкт  даних повідомлень (MessageDataItem) призначений для збереження повідомлень від моделі із зазначенням часу, рівня та тексту повідомлення шифрування.

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

Часова  таблиця послідовність (TimeSeries) представляє собою таблицю, що завжди містить дату і час.

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

RiverElementsSeries, GeometryElementSeries наслідують ElementSeries і реалізують відповідно сітку та просторову структуру з комірками довільної форми.

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

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

 

Висновки

 

 

В данному курсовому проекті була розроблена архітектура та компоненти програмного комплексу на основі методів стенографії для захисту авторських прав.

Информация о работе Інформаційно пошукова система аптеки