48862 (588615), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

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

1.1.2 Опис процесу діяльності

1.1.2.1 Сценарій роботи АРМ науково-технічної бібліотеки

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

• функціональность – додати нові можливості для користувача;

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

• можливість видаленого доступу до довідника через інтернет або локальну мережу.

Виходячи з цього, пропонується наступний сценарій роботи системи.

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

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

1.1.2.2 Вибір засобів проектування

Для успішного проектування необхідні три складових процесу: організація, нотація і інструмент [9].

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

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

• методологія швидкої розробки застосуватнь RAD (Rapid Application Development);

• методологія функціонального моделювання SADT (Structured Analysis and Design Technique);

• методологія моделювання даних IDEF;

• методологія RUP (Rational Unified Process);

• методологія екстремального програмування (XP).

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

Методологія Rational Unified Process структурована в двох напрямах:

• час (розділення життєвого циклу на фази і версії);

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

Робота над проектом складається з наступних часових етапів:

• задум - визначення загальної ідеї проекту;

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

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

• перехідний період - постачання продукту користувачам (виробництво, розповсюдження, навчання).

У розрізі компонентів процес ділиться на наступні стадії:

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

• визначення вимог до системи - виклад загальної ідеї системи сумісний з функціональними і нефункціональними умовами її роботи;

• аналіз і проектування - опис способів виконання системи на етапі реалізації;

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

• тестування - перевірка функціонування системи;

• впровадження - постачання системи кінцевим користувачам і їх навчання.

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

«Нотація виконує три функції:

• є мовою для опису взаємодій, які неочевидні або не можуть бути отримані безпосередньо з коду;

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

• пропонує конкретну форму, що допомагає людина міркувати про предметну область, а засобам моделювання утілювати описані ідеї» [8].

Уніфікована мова моделювання (Unified Modeling Language - UML) пропонує достатньо повну нотацію, яка розширюється при переході від аналізу до проектування.

Методи створення програмного забезпечення успішно підтримуються відповідними інструментами розробками (CASE - системами). Однією з найбільш розвинених систем такого роду є сімейство продуктів Rational Rose. Для побудови моделей при проектування програм також можна використовувати такі програми, як Microsoft Visual Modeler і Microsoft Visio, StarUML та досить багато інших програмних засобів

У дипломному проекті для проектування використовувається програма Microsoft Visio, як найбільш поширене середовище проектування різноманітних моделей.

1.1.2.3 Опис функцій, які автоматизуються

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

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

Рисунок 1.2 – Функціональна схема автоматизованого робочого місця науково-технічної бібліотеки

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

Основні функціональні вимоги до розроблюваного автоматизованого робочого місця зводяться до наступного:

• гнучкі можливості пошуку;

• можливість видаленого доступу;

• засоби захисту від несанкціонованого доступу.

Під гнучким пошуком розуміється наступний алгоритм пошуку:

• задане прізвище автора спочатку шукається в таблиці книг;

• якщо шуканого прізвища немає в списку, визначається назва книги по цій же таблиці;

• задане прізвище спочатку шукається в таблиці авторів;

• якщо шуканого прізвища немає в списку, виводиться повідомлення що пошук не дав результатів.

Під пошуком по класифікаторові розуміється наступне:

• кожна бібліотека має свою назву;

• користувач здійснює ієрархічний пошук потрібної йому книги шляхом послідовного вибору в сформованій ієрархічній структурі.

Під пошуком за зразком розуміється наступне:

• користувач указує текстовий зразок, пошук якого потрібно здійснити в довіднику;

• користувач указує, в яких структурах довідника потрібно шукати заданий зразок для пошуку (у заголовку, скрізь);

• користувач указує, де потрібно шукати заданий зразок (починається з, містить).

1.1.2.4 Діаграмма прецедентів

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

Актори - це користувачі, або інші системи, які унікальним чином взаємодіють з даною системою.

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

• Адміністратор - користувач, що здійснює налаштування і конфігурування системи;

• Оператор - користувач, що здійснює налаштування і конфігурування курсів;

• Читач (або клієнт) - користувач, що одержує існуючу в системі інформацію про книги та авторів.

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

У системі, що розробляється, повинні забезпечуватися наступні потреби:

• актор Адміністратор реєструється в системі, як користувач, що володіє відповідними правами доступу до даних;

• актор Адміністратор конфігурує систему;

• актор Оператор реєструється в системі, як користувач, що володіє відповідними правами доступу до даних;

• актор Оператор вводить і редагує дані в базі даних системи;

• актор Клієнт реєструється в системі, як користувач, що володіє відповідними правами доступу до даних;

• актор Клієнт виконує пошук необхідної йому інформації.

На підставі перерахованих потреб можна виділити наступні прецеденти:

• реєстрація в системі;

• конфігурація системи;

• введення і редагування даних;

• пошук даних.

Список акторів і прецедентів системи показаний на рис.1.3.

Рисунок 1.3 – Список акторів и прецедентів системи

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

Головна діаграма прецедентів системи приведена на рис. 1.4.

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

Діаграма дій оператора при редагуванні даних зображена на рис. 1.5. Оператор зобов'язаний ввести пароль. У разі невірного пароля редагування неможливе. У разі правильного пароля Оператор вводить всі необхідні дані, формує списки авторів та книжок.

Рисунок 1.4 – Головна діаграма прецедентів

Рисунок 1.5 – Діаграмма дій при редагуванні даних

1.1.2.5 Головна діаграма класів

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

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

Створюємо необхідні для системи класи: Автори, Книги, Клієнти, Картки, Рух книжок, Теми.

Переміщаємо класи у відповідні пакети: Книги, Кліенти, Рух.

Характеристики

Список файлов ВКР