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

Размещено на http://www.allbest.ru/

Реферат / Abstract

Пояснювальна записка до випускної кваліфікаційної роботи бакалавра: 26 с., 13 рис., 20 джерел.

Метою роботи є розробка веб-застосування типу «соціальна мережа», яка дозволятиме в он-лайн режимі спілкуватися зареєстрованим користувачам.

Методи розробки базуються на мові програмування PHP, сервері системи керування базами даних MySQL і веб-сервері Apache.

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

ВЕБ-СЕРВІС, СОЦІАЛЬНА МЕРЕЖА, PHP, APACHE, ВЕБ-СЕРВЕР, MYSQL, HTML, ШАБЛОНІЗАТОР, РЕГУЛЯРНИЙ ВИРАЗ.

The aim is to develop a Web service such as "social network" which will allow online chat mode to registered users.

Methods of developing are based on the programming language PHP, a server database management system MySQL and Web server Apache.

As a result of work carried out by software implementation of a web communication system for registered users.

WEB SERVICE, SOCIAL NETWORK, PHP, APACHE, WEB SERVER, MYSQL, HTML, SHABLONIZATOR, REGULAR EXPRESSION.

Зміст

Вступ

1. Аналіз предметної галузі

2. Вибір програмних засобів

2.1 Вибір архітектури програмного забезпечення

2.2 Вибір програмних засобів

3. Розробка бази даних

4. Особливості реалізації

5. Тестування

6. Особливості застосування

Висновки

Перелік посилань

Додатки

Вступ

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

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

Переможний хід по Інтернету соціальні мережі почали в 1995 році з американського порталу Classmates.com («Однокласники» є його російським аналогом). Проект виявився дуже успішним, що в наступні кілька років спровокувало появу не одного десятка аналогічних сервісів. Але офіційним початком буму соціальних мереж прийнято вважати 2003-2004 роки, коли були запущені LinkedIn, MySpace і Facebook. І якщо LinkedIn створювалася з метою встановлення / підтримки ділових контактів, то власники MySpace і Facebook зробили ставку, в першу чергу, на задоволення людської потреби в самовираженні. Саме самовираження є найвищою потребою людини, випереджаючи навіть визнання і спілкування. Соціальні мережі стали свого роду інтернет-притулком, де кожен може знайти технічну і соціальну базу для створення свого віртуального «Я». При цьому кожен користувач отримав можливість не просто спілкуватися і творити, але й ділитися плодами своєї творчості з багатомільйонною аудиторією тієї чи іншої соціальної мережі. Але, у кожної є свої недоліки: деякі перевантажені контентом, деякі - навпаки, мають недостатню кількість контенту та функціонал. Саме тому, актуальність створення соціальних мереж не згасає.

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

1. Аналіз предметної галузі

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

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

b) телеконференції або групи новин. Телеконференції стали наступним етапом розвитку систем спілкування. Їх особливостями стали, по-перше, зберігання повідомлень і надання зацікавленим особам доступу до всієї історії обміну, а по-друге, різні способи угрупування повідомлень.

c) інтерактивні бесіди. З розвитком телекомунікації, все більша кількість користувачів починає працювати в Інтернеті в режимі постійної присутності, і як логічний розвиток цієї ситуації, з'являється сервіс спілкування в режимі реального часу, коли абонент отримує повідомлення на протязі незначного проміжку часу в межах декількох секунд після відправки його співрозмовником. Спеціалізований сервіс такого роду отримав назву Internet Relation Chat (IRC). В рамках цього сервісу спілкування проходить через спеціальні вузли в рамках загальних напрямів - каналів.

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

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

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

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

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

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

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

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

c) блоги (від англ. Web log - web-журнал, web-протокол). У цих сервісах кожен учасник веде власний журнал - тобто залишає записи в хронологічному порядку. Теми записів можуть бути будь-якими; найпоширеніший підхід - це ведення блога як власного щоденника. Інші відвідувачі можуть залишати коментарі на ці записи. У цьому випадку користувач, крім можливості вести свій журнал, отримує можливість організовувати стрічку перегляду - список записів з журналів "друзів" (friends), регулювати доступ до записів, шукати собі співрозмовників за інтересами.

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

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

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

c) крім облікових даних, користувач настроює оточення - зовнішній вигляд, додаткові дані про себе, указує свої інтереси.

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

Таким чином, спираючись на вище приведену інформацію, можна побудувати UML-діаграму прецедентів (Рис 1.1).

Размещено на http://www.allbest.ru/

Рисунок 1.1 - UML-діаграма прецедентів

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

2. Вибір програмних засобів

2.1 Вибір архітектури програмного забезпечення

спілкування сервер соціальний мережа

Для розробки такого веб-застосування, як соціальна мережа необхідно створити не просту систему. Вона повинна володіти такими властивостями, як:

- швидкість;

- надійність;

- безпечність;

- простота;

- масштабованість.

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

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

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

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

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

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

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

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

Рисунок 2.1 - Діаграма взаємодії між компонентами шаблону

Рисунок 2.2 - Схема архітектури клієнт-сервер

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

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

Сервер бази даних займає третій рівень багаторівневої архітектури клієнт-сервер. Він забезпечує зберігання даних. У даному випадку - це реляційна СУБД. Якщо третій рівень представляє собою базу даних разом з процедурами та тригерами й схемою, яка описує програму термінами реляційної моделі, то другий рівень будується як програмний інтерфейс, що пов'язує компоненти користувача з прикладною логікою бази даних.

Переваги багаторівневих моделей:

a) централізована бізнес-логіка. Як відомо, бізнес-логікою називають деякі правила обробки даних. Наприклад, видаляючи запис з однієї таблиці, потрібно видалити пов'язані з нею записи інших таблиць. У звичайних файл-серверних або клієнт-серверних додатках, частина бізнес-логіки лягала на клієнтську програму. При необхідності зміни якихось правил, доводилося переробляти клієнтський додаток, потім витрачати зусилля на його поширення на клієнтські ПК. Тепер же, ця бізнес-логіка зберігається на рівні сервера додатків, і при її зміні, клієнти відразу отримують можливість працювати за новими правилами.

b) архітектура "тонкого" клієнта. Як відомо, для отримання даних з БД, додатки використовують один з механізмів доступу до даних - BDE, ADO, ODBC, IBX, dbExpress і т.п. Все це призводить до того, що на ПК кожного клієнта доводиться встановлювати і налаштовувати відповідні драйвери, а це сильно ускладнює процес поширення програми. У багатоланкової архітектури механізми доступу до даних розташовуються на сервері додатків. Тільки там треба встановлювати ці драйвери (наприклад, BDE). Клієнтські ж машини не потребують їх, за що і називаються "тонкими".

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

d) зниження трафіку мережі. За рахунок можливості відкладеної обробки даних значно знижується навантаження на мережу.

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

Рисунок 2.3 - Багаторівнева архітектура клієнт сервер

2.2 Вибір програмних засобів

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

Можливих варіантів вибору веб-серверу було два: IIS, Apache. Вибір пав на Apache, який є самостійним, некомерційним, вільно розповсюджуваним продуктом. Підтримує безліч можливостей, багато з яких реалізовані як скомпільовані модулі, які розширюють основні функціональні можливості. Вони різняться від серверної підтримки мов програмування до схем аутентифікації. Існують інтерфейси для підтримки мов програмування Perl, Python, Tcl і PHP. У проекті використовується Apache 2.2.19

Сервер Apache створений на початку 1995 року співтовариством незалежних розробників «Apache Group», члени якої у свій час брали участь у проекті з побудови перших Web-серверів у NCSA (National Center for Supercomputer Applications, USA). «Apache Group» пропонує Web-сервери, сумісні з будь-якою UNІХ-системою, установленої на будь-якій апаратній платформі. Сервер перенесений і на інші операційні системи. Так, уже зараз Apache Web-сервер доступний для OS/2, UNІХ-платформ, Windows 2000 та ін.

Web-сервер Apache, як і всі інші Web-сервери, базується на ідеях і частині коду, реалізованих у першому по-справжньому популярному Web-Сервері - NCSA httpd 1.3.

Є два пояснення назви проекту. Згідно Apache Foundation, назву проекту було вибрано з поваги до корінного племені американського континенту апачів, що були відомі за свою витривалість та військову майстерність. Проте, перший FAQ на веб-сайті проекту Apache Server з 1996 до 2001 стверджував, що «назва „Apache“ походить від абревіатури „А PAtCHy server“, що дослівно перекладається як „залатаний сервер“ - сервер, у код якого внесений цілий ряд серйозних змін.» Перше пояснення було підтверджено на Конференції Apache і в інтерв'ю 2000 року з Брайаном Беглендорфом, який, тим не менш, спростував це твердження в інтерв'ю 2007 року, заявляючи, що «сервер Apache не названий на честь племені Джеронімо».

Версія 2 веб-серверу Apache була істотним переписом великої частини коду програми версії 1.x, з сильним нахилом на подальшу модульність та портативність. Версія 2.2 має гнучкіший API авторизації. Вона також включає поліпшені модулі кешу й проксі сервера.

Web-сервер Apache є самостійним, некомерційним, вільно розповсюджуваним продуктом. Продукт підтримує безліч можливостей, багато з яких реалізовані як скомпільовані модулі, які розширюють основні функціональні можливості. Вони різняться від серверної підтримки мов програмування до схем аутентифікації. Існують інтерфейси для підтримки мов програмування Perl, Python, Tcl і PHP.

Популярні методи стискування на Apache включають зовнішній модуль mod_gzip, створений для зменшення розміру веб-сторінок, переданих по HTTP.

Функції віртуального хостингу дозволяють одній інсталяції Apache обслуговувати різні веб-сайти. Наприклад, одна машина, з однією інсталяцією Apache може одночасно містити www.example.com, www.test.com, test47.test-server.test.com і так далі.

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

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

- типи файлів, які необхідно кешувати або навпаки, не включати в кеш;

- максимальний обсяг дискового простору, відведений під кеш;

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

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

Згідно статистики [2] Netcaft за червень 2008 року, Apache є найпоширенішим серверним програмним забезпеченням в Мережі: на цей веб-сервер припадала частка близько 49% відповідного сегменту ринку (майже 85 мільйонів сайтів). Друге місце за популярністю займають програмні платформи Microsoft - 35,4% (61 мільйон сайтів).

База даних - це дуже важлива частина для кожного веб-проекту. Усі важливі дані зберігаються саме в ній. СКБД обрати було тяжче, ніж веб-сервер, так як вибір значно більший. Та після довгих міркувань було вирішено користуватися СКБД MySQL. Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL - одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має підтримку з боку різноманітних мов програмування. У проекті використовується MySQL версії 4.1.16.

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

Проекти на основі безкоштовного ПЗ, які вимагають повнофункціональної системи керування базами даних часто використовують MySQL. До таких проектів відносяться, наприклад, WordPress, phpBB, Drupal та інше програмне забезпечення, побудоване на стеку продуктів LAMP (Linux, Apache, MySQL, PHP/Perl/Python). MySQL також використовується в багатьох гучних великомасштабних Web-продуктах, включаючи Wikipedia, Google (для програми AdWords), Facebook, YouTube, Flickr, Yahoo!, Digg, LiveJournal, Nokia тощо. MySQL - компактний багато потоковий (багатонитковий) сервер баз даних. Характеризується великою швидкістю, стійкістю і простотою використання.

Для некомерційного використання MySQL є безкоштовним. Можливості сервера MySQL:

- простота у встановленні та використанні;

- підтримується необмежена кількість користувачів, що одночасно працюють із БД;

- кількість рядків у таблицях може досягати 50 млн.;

- висока швидкість виконання команд;

- наявність простої і ефективної системи безпеки.

Історія mSQL (вона ж MiniSQL) - легка клієнт-серверна реляційна СУБД, що випускається компанією Hughes Technologies. Вперше випущена в 1994 році, вона заповнила вакуум утворився між вбудованими настільними СУБД типу Microsoft Accessі такими комерційними СУБД рівня підприємства як Oracleі DB2. З 1994 по 1997 рік її популярність росла і mSQL стала популярною серед open source розробників. При цьому початковий код самої mSQL не є відкритим.

З 1996 року розвиток mSQL загальмувалося, внаслідок чого її місце зайняла MySQL. У 1999 році MySQL обігнала mSQL за популярністю. Остання версія mSQL- 3.8 - була випущена 9 червня 2006.

MySQL виникла як спроба застосувати mSQL до власних розробок компанії: таблицям, для яких використовувалися ISAM - підпрограми низького рівня. У результаті був вироблений новий SQL-інтерфейс, але API-інтерфейс залишився в спадок від mSQL.

В січні-лютому 2008 Sun Microsystems придбала виробника системи керування базами даних MySQL за $1 млрд. Після поглинання у 2009 році Sun Microsystems з боку Oracle Corporation MySQL стала власністю Oracle.

Функціональність MySQL. Станом на квітень 2009 року, MySQL пропонує версію MySQL 5.1 в двох різних варіантах: з відкритим вихідним кодом MySQL Community Server і комерційний Server Enterprise. Вони мають спільний програмний код і включають в себе серед іншого наступні можливості:

- крос-платформна підтримка

- збережувані процедури та функції

- тригери

- курсори

- оновлювані подання (представлення)

- інформаційна схема (так званий системний словник, що містить метадані).

- підтримка SSL

- кешування запитів

- вкладені запити SELECT

- підтримка реплікації

- повноцінна підтримка Юнікоду (UTF-8 і UCS2)

- сегментування таблиць

- тощо.

Адміністрування СКБД MySQL найкраще проводити за допомогою програми phpMyAdmin.

phpMyAdmin - веб-застосунок з відкритим кодом, написаний на мові PHP, представляє собою веб-інтерфейс для адміністрування СКБД MySQL. phpMyAdmin дозволяє через браузер здійснювати адміністрування сервера MySQL, запускати команди SQL та переглядати вміст таблиць і баз даних. Система користується великою популярністю у веб-розробників, оскільки дозволяє керувати СКБД MySQL без безпосереднього вводу SQL команд, надаючи дружній інтерфейс, Рис. 2.4.



Рисунок 2.4 - Інтерфейс програми phpMyAdmin

Програма розповсюджується під ліцензією GNU General Public License і тому інші розробники інтегрують його у свої проекти, у тому числі у XAMPP та Denwer.

Експорт БД виконується за допомогою вкладки Експорт. Результатом буде дамп БД, Рис. 2.5, який являє собою набір SQL (DDL) інструкцій.

Рисунок 2.5 - Дамп БД

Щоб перенести БД на інший сервер необхідно виконати SQL-запит, тілом якого буде дамп бази даних.

Проводити розробку веб-сервісу було вирішено на мові програмування PHP. Велика різноманітність функцій PHP дають можливість уникнути написання багаторядкових призначених для користувача функцій на C або Pascal. Ця мова програмування має інтерфейси до більшості баз даних. важливою перевагою PHP є те, що ця мова належить до інтерпретованих. Це дозволяє обробляти сценарії з достатньо високою швидкістю. За деякими оцінками, більшість PHP-сценаріїв (особливо не дуже великих розмірів) обробляються швидше за аналогічні їм програми, написані на Perl. Проте, щоб не робили розробники PHP, виконувані файли, отримані за допомогою компіляції, працюватимуть значно швидше - в десятки, а іноді і в сотні разів. Але продуктивність PHP цілком достатня для створення цілком серйозних веб-застосунків. Саме цим і зумовлений мій вибір. У проекті використовується модуль PHP версії 5.2.1. PHP - мова, яка може бути вбудована безпосередньо в html-код сторінок, які, в свою чергу коректно будуть оброблені PHP -інтерпретатором. Механізм РНР просто починає виконувати код після першої екрануючої послідовності (<?) і продовжує виконання до того моменту, коли він зустріне парну екрануючу послідовність (?>).

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

Наявність інтерфейсів до багатьох баз даних в PHP вбудовані бібліотеки для роботи з MySQL, PostgreSQL, mSQL, Oracle, dbm, Hyperware, Informix, InterBase, Sybase, через стандарт відкритого інтерфейсу зв'язку з базами даних (Open Database Connectivity Standard - ODBC) можна підключатися до всіх баз даних, до яких існує драйвер.

Мова РНР здаватиметься знайомою програмістам, що працюють в різних областях. Багато конструкцій мови запозичені з С, Perl. Код РНР дуже схожий на той, який зустрічається в типових програмах на С або Pascal. Це помітно знижує початкові зусилля при вивченні РНР. PHP - мова, що поєднує переваги Perl і С і спеціально спрямована на роботу в Інтернеті, мова з універсальним і зрозумілим синтаксисом. І хоча PHP є досить молодою мовою, вона здобула таку популярність серед web-програмістів, що на даний момент є мало не найпопулярнішою мовою для створення веб-застосунків (скриптів).

Стратегія Open Source, і розповсюдження початкових текстів програм в масах, безсумнівно справили благотворний вплив на багато проектів, в першу чергу - Linux хоч і успіх проекту Apache сильно підкріпив позиції прихильників Open Source. Сказане відноситься і до історії створення РНР, оскільки підтримка користувачів зі всього світу виявилася дуже важливим чинником в розвитку проекту РНР.

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

Ефективність є дуже важливим чинником при програмуванні для середовищ розрахованих на багато користувачів, до яких належить і web. Важливою перевагою PHP є те, що ця мова належить до інтерпретованих. Це дозволяє обробляти сценарії з достатньо високою швидкістю. За деякими оцінками, більшість PHP-сценаріїв (особливо не дуже великих розмірів) обробляються швидше за аналогічні їм програми, написані на Perl. Проте, щоб не робили розробники PHP, виконувані файли, отримані за допомогою компіляції, працюватимуть значно швидше - в десятки, а іноді і в сотні разів. Але продуктивність PHP цілком достатня для створення цілком серйозних веб-застосунків.

Всі сценарії оформляються у вигляді блоків коду. Ці блоки можуть бути поміщені в HTML-код, але відділені від нього відповідними обмежувачами. Код PHP в HTML повинен знаходитись між початковим тегом <?php та кінцевим ?> (або між <script language="php"> та </script>) Бажаним варіантом виділення PHP коду є варіант <?php ?>, оскільки саме такі початковий та кінцевий теги дозволять використовувати PHP код в документах, які відповідають правилам XML. Також можна користуватися скороченим записом: <? ?> (інколи потрібно активізувати даний стиль внісши вручну зміни в файл php.ini: змінна short_open_tag повинна мати значення On) і записом в стилі ASP: <%%> (в php.ini змінна asp_tags повинна мати значення On). Проте стиль ASP не рекомендується і очікується, що він буде відсутній у PHP6.

3. Розробка бази даних

Розробка бази даних, дуже важливий етап у проектуванні програмного продукту, а особливо, веб-застосувань. Від бази даних залежить швидкість доступу до інформації, тобто її вилучення або додавання. Таблиці бази даних обов'язково повинні знаходитись у третій нормальній формі. Для реалізації дипломного проекту було розроблено базу даних, що містить шість таблиць: «Клієнти», «Інформація про клієнтів», «Фото», «Повідомлення», «Новини» та «Друзі». Кожна з них знаходиться у третій нормальній формі.

Рисунок 3.1 - Схема бази даних проекту

Тепер, подрібніше про кожну з них. Таблиця «Клієнти» (client_db), показана на Рис. 3.2, має у собі інформацію стосовно даних реєстрації користувача, тобто необхідних даних для авторизації на веб-сервісі. Ця таблиця виділена окремо, тому що кількість запитів до неї буде однією з найбільших. Таблиця містить поля «client_id» (ідентифікатор користувача), «email» (електронна пошта користувача), «client_pass» (пароль користувача). При чому поля ідентифікатора і електронної пошти обов'язкові для заповнення, так як фактично ідентифікують людину у системі. Правильність вводу даних у ці поля контролюється регулярними виразами. Ключем цієї таблиці виступає поле «client_id».

Рисунок 3.2 - Поля таблиці «Клієнти»

Таблиця «Інформація про клієнтів» (client_info) - найбільша таблиця бази даних, яка містить у собі основну інформацію про користувачів. Поля показані на Рис. 3.3. ЇЇ буде заповнювати саме користувач, частину під час реєстрації, а частину - після. Таблиця містить такі поля «client_id» (ідентифікатор користувача), «city_id» (ідентифікатор міста) «client_adrs» (адреса користувача), «client_places» (улюблені місця користувача), «client_name» (ім'я користувача), «client_nick» (прізвисько користувача), «client_contact» (контактна інформація), «city_name» (назва міста користувача). Поля «city_id» та «client_id» генеруються автоматично. Для заповнення обов'язкові дані «client_name» і «client_adrs». Назва міста «city_name» приймає значення автоматично. Ключі «city_id» та «client_id».

Рисунок 3.3 - Поля таблиці «Інформація про клієнтів»

Таблиця «Фото» (images), Рис. 3.4, виступає сховищем користувацьких фото, так званого «аватару». Вона виділена окремо, так як міститиме велику кількість даних. Таблиця містить всього два поля: «client_id» та власне фото «client_foto». Поле «client_foto» має тип даних MEDIUMBLOB - це байтовий тип даних, який дозволяє зберігати файли розміром до 16 мегабайт, повністю задовольняє призначення. Ключ - «client_id».

Рисунок 3.4 - Поля таблиці «Фото»

Таблиця «Друзі» (friends) - досить проста, адже має всього три поля: «friend_id» (ідентифікатор друга), «client_id» (ідентифікатор користувача), «friend_name» (ім'я друга). Жодне із полів не повинно бути пустим. Поля показані на Рис. 3.5. При додаванні користувача до списку друзів, дані із таблиці доданого друга «Інформація про клієнтів», а саме інформація полів «client_id» та «client_name» заповнює відповідні їм «friend_id» та «friend_name». Ключем виступає поле «friend_id».

Рисунок 3.5 - Поля таблиці «Друзі»

Таблиця «Повідомлення» (message), поля таблиці якої зображені на Рис. 3.6, призначена для зберігання приватних повідомлень користувачів. Вона містить ідентифікатор користувача, який отримав повідомлення («client1_id») та ідентифікатор користувача, який відіслав повідомлення («client2_id»). Ну і звичайно текст самого повідомлення («message»). Текст приватного повідомлення обмежено 200 символами. Ключем являється поле-ідентифікатор повідомлення «mess_id».



Рисунок 3.6 - Поля таблиці «Повідомлення»

Остання таблиця - це таблиця «Новини» (posts), Рис. 3.7. В ній знаходяться повідомлення, залишені на сторінці користувача. Тут зберігаються саме текстові повідомлення (поле «post_text»), їх ідентифікатори («post_id») та ідентифікатор користувача, який залишив повідомлення («client_id»). Текст повідомлення обмежений довжиною у 400 символів. Первинній ключ - поле ідентифікатора повідомлення «post_id».

Рисунок 3.7 ? Поля таблиці «Новини»

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

4. Особливості реалізації

Усі існуючі соціальні мережі не стоять на місці - вони розвиваються. Саме тому, при розробці веб-застосувань, потрібно враховувати можливі майбутні зміни коду будь-якої частини системи, а особливо дизайну та логіки програми. Таким чином було вирішено розробити таке програмне забезпечення, яке забезпечило б можливість одночасної розробки для дизайнера та програміста. Таким програмним забезпеченням являється шаблонізатор. Існують вже реалізовані шаблонізатори, але було вирішено розробити власний, так як він матиме ряд переваг. Наприклад, більшість готових шаблонізаторів, той самий Smarty, не підтримують повноцінну вставку коду PHP. З власноруч розробленим шаблонізатором отримуєш повний контроль над процесом відображення веб-сторінки.

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

Створений шаблонізатор працює на основі регулярних виразів. Фактично, за допомогую їх, шаблонізатор і шукає збіг шаблону з кодом html-сторінки. Наведу приклади використованих регулярних виразів:

a) define('PREG_FUNCTION','/\{\d*\s*[\w\s]*[\w\:\-\>\$]*\([\S]*\)\s*\}/');

b) define('PREG_FUNCTION_CALL', '/[^\d\s][\w*\:\-\>*]*/');

c) define('PREG_FUNCTION_QUEUE', '/^\s*[\d]*\s/');

d) define('PREG_FUNCTION_PARAMS', '/\([\S*\s*]*\)/');

e) define('PREG_FUNCTION_ADDITION', '/\s[\w]*\s/');

f) define('PREG_VAR', '/\{\s*\w*[\:*\-\>\$*\w*]*\s*\}/');

g) define('PREG_VAR_PARTS', '/\$*[\w]*[\:]*[\-\>]*/');

h) define('PREG_LOCALE', '/\{\d\d\d\d\d\d\}+/');

i) define('PREG_FILE', '/\{\|\w+.*/');

j) define('PREG_INSERT', '/\{\s*\w*\/\w*\s*\}/');

k) define('PREG_CODECHUNKS','/\{\&\&\&\*\&\&\d*\&\&\*\&\&\&\}/')

Перший регулярний вираз визначає функцію у шаблоні, тега виду «{phpinfo()}» або «{11 echo time()}» загального вигляду "{NNN AA CCCCC(PPPP)}". Наступні вирази детально розбирають знайдений тег:

a) «'PREG_FUNCTION_CALL'» - виклик функції (ССССС);

b) «'PREG_FUNCTION_QUEUE'» - порядковий номер виклику функції (NNN);

c) «'PREG_FUNCTION_PARAMS'» - параметри функції (PPPP);

d) «'PREG_FUNCTION_ADDITION'» - вставка перед викликом, наприклад «echo» (AA);

e) «'PREG_VAR'» - змінна у шаблоні; «'PREG_VAR_PARTS'» - розбиття змінної на частини;

f) «'PREG_LOCALE'» - вставка локалізованої змінної, тег виду «{123456}»;

g) «'PREG_FILE'», «'PREG_INSERT'» та «'PREG_CODECHUNKS'» - підключають файл темплейта.

Таким чином, ми отримуємо вхідні дані, для підстановки шаблону. Знаходимо потрібний шаблон, записуємо його у змінну:

$str = file_get_contents(DIR_VIEWS.$filename).

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

$str = preg_replace_callback(PREG_FILE, 'Compiler::insert_file', $str);

$str = preg_replace_callback(PREG_LOCALE, 'Compiler::insert_localized', $str);

$str = preg_replace_callback(PREG_VAR, 'Compiler::insert_var', $str);

$str = preg_replace_callback(PREG_FUNCTION, 'Compiler::insert_function', $str);

$str = preg_replace_callback(PREG_INSERT, 'Compiler::insert_insert', $str);

$str = Compiler::get_execute_code().$str;

$str = preg_replace_callback('/[\w\)][^;!?]*[\s]*\?\>/', create_function('$ce', 'return str_replace("?>", "; ?>", $ce[0]);'), $str);

$str = preg_replace('/\?\>[\s\z\Z\W]*\<\?php/', "\n", $str);

$str = preg_replace_callback(PREG_CODECHUNKS, 'Compiler::insert_codechunks', $str);

Compiler::$codechunks = array();

Compiler::$output = $str;

file_put_contents($file, Compiler::$output);

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

5. Тестування

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

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

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

a) модульне тестування тестує мінімальний компонент програми, або модуля. Кожний модуль тестується для перевірки правильності його реалізації.

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

c) системне тестування тестує інтегровану систему для перевірки відповідності всім вимогам.

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

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

f) альфа-тестування - це симульоване або реальне операційне тестування потенційними користувачами/замовником або командою тестувальників на боці розробника.

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

Тестування чорної і білої скриньки. У термінології професіоналів тестування (програмного й деякого апаратного забезпечення), фрази "тестування білого ящика" і "тестування чорного ящика" відносяться до того, чи має розробник тестів доступ до вихідного коду ПЗ, що тестується, або ж тестування виконується через інтерфейс користувача або прикладний програмний інтерфейс, наданий модулем, що тестується. При тестуванні білого ящика (англ. white-box testing, також говорять - прозорого ящика), розробник тесту має доступ до вихідного коду й може писати код, що пов'язаний з бібліотеками ПЗ, що тестується. Це типово для юніт-тестування (англ. unit testing), при якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції - працездатні й стійкі до певного ступеня.

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

Якщо "альфа-" і "бета-тестування" відносяться до стадій до випуску продукту (а також, неявно, до обсягу співтовариства, що тестує, й обмеженням на методи тестування), тестування "білого ящика" і "чорного ящика" має відношення до способів, якими тестер досягає мети.

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

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

Не можна писати код, який поєднує доступ до бази даних і логіку з обробки даних з бази даних. Це робить тести громіздкими, складними і повільними. Тому бізнес-логіку і доступ до бази даних потрібно розділяти на окремі класи і тестувати окремо.

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

Для тестування підключення до бази даних необхідна окрема база даних, відмінна від робочої.

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

Ще одним варіантів може бути єдина база даних, але для тестів передбачається використання таблиць із спеціальними префіксами, наприклад '_test_some_table'. Перевагою такого підходу є те, що тести в такому випадку можна проводити на хостингу. У нас такий підхід не прижився. Справа в тому, що деякі методи містять SQL-код, в яких назви таблиць вказані явно, плюс класи DBAL також часто явно містять імена таблиць.

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

<?php

class DBTableTest extends UnitTestCase

{

var $db = null;

function setUp()

{

$toolkit =& Limb :: toolkit();

$this->db =& new SimpleDB($toolkit->getDbConnection);

$this->_cleanUp();

}

function tearDown()

{

$this->_cleanUp();

}

function _cleanUp()

{

$this->db->delete('test1');

}

}

?>

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

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

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

<?php

class FeaturedOrdersDAO

{

function & fetch()

{

$toolkit =& Limb :: toolkit();

$db =& new SimpleDB($toolkit->getDbConnection());

$sql = 'SELECT * FROM orders';

$stmt =& $db->createStatement($sql);

$orders_rs =& stmt->getRecordSet();

$order_mapper = new OrderMapper();

$result = array();

for($orders_rs->rewind(); $orders_rs->valid(); $orders_rs->next())

{

$order_record =& orders_rs->current();

$order =& $order_mapper->map($order_record);

if($this->_passCriteria($order))

$result[] =& $order_record;

}

return new PagedArrayDataset($result);

}

function _passCriteria($order){ //some complex logic }

}

?>

Уявімо, яким буде виглядати тест на даний клас. Необхідно буде занести кілька записів у базу даних, перевірити, як працює метод _passCriteria () для різних замовлень, при цьому OrderMapper повинен працювати як годинник. Тестування бізнес-логіки, як правило, пов'язано з різними умовами (пам'ятаємо про пору року), тому тестових методів може бути багато. Схематично, тест буде виглядати так:

<?php

class FeaturedOrdersDAOTest extends UnitTestCase

{

function setUp()

{

$this->_cleanUp();

$this->_loadOrders();

}

function tearDown()

{

$this->_cleanUp();

}

function testManyDifferentOrderForWinter(){}

function testManyDifferentOrderForSummer(){}

function testManyDifferentOrderForSpring(){}

}

?>

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