­ підтримка традиційних технологій: від друкування листів замовлення і книги сумарного обліку до друкування всіх видів карток каталогу;

­ технологія використання штрих-коду на виданнях і читацьких квитках;

­ підтримка повних текстів, графічних даних та інших зовнішніх об'єктів, зокрема ресурсів Інтернету;

­ засоби для перекладу інтерфейсів іншими мовами;

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

­ широкі можливості для адаптації до умов роботи конкретної бібліотеки.

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

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

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

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

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

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 Головна діаграма класів

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

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

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

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

Cтворюємо головну діаграму класів, на якій представлені пакети системи (див. рис. 1.6).

Пакет Книги містить класи, що описують книги і їх атрибути.

Пакет Клієнти містить класи, що описують читачів.

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

Рисунок 1.6 - Головна діаграма класів системи

1.1.2.6 Детальна діаграма класів системи

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

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

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

­ Предмет - Книга (1 - 1..*);

­ Книга - Картка (1 - 1..*);

­ Картка - Рух (1 - 1..*);

­ Рух - Клієнт (1..* - 1);

Страницы: 1, 2, 3, 4