Користанням рнр-сценаріїв та створена база даних „osbb db з використанням системи управління реляційними базами даних Mysql, яка ідеально інтегрується з рнр

Вид материала

Документы

Содержание 3. ПРОЕКТНИЙ РОЗДІЛ 3.1. Фази розробки OSBB System Опис та аргументування вибору застосованих технології при розробці OSBB System Вивчення РНР Вбудовані бібліотеки Проектування OSBB System Панель керування в «OSBB System» Таблиця “customer Набір класів необхідних для роботи програми OSBB System Дослідження ефективності системи OSBB System Функціональні Вимоги (Functional Requirements) Не функціональні вимоги (Non-Functional Requirements) Вимоги до Інтерфейсу (Interface Requirements) Security and Privacy Data Retention Error Handling Validation Rules 4. Дослідницький розділ

Подобный материал:

• Тема. Поняття про бази даних. Системи управління базами даних (субд) Мета, 35.04kb.
• План уроку: Порівняльна характеристика типів баз даних. Особливості реляційних баз, 83.01kb.
• Інтерфейс системи керування базами даних access. Створення бази даних. Таблиці. Запити, 156.05kb.
• Методичні рекомендації до вивчення теми 4 Державний стандарт освіти «Бази даних. Системи, 1008.1kb.
• Вступ. База даних у Access, 257.75kb.
• Системи управління базами даних (субд), 222.23kb.
• Лекція 21 "Інформатика та комп'ютерна техніка" Тема Бази даних та системи керування, 106.88kb.
• Урок 1 тема. Поняття про бази даних. Системи управління базами даних (субд) Мета: показати, 36.11kb.
• "Вычислительные системы" с применением программы pc virtual, 36.24kb.
• Затверджено, 191.24kb.

3. ПРОЕКТНИЙ РОЗДІЛ

3.1. Фази розробки OSBB System

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

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

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

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

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

2. Опис та аргументування вибору застосованих технології при розробці OSBB System

1. Бази даних. Переваги використання мови SQL
   

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

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

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

Для виконання операцій над відношеннями в СУБД існують спеціальні алгоритмічні мови.


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

Основні переваги напряму витікають з переваг клієнт/серверного підходу. Наприклад, просте підсумовування значень всіх полів без використання SQL приведе до пересилки всієї таблиці по мережі на машину клієнта. Після підсумовування таблиця фактично вже не потрібна і таке використання мережі є не раціональним. У випадку ж з SQL по мережі піде запит на сервер, сервер проведе підсумувування і поверне по мережі тільки отриману суму!

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

Загалом, список переваг, на які варто звернути увагу насамперед, можна представити в наступному вигляді:

• незалежність від конкретної СУБД;
  
• переносимість з однієї обчислювальної системи на іншу;
  
• наявність стандартів;
  
• підтримка з боку компанії Microsoft (протокол ODBC);
  
• реляційна основа;
  
• високорівнева структура, що нагадує англійську мову;
  
• можливість виконання спеціальних інтерактивних запитів:
  
• забезпечення програмного доступу до баз даних;
  
• можливість різного представлення даних;
  
• повноцінність як мови, призначеної для роботи з базами даних;
  
• можливість динамічного визначення даних;
  
• підтримка архітектури клієнт/сервер.
  

Всі перераховані вище чинники були причиною того, що SQL став стандартним інструментом для управління даними на персональних комп'ютерах, міні-комп'ютерах і великих ЕОМ.

2. Переваги використання мови РНР. ссылка скрыта MVC
   

РНР володіє множиною переваг в порівнянні з цими продуктами до яких належать:

Продуктивність

РНР виключно ефективний. Використовуючи єдиний недорогий сервер, можна обслуговувати мільйони звернень в день. Результати тестування опубліковані компанією Zend Tehnologies (ссылка скрыта) підтверджують більш високу продуктивність в порівнянні з конкуруючими продуктами.

Інтеграція з базами даних

РНР володіє вбудованою зв’язністю з багатьма системами баз даних (можна безпосередньо підключатись до баз даних PostgreSQL, mSQL, Oracle, dbm, Hyperware, Informix, InterBase, i Sybase). Використовуючи стандарт відкритого інтерфейсу зв’язку з базами даних ODBC можна підключитись до любої бази даних, для яких існує ODBC-драйвер.

Вартість

Пакет РНР є безкоштовний. Найбільш нову версію можна в любий момент абсолютно безкоштовно завантажити з ссылка скрыта.

Вивчення РНР

Синтаксис РНР заснований на інших мовах програмування, в першу чергу на С та Perl. Якщо ви вже знайомі з С,Perl чи С-подібною мовою такою як С++ чи Java, то майже відразу зможете ефективно використовувати РНР.

Переносимість

Пакет РНР можна використовувати під керуванням багатьох різних операційних систем. Код РНР можна створювати в середовищі таких безкоштовних Unix-подібних операційних систем, як Linux чи FreeBSD, комерційних версій Unix типу Solaris i IRIX, або різних версій Microsoft Windows.

Вбудовані бібліотеки

Так як РНР був розроблений для використання в Web він має багато вбудованих функцій для виконання корисних пов’язаних з Web завдань. З його допомогою можна „на льоту” можна генерувати Gif-зображення, підключатись до багатьох мережних служб, відправляти повідомлення по електронній пошті, працювати з cookie-наборами і генерувати PDF-документи.

Моде́ль-вид-контро́лер (або Модель-вигляд-контролер, ссылка скрыта Model-view-controller, MVC) — ссылка скрыта, який використовується під час проектування та розробки ссылка скрыта.

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

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

Архітектурний шаблон Модель-Вид-Контролер (MVC) поділяє програму на три частини. У тріаді до обов'язків компоненту Модель (Model) входить зберігання даних і забезпечення інтерфейсу до них. Вигляд (View) відповідальний за представлення цих даних користувачеві. Контролер (Controller) керує компонентами, отримує сигнали у вигляді реакції на дії користувача, і повідомляє про зміни компоненту Модель. Така внутрішня структура в цілому поділяє систему на самостійні частини і розподіляє відповідальність між різними компонентами.

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

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

2. Проектування OSBB System
   

Розроблене програмне забезпечення розділене на 2 частини : фронт-енд та бек-енд.

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

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

Ця частина система можна сказати основна , тому що якшо на деякий час виключити фронт-енд , то користувачі просто не можуть користуватись системою , але всі дані про них , послуги , нарахування оплати тощо – залишаться.

Бек-енд розділений на 5 розділів , які також мають свої підрозділи та можуть розширюватись до нижчих ієрархічних рівнів.

1. Панель керування в «OSBB System»
   

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

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

• Локалізація – дає змогу налаштувати макети , мови , країни , геозони , зображення;
  
• Модулі – цей розділ відповідає за підключення та налаштування модулів системи («Обліковий запис» , «Банер» , «Карусель» , «Google Talk» , «Інформація» , «Слайдшоу» , «Ласкаво просимо» тощо );
  
• Платежі – підключення платіжних систем;
  
• Пошта – відповідає за масове розсилання повідомлень мешканцям системи;
  
• Журнали помилок – розділ допомагає «виловлювати» адміністратору помилки які мали місце в роботі системи та усівати їх;
  
• Резервне копіювання – робить резервне копіювання БД;
  

Рис.3.3.1.1. Панель керування системи

2. Розділ «Майно» в «OSBB System»
   

Цей розділ відображає будинки , квартири , житлові та нежитлові

приміщення організації (Рис.3.3.2.1.) . Він також поділяється на 3 модулі :

• Будинки – керування будинками організації;
  
• Квартири – керування квартирами організації , задання зв`язків квартира-будинок;
  
• Нежитлове майно – керування нежитловим майном системи (паркінг , підвальні приміщення тощо ) яке є у власності організації та задає зв’язки квартира-майно.
  

Рис.3.3.2.1. Розділ системи «Майно»

3. Розділ «Адміністратори» в «OSBB System»
   

Цей розділ дозволяє керувати адміністраторами системи , групами

адміністраторів та мешканцями (Рис.3.3.3.1.). Також поділяється на 3 підрозділи:

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

Рис.3.3.3.1. Розділ системи «Адміністратори»

4. Розділ «Послуги» в «OSBB System»
   

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

Цей розділ розділений на 4 підрозділи :

• Послуги – дозволяє вносити нові послуги та редагувати.
  
• Тарифи – перегляд попередніх тарифів за послуги та внесення нових.
  
• Нарахування – нарахування вартості використаних квартирами та мешканцями послуг
  
• Оплати – перегляд здійснених мешканцями оплат
  

Рис.3.3.4.1. Розділ системи «Послуги»

5. Розділ «Звіти» в «OSBB System»
   

Цей розділ дозволяє формувати звіти по роботі системи , такі як суми

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

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

1. Mysql база даних «osbb_db»
   
2. Програма частина яка використовуючи MVC архітектуру складається з набору класів необхідних для роботи програми
   
3. Файли шаблонів та каскадні таблиці стилів (Сss)
   
4. Бібліотека Jquery
   
5. Java Script файли , які містять додаткові функції для роботи програми
   

2. Структура та призначення БД «osbb_db»
   

База даних „osbb_db” розроблена на MySQL та складається з 34 таблиць (рис. 3.4.1) . Нижче наведене призначення деяких основних з них :

• banner – таблиця керування зображеннями
  
• blog – таблиця новин
  
• customer – таблиця даних мешканців системи
  
• customer_ip – таблиця даних авторизацій мешканців
  
• ссылка скрыта – таблиця транзакцій користувачів
  
• extension – таблиця модулів
  
• flats – таблиця квартир
  
• houses - таблиця будинків системи
  
• information – таблиця інформаційних сторінок
  
• information_description – таблиця даних інформаційних сторінок
  
• language – таблиця мов системи
  
• layout – таблиця шаблонів
  
• rates – таблиця тарифів
  
• services - таблиця послуг системи
  
• services_charges – таблиця нарахувань послуг
  
• services_counting_types – таблиця лічильників послуг
  
• services_to_flat – таблиця зв`язків послуга-квартира
  
• setting – таблиця налаштувань системи
  
• user – таблиця даних адміністраторів системи
  
• user_group – таблиця груп адмыныстраторів
  

Рис. 3.4.1. Схема бази даних „osbb_db”



Таблиця “customer”

Поля:

• customer_id int(11)
  
• firstname varchar(32)
  
• middlename varchar(32)
  
• lastname varchar(32)
  
• email varchar(96)
  
• house_id int(11)
  
• flat_id int(11)
  
• telephone varchar(32)
  
• fax varchar(32)
  
• password varchar(40)
  
• newsletter tinyint(1)
  
• ip varchar(15)
  
• status tinyint(1)
  
• approved tinyint(1)
  
• token varchar(255)
  
• date_added datetime
  

Рис. 3.4.2. Структурна схема БД «osbb_db»

В реляційній базі даних існує три типи основних типи відношень. Їх класифікують в залежності від кількості елементів по кожну сторону відношення. Розрізняють відношення типу „один до одного”, „один до багатьох” та „багато до багатьох”.

Відношення „один до одного” означає, що одна стрічка в одній таблиці посилається на одну стрічку в іншій таблиці.

При відношенні „один до багатьох” одна стрічка першої таблиці посилається на декілька стрічок іншої таблиці.

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

2. Набір класів необхідних для роботи програми OSBB System
   

Програмна складається з таких директорій :

- admin

- catalog

- image

- system


Директорія «admin» призначена для зберігання в собі файлів , класів , моделей , шаблонів , які використовуються в адміністративній частині системи адміністраторами.

Всі класи , які використовуються в адміністративній частині знаходяться в піддиректорії «controller» директорії «admin» :

/admin/ controller /common/ - класи , які використовуються на всіх сторінках адміністративної частини (для дизайну , виведення повідомлення про авторизацію тощо) :

• ControllerCommonFileManager
  
• ControllerCommonFooter
  
• ControllerCommonForgotten
  
• ControllerCommonHeader
  
• ControllerCommonHome
  
• ControllerCommonLogin
  
• ControllerCommonLogout
  
• ControllerCommonReset
  
• ControllerCommonSidebar
  

/admin/controller/error/ - класи виведення помилок – повідомлення про незнайдену сторінку та повідомлення про обмеження прав доступу до контролера

• ControllerErrorNotFound
  
• ControllerErrorPermission
  

/admin/controller/extension/ - класи , які призначенні для розширення функціоналу (підключення інформативних сторінок , підключення модулів , підключення платіжних систем)

• ControllerExtensionContact
  
• ControllerExtensionInformation
  
• ControllerExtensionModule
  
• ControllerExtensionPayment
  

/admin/controller/localisation/ - класи призначені для локалізації системи ( налаштування шаблонів , керування фотографіями , вибір мови , країн тощо)

• ControllerLocalisationBanner
  
• ControllerLocalisationCountry
  
• ControllerLocalisationLanguage
  
• ControllerLocalisationLayout
  
• ControllerLocalisationZone
  

/admin/controller/module/ - класи модулів системи

• ControllerModuleAccount
  
• ControllerModuleBanner
  
• ControllerModuleCarousel
  
• ControllerModuleGoogleTalk
  
• ControllerModuleInformation
  
• ControllerModuleSlideshow
  
• ControllerModuleWelcome
  

/admin/controller/property/ - класи призначені для керування житловим та нежитловим майном організації :

• class ControllerPropertyFlats extends Controller
  
• class ControllerPropertyHouses extends Controller
  
• class ControllerPropertyOther extends Controller
  

/admin/controller/services/ - класи призначені для керування послугами які надаються мешканцям ( створення нових послуг , вказання місячних тарифів , здійснення нарахувань , огляд оплат та заборгованостей тощо ) :

• class ControllerServicesCharges extends Controller
  
• class ControllerServicesCounttypes extends Controller
  
• class ControllerServicesRates extends Controller
  
• class ControllerServicesServices extends Controller
  

/admin/controller/setting/ - адміністративні класи призначені для керування системою в цілому – налаштування системи , резервне копіювання системи , реєстрація помилок в журналі :

• class ControllerSettingBackup extends Controller
  
• class ControllerSettingErrorLog extends Controller
  
• class ControllerDesignLayout extends Controller
  
• class ControllerSettingSetting extends Controller
  

/admin/controller/user / - адміністративні класи цієї директорії призначені для управління користувачами системи , групами користувачів та мешканцями

• class ControllerUserCustomer extends Controller
  
• class ControllerUserUserPermission extends Controller
  
• class ControllerUserUser extends Controller
  

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

В під директорії «model» містяться файли моделей , що використовуються в системі. Всі класи моделей мають ту саму назву , що й контролери і оперують даними з БД «osbb_db». Список деяких моделей перераховано нижче :

• class ModelPropertyFlats extends Model
  
• class ModelPropertyHouses extends Model
  
• class ModelServicesCharges extends Model
  
• class ModelServicesRates extends Model
  
• class ModelServicesServices extends Model
  
• class ModelLocalisationBanner extends Model
  
• class ModelLocalisationLanguage extends Model
  
• class ModelLocalisationLayout extends Model
  
• class ModelUserCustomer extends Model
  
• class ModelUserUserGroup extends Model
  
• class ModelUserUser extends Model
  

Директорія «catalog» - це так званий фронт-енд системи . В цьому каталозі зберігаються файли , класи , моделі , шаблонів , які призначені для мешканців будинку. Структура яка використовується в цій частині системи практично та сама , що й в адміністративній частині .

2. Дослідження ефективності системи OSBB System
   

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

Використовуючи загальновідомі на загальноприйняті засоби та методи тестування , я розділив тестування по групам у відповідності до вимог – функціональні та не функціональні вимоги. Функціональні вимоги визначають що система повинна робити, а не функціональні вимоги визначають якою система повинна бути.

Функціональні Вимоги (Functional Requirements)

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


Не функціональні вимоги (Non-Functional Requirements)

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

Вимоги до Інтерфейсу (Interface Requirements)


Інтерфейс системи має бути інтуїтивно зрозумілим користувачу та приємним для роботи. Застосування білих , світло синіх нейтральних кольорів на мою думку забезпечують комфортну роботу з системою , користувачу легше орієнтуватись , адміністратору – не завдає незручностей довга робота з даними мешканців. Це також перевірено при ще одному тестуванні – введені особистих даних мешканців для визначення так званих «багів» в роботі системи «OSBB System».

Несхвалення більшості елементів форматування HTML, які використовувалися в HTML 4.0, означає, що навіть якщо браузери як і раніше підтримують їх, відповідно до рекомендації Консорціуму W3C вони не повинні більше використовуватися. Веб-дизайнерам рекомендується використовувати CSS (Cascading Style Sheets – каскадні таблиці стилів).

В системі використовуються каскадні таблиці стилів в таких файлах :

• /admin/view/stylesheet/stylesheet.css
  
• /catalog/view/theme/default/stylesheet/carousel.css
  
• /catalog/view/theme/default/stylesheet/ie6.css
  
• /catalog/view/theme/default/stylesheet/ie7.css
  
• /catalog/view/theme/default/stylesheet/slideshow.css
  
• /catalog/view/theme/default/stylesheet/stylesheet.css
  

Апаратні та програмні вимоги (Hardware/Software Requirements)


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

1. Персональний комп’ютер платформи IBM, оскільки під цю систему розроблена більшість програмного забезпечення.
   
2. Тактова частота процесора ПК для виконання даної задачі має бути принаймі не нижче 1 ГГц, для цього підійдуть ПК на базі процесорів Intel, або AMD.
   
3. Мінімальний об’єм оперативної пам’яті має бути не нижче 2 Гб.
   
4. Об’єм жорсткого диску повинен бути щонайменше 20 Гб.
   
5. ПК для виконання поставленої задачі повинен бути укомплектований кольоровим монітором SVGA розміром не менше 15".
   
6. Відеокарта з об’ємом відеопам’яті не менше 32 Мб для роботи з 32-бітним кольором при нормальній роздільчій здатності (мінімум 1024x768) і нормальній частоті кадрової розгортки (мінімум 85 Гц).
   
7. Стандартна 104-клавішна клавіатура для Windows95/98.
   
8. 2-клавішний маніпулятор “миша” PS/2 .
   

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

Серед програмних засобів, які були встановлені на ПК для проведення робіт можна назвати:

• для набору текстової інформації – текстовий редактор Microsoft Word, для створення формул і таблиць – Microsoft Equation 3.0;
  

• СУБД MySQL – для створення бази даних;
  

• PHP – для розробки сценаріїв та роботи з базою даних;
  
• Web – cервер Apache;
  
• Zend Studio 8 – для розробки ПЗ
  

Програма-браузер для перегляду web-документів, html-cторінок. Такими програмами можуть бути Internet Explorer, Opera, Mozilla Firefox , Google Chrome тощо.


Безпека та Конфіденційність ( Security and Privacy)
Розроблена система відповідає забезпечує конфіденційність особистих даних користувачів , оскільки доступ до них мають уповноважені адміністратори або групи адміністраторів. В свою чергу доступ до адміністративної частини системи є більш захищеним і доступ до нього має незначна к-сть осіб. Якщо система початково була правильно налаштована системним адміністратором ( підібраний складний пароль до БД , до сервера розташування , нерозголошувались та не передавались незахищеними методами паролі доступу) , то можна гарантувати значну безпеку недоступу до системи.


Надійність (Reliability)

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

Збереження даних ( Data Retention)

В системі «OSBB System» розроблений спеціальний модуль для збереження даних БД («osbb_db»). Використовуючи його , можна з легкістю та в будь-який потрібний час зробити резервне копіювання бази даних на локальний комп’ютер адміністратора , не втрачаючи інформаці. Модуль доступний за адресою Панель керування – Резервне копіювання.

Керування помилками ( Error Handling)
В системі «OSBB System» розроблений спеціальний модуль для керування помилками «Журнал помилок». Використовуючи його , можна відстежувати помилки , які виникають при роботі програми. Модуль доступний за адресою Панель керування – Журнал помилок.


Правила Перевірки ( Validation Rules)
В кожному модулі системи , в кожному розділі або сторінці де відбувається маніпулювання з даними – внесення , редагування , підраховування тощо , прописані правила які фільтрують некоректно введенні адміністраторами та користувачами дані , тим самим зменшуючи кількість помилкових та конфліктних ситуацій. Наприклад , в полях де мають вводитись лице цілі числа – виводиться помилка про неможливість збереження цього запису , перед внесенням даних до бази даних системи.

4. ДОСЛІДНИЦЬКИЙ РОЗДІЛ