1.
Великотърновски университет “Св. св. Кирил и Методий”
Факултет “Математика и Информатика”
Дипломна работа
Тема: Отворена система за
управление на потребителите
Дипломант: Научен ръководител:
Невен Боянов Боянов доц. д-р Валентин Бакоев
сп.: „Математика и информатика”
фак. №: 15171
Велико Търново
2013

2.
Великотърновски университет “Св. св. Кирил и Методий”
Факултет “Математика и Информатика”
Задание
За разработване на дипломна работа на
Невен Боянов Боянов, фак. №: 15171,
сп.: „Математика и информатика“
Тема: Отворена система за управление на потребителите
Цел: Да се доразвие съществуващата вече система за управление на
потребителите разработена от дипломанта като се направи анализ на
нуждите от подобен вид системи и съвременните изискванията поставени
при изграждане на клиент-сървър приложения. Системата да служи като
база за изграждане на други системи изискващи управление на потребители,
на техните ресурси и на предоставяните им услуги. Да се предостави
възможност на трети страни да разработват системи базирани на настоящата
разработка.
Основни задачи:
• Изследване на необходимите теоретични постановки необходими за
развитието и усъвършенстването на системата.
• Преглед на съществуващи решения и помощни средства.
• Описание на компонентите на системата, проектиране на нови такива.
• Практическа разработка на обновените компонентите на системата.
• Прилагане на системата за разработка на реални продукти.
Обем на дипломната работа: 60-80 стр.
Основна литература:
• Learning PHP, MySQL, JavaScript, and CSS, O'Reilly Media [12];
• Programming PHP, O'Reilly Media [11];
• Apache 2 Pocket Reference -- For Apache Programmers & Administrators,
O'Reilly Media [1];
Срок за завършване и представяне: 11.02.2013 г.
Дипломант: Научен ръководител:
Невен Боянов доц. д-р Валентин Бакоев

3.
Отворена система за управление на потребителите
Съдържание
Увод..............................................................................................................................5
Глава 1. Теоретични постановки и изследвания...................................................9
1.1. Разработка на уеб-базирани клиент-сървър приложения........................9
1.2. Преглед на съществуващи решения..........................................................10
1.2.1 Отворени системи и системи с отворен код........................................10
1.2.2 Затворени системи.................................................................................12
1.2.3 OАuth системи.........................................................................................12
1.2.4 Други системи и решения.....................................................................12
Глава 2. Проектиране и разработка на приложението.......................................14
2.1. Предистория..................................................................................................14
2.1.1 Лицензно споразумение........................................................................14
2.2. Платформа за разработка...........................................................................14
2.2.1 Уеб сървър...............................................................................................14
2.2.2 Сървър за управление на база данни..................................................15
2.2.3 Език за програмиране...........................................................................15
2.2.4 Други средства за разработка...............................................................15
2.3. Основни принципи и концепции...............................................................16
2.3.1 База данни...............................................................................................16
2.3.2 Изходен код............................................................................................21
2.3.3 Интерфейси за достъп...........................................................................25
2.4. Слоеве в архитектурата на системата........................................................28
2.4.1 База данни и структура на базата данни............................................28
2.4.2 Библиотека за работа с база данни.....................................................29
2.4.3 Бизнес логика........................................................................................29
2.4.4 Инструментална библиотека...............................................................29
2.4.5 Сървърна библиотека и програмен интерфейс.................................29
2.4.6 Клиентска библиотека за връзка с програмния интерфейс...........30
2.4.7 Логика на клиентското приложение..................................................30
2.4.8 Потребителски интерфейс...................................................................30
2.4.9 Други клиентски библиотеки..............................................................30
Глава 3. Разработка на системата..........................................................................31
3.1. Структура на базата данни...........................................................................31
3.1.1 Таблици....................................................................................................31
3.1.2 Основни единици...................................................................................33
3.1.3 Релации...................................................................................................34
3.1.4 Процедури...............................................................................................35
Стр. 3

4.
Отворена система за управление на потребителите
3.1.5 Примерни данни....................................................................................35
3.2. Модул за работа с базата данни.................................................................37
3.2.1 Основни функции..................................................................................37
3.2.2 Допълнителни функции.......................................................................38
3.3. Бизнес логика на системата.......................................................................38
3.3.1 Удостоверяване......................................................................................38
3.3.2 Профили, типове и параметри............................................................38
3.4. Инструментална библиотека.....................................................................38
3.4.1 Удостоверяване......................................................................................39
3.4.2 Потребител.............................................................................................39
3.4.3 Профили.................................................................................................39
3.5. Програмен интерфейс.................................................................................39
3.5.1 Методи.....................................................................................................39
3.5.2 Групи от методи параметри.................................................................40
3.6. Клиентска библиотека.................................................................................41
3.7. Логика на клиентското приложение.........................................................41
3.8. Потребителски интерфейс..........................................................................41
3.9. Зависимости от външен код........................................................................41
3.9.1 Задължителни.........................................................................................41
3.9.2 Опционални...........................................................................................42
3.10. Достъп до изходния код............................................................................43
3.10.1 UMS........................................................................................................43
3.10.2 Допълнителни модули........................................................................44
Глава 4. Примерни разработки.............................................................................45
Заключение..............................................................................................................55
Използвана литература..........................................................................................56
Приложения.............................................................................................................57
Структура на базата данни.................................................................................57
Релации............................................................................................................57
Таблици............................................................................................................58
Основни функции...............................................................................................63
Функции за работа с база данни...................................................................63
Стр. 4

5.
Отворена система за управление на потребителите
Увод
В съвременните компютърни системи една от основните задачи при
изграждането им е управлението на ресурсите и режима на достъп до тези
ресурси. Това с особена сила важи при клиент-сървър системите. За да бъде
установен такъв режим е наложително съществуването на система за
управление на потребителите, която да лежи във фундамента на по обширна
система, която на свой ред, заедно с управлението на потребителите и
ресурсите, се грижи и за задачите за които е създадена.
Настоящата разработка разглежда основните аспекти на проектиране на
система за управление на потребителите както и практическата реализация
на една Отворена система за управление на потребители – за по кратко
наричана ОСУП.
Целите на разработката са да се доразвие съществуващата вече система за
управление на потребителите разработена от дипломанта като се направи
анализ на нуждите от подобен вид системи и съвременните изискванията
поставени при изграждане на подобен вид клиент-сървър системи и
приложения. Системата трябва да служи като база за изграждане на други
системи изискващи управление на потребители, на техните ресурси и на
предоставяните им от една такава система услуги. Трябва да има възможност
разработката да се предостави на трети страни с цел разработка на продукти
базирани на настоящата система.
Първоначалната разработката на ОСУП (под името UMS) е започната от
дипломанта през 2001 година с цел обслужване на нуждите на конкретен
проект. С течение на времето се обособяват отделни модули които на свой
ред прерастват в самостоятелни проекти. През 2004 година е първото по-
мащабно внедряване на системата, а през 2007 година е интегрирана в
продуктите на фирма Интерлекта където работи успешно и до днес
обслужвайки (към дата януари 2013 г.) над 420 000 потребители от цял свят.
В настоящия си вид отворената система за управление на потребители ОСУП
не е продукт сама по себе си, въпреки че има налични потребителски
интерфейси за ползване, както от администратори, така и от крайни
потребители. Това е по-скоро платформа за вграждане в други по-големи и
по-сложни системи.
ОСУП се разпространява като свободен софтуер с отворен код, което
позволява всеки да модифицира кода според нуждите си, както и да споделя
направените модификации. Подобен подход подпомага разработката на
Стр. 5

6.
Отворена система за управление на потребителите
системата и нейното усъвършенстване, ускорява процеса на откриване на
грешки и отстраняването им и най-важното – споделя дългогодишните
натрупаните знания и опит с общността заинтересована от разработката.
Системата ОСУП може да бъде инсталирана и да работи под операционната
система Linux и FreeBSD, но би могла да се ползва също и под Windows.
Последната версия на системата съдържа около 10 000. реда код, който е
оценен (по системата COCOMO) на 3 години работа. 1
Понастоящем (януари 2013) ОСУП системата, позната в Интернет като
UMS3, се използва в много комерсиални проекти по света, като общият брой
потребители регистрирани и ползващи услуги базирани на нея е почти 500
хил.
В частта Примерни разработки на стр. 45 са дадени примерни разработки
базирани изцяло или от части на ОСУП.
За постигане на целите поставени в тази разработка се обособяват следните
основни задачи:
• Изследване на необходимите теоретични постановки необходими за
развитието и усъвършенстването на системата;
• Преглед на съществуващи решения и помощни средства подпомагащи
усъвършенстването на системата;
• Описание на компонентите на системата, проектиране на нови
възможност и усъвършенстване на съществуващите;
• Практическа разработка на обновените компонентите на системата,
добавяне на нови възможности;
• Прилагане на системата за разработка на реални продукти.
Разработката е структурирана по следния начин: Увод, Глава 1. Теоретични
постановки и изследвания, Глава 2. Проектиране и разработка на
приложението, Глава 3. Разработка на системата, Глава 4. Примерни
разработки, Заключение, Използвана литература, Приложения.
Глава 1. Теоретични постановки и изследвания
Разгледани са основни постановки при разработване на клиент-сървър
системи и по-специално на такива базирани на свободен софтуер с отворен
код изградени върху платформата Apache/MySQL/PHP известна още като
1 Източникът на статистическия анализ на кода и разработката е системата Ohloh на
фирмата Black Duck Software, Inc., достъпна на адрес http://www.ohloh.net/p/ums3
Стр. 6

7.
Отворена система за управление на потребителите
AMP. В тази глава е направен също и кратък анализ за съществуващи
решения за управление на потребителите.
Глава 2. Проектиране и разработка на приложението
В тази глава е разгледан процесът на проектиране на приложението като се
започва с неговата предистория, датираща от 2001 г. Разгледани са
платформата за разработка AMP, а същи и други помощни средства за
разработка.
В тази глава са разгледани 3 много важни аспекта на проектирането на
системата ОСУП, а именно:
• проблеми при изграждане на сложни структури в база данни и
принципа „вертикална параметризация“;
• проблеми при разработката и поддръжката на средно големи и големи
проекти и две решения, или концепции: „отделяне на проблемите“ и
„процедурно инжектиране на зависимостите“;
• управление на привилегиите за достъп в една система за управление
на потребителите и концепцията PSU (public/shared/user) за
постигането на тази цел.
Друг аспект на проектирането, който е засегнат в тази глава е интерфейсите
за достъп до системата: от потребителите и от външни системи или известни
още като API (application program interface) и основни принципи при тяхното
изграждане.
На последно място, но не най-маловажно, се дискутират на високо ниво
слоевете в архитектурата на системата.
Глава 3. Разработка на системата
Тук се разглеждат практическите аспекти на разработката, а именно:
• Структурата на базата данни и релациите между таблиците. Модулите
за работа с базата данни и други помощни модули;
• Бизнес логиката на системата, инструменталната библиотека и
програмните интерфейси;
• Клиентските програмни интерфейси, елементите на потребителския
интерфейс и зависимостите от външни библиотеки и модули.
• Предоставена е и информация за достъпа до целия изходен код.
Глава 4. Примерни разработки
Стр. 7

8.
Отворена система за управление на потребителите
В тази глава се разглеждат системи, продукти и проекти, които са базирани
на ОСУП системата. Изброени са комерсиални продукти, заедно с техните
параметри и област на положение.
Заключение
В заключение е направено кратко обобщение на целия процес на разработка,
и на постигнатите цели, а също така и поставени задачи за бъдещи
разработки.
Използвана литература
Приложения
В приложенията са представени в табличен вид структурата на базата данни,
а също и списък с най-важните функции имплементирани в системата.
Стр. 8

9.
Отворена система за управление на потребителите
Глава 1. Теоретични постановки и
изследвания
Кратък анализ на процеса на разработка на клиент-сървър базирани системи
както и преглед на съществуващи решения подобни на ОСУП.
1.1. Разработка на уеб-базирани клиент-сървър
приложения
Моделът клиент-сървър е подход в разработката на мрежов софтуер
разработен в лабораториите Xerox PARC през 1970. Днес той е широко
разпространен в компютърни мрежи - Email, World Wide Web и много други
прилагат модела клиент-сървър.
Според технологията на всяка машина в мрежата се възлага една от двете
роли: клиент или сървър. Сървърът представлява компютърна система,
която избирателно споделя нейните ресурси; клиентът е компютър или
компютърна програма, която инициира контакт със сървър, за да осъществи
използването на даден ресурс. Данни, процесори, принтери и устройства за
съхранение на данни са някои от примерите за ресурси.
Независимо дали компютърът е клиент, сървър или и двете, той може да
изпълнява множество функции. Например, един компютър може да работи
като уеб сървър или файлов сървър и в същото време да предоставя
различни данни на клиенти или пък да изпълнява различни видове заявки
към база данни. Клиентският софтуер може да комуникира със сървърния
софтуер на един и същ компютър.
Структурата на една уеб-базирана клиент-сървър система се изгражда на
основата на посочените по-горе принципи. Много често, особено в случаите
когато е необходимо да се пестят ресурси, всички необходими сървърни
приложения: база данни, уеб сървър и т.н., работят на една машина.
Клиентските приложения от друга страна са разположени на множество
отдалечени машини. Получава се мрежова система с топология тип звезда.
Сървърната част на една уеб-базирани клиент-сървър система съдържа като
минимум 3 компонента: уеб сървър, сървър за база данни и скрипт език.
Клиентската час в повечето случаи представлява работна станция, на която е
инсталиран уеб браузър.
Стр. 9

10.
Отворена система за управление на потребителите
В някои случаи клиентската част може да бъде специално за целта написано
приложение – било то за настолен компютър или друго устройство –
например мобилно устройство свързано към Интернет.
Повече техническа информация за изграждане на клиент-сървър
платформата е налична в Глава 2. Проектиране и разработка на
приложението и по-точно в частта Платформа за разработка на стр. 14.
1.2. Преглед на съществуващи решения
Разгледани са съществуващи системи, които реализират управление на
потребителите и ресурсите свързани с тях в най-различни аспекти.
Приоритет е даден на тези, които са отворени или с отворен (свободен) код.
Отворените системи и тези с отворен код имат редица предимства. Това са:
• споделяне на знанията и опита на разработчика с общността
заинтересувана от конкретната разработка;
• ползвателите имат възможност да както да отстраняват проблеми в
системата така и да внасят подобрения;
• възможност общността да участва в разработката и усъвършенства-
нето на продукта.
1.2.1 Отворени системи и системи с отворен код
Сравнение е направено предимно на системи базирани на Apache, MySQL,
PHP комбинация позната още като AMP (LAMP в Linux среда , WAMP в
Windows среда). 2
UserCake
Система базирана на Apache, MySQL, PHP. [15]
Usercake е сравнително лесна за използване и надеждна система за
управление на потребителите в Интернет. Според авторите си Usercake е
написана придържайки се към четири основни принципи: да е просто,
гъвкаво, бързо и преди всичко надеждно. Usercake е напълно с отворен код.
2 Търсене в Google на термините "user+management+system", директна връзка:
https://www.google.com/search?q="user+management+system".
Стр. 10

11.
Отворена система за управление на потребителите
Deadlock
Deadlock е продукт с отворен код за управление на потребителя написан на
PHP/MySQL и лицензиран под GNU GPL. [3]
Той използва htpasswd и htaccess файлове за защита на уеб директории.
Инсталацията и настройката са изключително лесни за използване с
помощта на скрипта за настройка. Deadlock не изисква специален код, за да
бъдат добавени към страници, като повечето други подобни системи.
Позволява да се защитят с парола цели директории, които са в рамките на
основната директория на уеб сървъра, което е много подходящо за защита на
всякакъв тип файлове, включително HTML страници, изображения или
други документи.
Generic User Management System
Това е система за управление на потребителите с общо предназначение,
създадена с идеята да се вгражда в други продукти, а също така да се
разширява с цел изграждане на по-сложни системи. [7]
The Efficient User Management System
Напълно автоматизирана система за управление на потребителите [5].
Тя събира и актуализира автоматично данни от една или повече системи и
намалява времето за дългите административни задачи. Системата генерира
единна база данни, която синхронизира информация с други системи за бази
данни. По този начин поддържа един потребител, който е синхронизиран с
всички системи. Системата е изградена около основен модул и други под-
модули, които могат да се комбинират според желанията и нуждите на
потребителите.
Solid PHP User Management System
С този продукт лесно може да се изгради цялостна система за управление на
потребителите за съществуващ вече уеб сайт или да създадете нов сайт чрез
модифициране на готова и лесна за надстрояване система [13].
Продуктът използва защитени интерфейси за комуникация с базата данни,
надежден HTML за предотвратяване на XSS атаки и алгоритми за кеширане.
Стр. 11

12.
Отворена система за управление на потребителите
1.2.2 Затворени системи
Съществуват голям брой затворени корпоративни системи и решения за
управление на потребителите, които предоставят голям брой възможности.
Поради затвореният им характер и невъзможността да се установят
значителна част от техните характеристики подобни системи не са сравнени
тук.
1.2.3 OАuth системи
През последните години широка популярност придобиха он-лайн услугите
предоставящи достъп по OAuth протокола. [8] [22]
По-долу са разгледани някои от най-популярните.
Facebook
Предоставя възможност за вписване (sign-in) и за изтегляне на информация
за потребителя. [6]
Модификации могат да се правят само от уеб-сайта на Facebook.
Twitter
Предоставя възможност за вписване (sign-in) и за изтегляне на информация
за потребителя. [14]
Модификации могат да се правят само от уеб-сайта на Twitter.
Други
Други системи които позволяват OAuth достъп или подобен са Google, Live,
OpenID, LinkedIn и много други.
1.2.4 Други системи и решения
Съществуват много други отворени системи за управление на потребителите
който предоставят най-различни възможности за управление на
потребителите и свързаните с тях ресурси.
Стр. 12

13.
Отворена система за управление на потребителите
LDAP системите за управление
Системите работещи с протокола LDAP за отдалечено управление на
справочна информация на практика са клиенти-сървър приложения, чиято
клиентска част се свързват с далеч по-мощни сървърни системи. [21]
Пример за популярен клиент е Apache Shiro проектът, който поддържа
широк набор от протоколи за комуникация и възможности.
Съществуват отворени OpenLDAP сървърни решения, но тяхното подробно
разглеждане е отвъд целите и задачите на настоящия проект. [20]
CMS системи
Системите за управление на съдържание (известни като CMS – content
management systems) предлагат свои решения за управление на
потребителите. Те са подходящи ако се работи в рамките на конкретната
система: ако се разработват добавки за нея, например. В някои случай е
възможно подобни система да се използва и от други приложения, но това
обикновено се затруднява от спецификата на разработка, тъй като модулът
за управление на потребителите се разработва преди всичко за да обслужва
конкретните нужди на дадената система за управление на съдържанието.
Примери за подобни системи са Drupal, WorkdPress, Joomla и мн. др. [19]
Други
Съществуват много други решения за управление и удостоверяване в мрежа.
Например Kerberos, които предлагат минимални средства за работа с
потребителски данни, е по-скоро насочен към сигурността и криптирането
на данните. [18]
Стр. 13

14.
Отворена система за управление на потребителите
Глава 2. Проектиране и разработка на
приложението
ОСУП е софтуер разработван в продължение на повече от 10 години.
2.1. Предистория
Разработката на ОСУП, под името (UMS) беше започната през 2001 година с
цел обслужване на нуждите на конкретен проект. С течение на времето се
обособиха отделни модули, които на свой ред прераснаха в самостоятелни
проекти: създадоха се принципи и концепции за разработка на системи
базирани на ОСУП. През 2004 година започна внедряване на системата в по-
мащабни проекти и през 2007 година беше интегрирана в продуктите на
фирма Интерлекта, където работи успешно и до днес обслужвайки (към дата
януари 2013 г.) над 420000 потребители от цял свят.
2.1.1 Лицензно споразумение
Системата на управление на потребители (ОСУП или UMS) се разработва и
разпространява под лиценз за свободен софтуер с отворен код.
2.2. Платформа за разработка
Изключително важна част от разработката на сложна система от тип клиент-
сървър е изборът на подходяща платформа. За Системата за управление на
потребители това са: уеб сървър, система за управление на база данни, език
за програмиране и други помощни средства за разработка.
2.2.1 Уеб сървър
Apache
Apache е HTTP сървър и един от най-популярните такива. Позволява
ползването на различни скрипт езици за програмиране (като PHP) за
създаване на динамични уеб-базирани системи [2]. Основно предимство е
възможността да обработва големи количества входящи заявки.
Стр. 14

15.
Отворена система за управление на потребителите
Apache е свободен софтуер с отворен код и позволява ползването му както в
лични така и в комерсиални разработки.
2.2.2 Сървър за управление на база данни
MySQL
MySQL е сървър за управление на релационна база от данни и предлага
необходимите възможности и параметри за разработка на системата [9].
Като предимство може да се изтъкне факта, че е съвместим със стандарта
SQL, но същевременно предлага и редица разширения на стандарта които
улесняват разработката на приложения базирани на този сървър.
MySQL е свободен софтуер с отворен код, лицензното му споразумение
позволява ползването му както в лични така и в комерсиални разработки.
2.2.3 Език за програмиране
PHP
PHP е програмен език с отворен код за създаване на уеб-базирани
динамични системи. Той е един от първите сървърни скриптови езици за
вграждане директно в HTML кода, вместо извикване на външен изпълним
файл от тип CGI. [10]
PHP е свободен софтуер с отворен код, лицензът му позволява вграждането
както в лични така и в комерсиални разработки.
2.2.4 Други средства за разработка
HTML
Hypertext Markup Language (HTML) е основният език за създаване на уеб
страници и представяне на информация в Интернет. Визуализира се
предимно в уеб браузър.
Последната версия на стандарта на този език е 5. [17]
Стр. 15

16.
Отворена система за управление на потребителите
JavaScript
JavaScript е скриптов език с отворен код, ползван най-често в средата на уеб
браузър. Подходящ е за създаване на по-добри потребителски интерфейси и
динамични уеб сайтове.
JavaScript е формализиран в стандарт ECMAScript. [4]
CSS
Cascading Style Sheets е език за описване визуалното представяне на
документ написан на HTML. Това позволява разработката на софтуерни
продукти с модерен и динамичен дизаин.
Cascading Style Sheets езика е стандартизиран от W3C консорциума. [16]
2.3. Основни принципи и концепции
По време на проектирането и разработката на ОСУП бяха разработени
различни теоретични концепции по-важните, от които са разгледани по-
долу.
2.3.1 База данни
Проблеми при изграждане структурата на базата данни
Нека да разгледаме един типичен пример за изграждане на база данни –
потребители и тяхната лична информация.
Входни данни: име – собствено и фамилно, дата на раждане, телефон, мейл
адрес.
Таблицата която бихме създали за целта би изглеждала така:
Field Type Null Default Links to
profileid int(11) No
first_name varchar(20) No
last_name varchar(20) No
date_of_birth datetime Yes NULL
phone_number varchar(20) Yes NULL
email varchar(40) Yes NULL
Стр. 16

17.
Отворена система за управление на потребителите
Field Type Null Default Links to
date_of_birth datetime Yes NULL
created datetime No
updated datetime Yes NULL
deleted datetime Yes NULL
active tinyint(1) No 1
При конкретно зададените параметри (входни данни) тази таблица напълно
удовлетворява изискванията на конкретната задача.
Какво става обаче ако с течение на времето изискванията се променят и едно
от тях е да се добавят нови данни за потребителите. Това е типичен случай
при разработката на клиент-сървър системи от среден и голям мащаб.
Първото и същевременно най-тривиално решение е да се добавят нови
полета в таблицата. Това обаче води след себе си редица проблеми:
• Нужна е намесата на администратора на базата данни;
• Новите полета ще доведат до промени в библиотеката за работа с база
данни тъй като вероятно на всяко поле от таблицата отговаря
определена променлива в кода и т.н.;
• Ще се наложи да се направят промени в програмния интерфейс (API),
както в сървърната, така и в клиентската част на системата.
Подобни проблеми се появяват и ако се наложи да се промени името на
някое от полета.
Частично решение на проблема е използването на асоциативни масиви за
съхранение на данните от таблицата. В този случай предаването на
параметрите, т.е. потокът на данни от базата към приложението, ще бъде
осъществено с помощта на масив от двойки (ключ, стойност) и ще се избегне
нуждата от добавяне или преименуване на променливи.
Проблемът със промяна в структурата на базата данни обаче остава.
Тук е моментът да се отбележи, че има голяма разлика между промяна в
структурата на една таблица и промяна в данните съдържащи се в нея.
Можем да направим паралел – промяна в структурата е нещо, което се прави
от администратора или разработчика на системата, докато данните се
променят от ползвателя на системата. От тук става видно, че точно
ползвателят е този, който би имал нужда от промяна на параметрите в
примера по-горе и съответно той би трябвало да има възможност да направи
Стр. 17

18.
Отворена система за управление на потребителите
тези промени без да е нужно да се обръща за помощ към администратора
или разработчика на системата.
Това е валидно в най-голяма степен за отворените системи и системите с
отворен код, където системата се разработва от екип, който може да няма
пряка връзка с ползвателите на системата.
Има ли друг начин да се изгради структурата на базата данни, който да ни
позволи по голяма гъвкавост при структуриране на данните.
Тук е разгледано едно такова решение.
Вертикална параметризация
Името вертикална параметризация (Vertical parametrization) произлиза от
факта, че желанието за промяна на структурата на данните не води до
добавяне на нови полета, т.е. нарастване на таблицата по хоризонтала, а
напротив – целта се постига чрез добавяне на нови записи, с други думи
таблиците растат по вертикала.
За целта създаваме 2 таблици.
Първата таблица profile_parameters съдържа фактическите данни, т.е.
параметрите на конкретния потребител.
Field Type Null Default Links to
parameterid int(11) No
profileid int(11) No profiles -> profileid
typeid int(11) No profile_parameter_types -> typeid
value varchar(255) Yes NULL
Информацията се пази в полето value на тази таблица. Типът на данните се
определя от полето typeid, което сочи към запис от следващата таблица.
Втората таблица profile_parameter_types съдържа типовете, т.е. видовете,
параметри, които един профил може да притежава.
Field Type Null Default Links to
typeid int(11) No
name varchar(64) No
description varchar(255) Yes NULL
rank tinyint(4) No 0
Стр. 18

19.
Отворена система за управление на потребителите
Field Type Null Default Links to
active tinyint(1) No 1
Полето typeid се използва като ключ в предишната таблица за определяне
типа на параметъра.
Полето name е уникален идентификатор на този тип параметър. Това може
да се използва в всички по-горни слоеве от архитектурата на системата –
програмен интерфейс, HTML форми и т.н.
Полето description е реално името на полето в разбираема за човек форма,
т.е. текст. Това може да се използва директно в потребителския интерфейс,
HTML форми и т.н.
Примерни входни данни:
име на поле стойност вид данни
име, собствено Невен текст
име, фамилно Боянов текст
имейл адрес test1234@boyanov.org текст
дата на раждане 20.11.1971 дата
телефон 0123-456-7890 текст
Таблицата profile_parameter_types би съдържала следните данни:
typeid name description rank active
1 name_first име, собствено 1 1
2 name_last име, фамилно 2 1
3 personal_email имейл адрес 3 1
4 personal_dateofbirth дата на раждане 4 1
5 personal_phone телефон 5 1
Таблицата profile_parameters ще съдържа следните данни:
parameterid profileid typeid value
1001 100 1 Невен
1002 100 2 Боянов
1003 100 3 test1234@boyanov.org
1004 100 4 20-ти ноември, 1971
1005 100 5 0123-456-7890
Стр. 19

20.
Отворена система за управление на потребителите
Изтеглянето на данните за конкретен профил може да направим със
следната SQL заявка:
SELECT
profile_parameters.parameterid,
profile_parameters.profileid,
profile_parameters.value,
profile_parameter_types.typeid,
profile_parameter_types.name,
profile_parameter_types.description,
profile_parameter_types.rank,
profile_parameter_types.active
FROM profile_parameters
INNER JOIN profile_parameter_types
ON profile_parameters.typeid = profile_parameter_types.typeid
WHERE profileid = 100;
Резултатът от тази заявка ще е:
parameterid
description
profileid
typeid
name
value
rank
1001 100 Невен 1 name_first име, собствено 1
1002 100 Боянов 2 name_last име, фамилно 2
1003 100 test1234@boyanov.org 3 personal_email имейл адрес 3
1004 100 20-ти ноември, 1971 4 personal_dateofbirth рожд. дата 4
1005 100 0123-456-7890 5 personal_phone телефон 5
От резултата се вижда, че получихме всичката ни необходима информация.
Как се добавят нови параметри?
Добавяме нов запис в таблицата profile_parameter_types ...
typeid name description rank active
6 gender пол 6 1
Добавяме и нова стойност за потребителските профили, за които е
необходимо в таблицата profile_parameters ...
Стр. 20

21.
Отворена система за управление на потребителите
parameterid profileid typeid value
1001 100 1 Невен
1002 100 2 Боянов
1003 100 3 test1234@boyanov.org
1004 100 4 20.11.1971
1005 100 5 0123-456-7890
В резултат на това SQL заявката по-горе ще върне следния резултат:
parameterid
description
profileid
typeid
name
value
rank
1001 100 Невен 1 name_first име, собствено 1
1002 100 Боянов 2 name_last име, фамилно 2
1003 100 test1234@boyanov.org 3 personal_email имейл адрес 3
1004 100 20-ти ноември, 1971 4 personal_dateofbirth рожд. дата 4
1005 100 0123-456-7890 5 personal_phone телефон 5
1006 100 мъж 6 gender пол 6
С подобен начин на структуриране на данните се постигат няколко цели:
• по-опростени и лесни за разбиране от разработчика таблици и полета.
• по-лесни за конструиране SQL заявки.
• по-добре структуриран резултат от изпълнението на заявките.
• по-оптимално дефиниране на ключове и индекси в таблиците.
• по-лесно разширяване на структурата на базата от външни модули.
И най-накрая, и може би най-важното, постигат се по–бързи заявки и
резултати при работа с базата данни.
2.3.2 Изходен код
Един от основните проблеми при създаване на средни и големи системи от
тип клиент-сървър е поддръжката на изходния код след завършването на
всеки етап от разработката. Това включва оправянето на грешки, добавянето
на сравнително малки подобрения в системата, както и проектиране и
евентуално разработване на следваща версия на системата.
Стр. 21

22.
Отворена система за управление на потребителите
С нарастване на обема на разработката нараства и нейната сложност, което
води до повишаване на трудността при работа по конкретна специфична
задача особено в случаите, когато зависимостите между различните
компоненти на системата са сложни.
Съществуват много подходи, техники и тактики за избягване или поне
намаляване на подобни проблеми. Тук са разгледани само няколко от тях –
тези, които са по-сериозно застъпени в настоящата разработка.
Отделяне на проблемите
Изолиране на проблемите и грижите (isolation of concern) при
структурирането на кода е способ, при който в рамките на определен модул,
или дори функция, се работи по точно определен и изолиран проблем.
За да са постигне това трябва да се следват определени правила при
построяване структурата на кода.
За изграждане на потребителския интерфейс на ОСУП системата са
използвани модули от проекта Phlex2, който е разработван в паралел със
системата. Повече информация за Phlex2 е достъпна в частта 3.9
Зависимости от външен код на стр. 42.
За изграждане на програмния интерфейс (API) на ОСУП са използвани
REST/RPC модулите от проекта Common2 който също е разработван в
паралел с настоящата система. Повече информация за Common2 е достъпна
в частта 3.9 Зависимости от външен код на стр. 41.
В конкретния случай модулът Common2/RESTRPC изолира конкретните
функции, имплементиращи определени методи от програмния интерфейс,
като за целта приема всички параметри подадени от отдалечения клиент,
обработва ги предварително и ги предава като аргументи на подходящата
функция. Като резултат функцията получава това, което й е необходимо за
обслужване на заявката, а разработчикът получава възможността да се
концентрира върху работата си над тази конкретна задача.
Друг способ, използван в паралел с горе описания, е инжектиране на
зависимостите и по-точно, както е използвано тук – процедурно
инжектиране на зависимостите (procedural dependency injection). 3
3 Важно е да се отбележи, че разгледаното тук „инжектиране“, приложено в чисто
процедурен контекст, се различава от това описано от Martin Fowler известно като
dependency injection.
Стр. 22

23.
Отворена система за управление на потребителите
Процедурно инжектиране на зависимостите
Още със самото започване на разработката на ОСУП една от основните
поставени цели беше колкото може по-широка съвместимост с платформи и
версии на софтуер. По това време най-разпространената версия на езика за
програмиране PHP беше 4.x.x, в която обектите не бяха много добре развити
и това наложи ползването на изцяло процедурен подход при проектирането
и разработката на системата.
Същевременно бяха разработени някои обектно-ориентирани подходи за
подобряване на процеса на имплементация и Процедурно инжектиране на
зависимостите (ПИЗ) е част от тях.
Основна градивна единица при изграждане йерархията в системата са
прото-обектите. Това на практика са структури или асоциативни масиви в
терминологията на PHP, които съдържат инициализираща информация и
биват предавани като най-първи аргумент на повечето функции.
Инициализирането на структурата в повечето случаи става в началото на
програмата, така че самата имплементираща функция получава
инициализирани вече прото-обекти с необходимата за работата си
информация.
Следват няколко примерни отрязъка от код на PHP, които ще демонстрират
практическото приложение на ПИЗ.
Файл /ums3/src/rest/server.php
Стартова процедура на програмата
// Инициализиране на common
$common_configuration = configuration_load(COMMON2_CONFIG_FILE);
$common = common_init($common_configuration);
// Инициализиране на db
$database_configuration =
database_configuration_load($common_configuration);
$db = database_init($database_configuration);
Инициализиране на REST/RPC подсистемата
// Инициализиране на REST/RPC подсистемата
$restrpcserver = restrpcserver_init($common);
// Инициализиране на UMS3 REST/RPC сървъра
$ums3server = restrpcserver_ums_init($restrpcserver, $db);
// Добавяне на REST/RPC метод
Стр. 23

24.
Отворена система за управление на потребителите
restrpcserver_register(
$restrpcserver,
$ums3server,
'authentication.signin',
RESTRPCSERVER_RECEIVES_URIP,
RESTRPCSERVER_RESPONDS_JSON);
Имплементация на метода authentication.signin
function restrpcserver_method_authentication_signin(
&$ums3server,
$parameters,
$content = NULL)
{
// Инициализиране
$restrpcserver = &$ums3server['restrpcserver'];
$common = &$restrpcserver['common'];
$db = &$ums3server['db'];
// Следва реалната имплементация на метода
$parameter_username = $parameters['username'];
$parameter_password = $parameters['password'];
// Инициализиране на UMS
$ums = ums_init($common, $db);
$session = authentication_signin($ums, $parameter_username,
$parameter_password);
restrpcserver_set_success($restrpcserver);
// Бележка: пропуснати са някои елементи от оригиналния код
// като проверката ums_is_successful($ums) например.
return $session;
}
От примера в последния отрязък код се вижда, че функцията
restrpcserver_method_authentication_signin получава почти всичките ѝ
необходими прото-обекти „наготово“, без да е необходимо нито да „знае“ как
се инициализират, нито да ги инициализира. Единственото изключение е
прото-обекта ums, който се инициализира локално, тъй като е специфичен за
точно тази операция – authentication.signin – и не е необходимо да бъде
инициализиран предварително, тъй като може и да не се ползва в други
Стр. 24

25.
Отворена система за управление на потребителите
методи.
Управление на привилегиите
Системата за управление на привилегиите в ОСУП се базира на това какво
другите потребители могат да правят с конкретния ресурс – потребител или
профил. Това е в контраст с концепцията, при която за всеки конкретен
потребител се дефинира какво може да прави с другите ресурси или групи от
ресурси.
За управление на привилегиите в системата се използва схема наречена PSU
(Public/Shared/User) привилегии.
• Публични (Public): това са привилегиите които има всеки „посетител“
на системата независимо дали е вписан в системата или не;
• Споделени (Shared): това са привилегиите, които получават всички
удостоверени потребители на системата;
• Потребителски (User): това са правата, които получава конкретен
потребител на системата.
За момента са дефинирани само привилегии четене и запис.
На сегашния етап от разработка на системата не са дефинирани нито групи
от потребители нито групови привилегии.
2.3.3 Интерфейси за достъп
Всяка съвременна система от тип клиент-сървър разполага с поне един
интерфейс за отдалечен достъп.
Интерфейсите за достъп може да разделим на два типа: такива
предназначени за потребители, т.е. хора и такива предназначени за
свързването на други машини и системи към конкретната система.
Потребителски интерфейси
Това са интерфейси позволяващи на крайния потребител или на
администратора на системата за ползват услугите предоставени от нея.
Типичен представител на подобен интерфейс е уеб-базирания интерфейс,
който позволява на потребител, удостоверил се с потребителско име и
парола, да ползва системата, нейните функции и услуги ползвайки уеб
Стр. 25

26.
Отворена система за управление на потребителите
браузър свързвайки се към системата по мрежата Интернет.
Машини интерфейси
Свързването на две машини посредством някакъв предварително уточнен
протокол за комуникация се осъществява през компютърна мрежа. Най-
често това е Интернет.
За целите на ОСУП бяха разработени няколко интерфейса за достъп до
системата.
XML/RPC
Това е протокол базиран на HTTP който използва XML кодиране при
обмяната на данни.
Следва примерен поток на данните.
Заявка:
<methodCall>
<methodName>authentication.signin</methodName>
<params>
<param>
<value><string>test</string></value>
</param>
<param>
<value><string>test</string></value>
</param>
</params>
</methodCall>
Отговор:
<methodResponse>
<params>
<param>
<value><struct>
<member><name>sessionid</name>
<value><string>1622</string></value>
</member>
<member><name>sessionvalue</name>
<value><string>cd398194457d205db2e3520abf722ce8</string></value>
</member>
<member><name>userid</name>
Стр. 26

27.
Отворена система за управление на потребителите
<value><string>3</string></value>
</member>
<member><name>username</name>
<value><string>test</string></value>
</member>
</struct></value>
</param>
</params>
</methodResponse>
В последната си версия ОСУП вече не поддържа XML/RPC протокола.
REST/RPC
Това е протокол, работещ върху HTTP и ползваш няколко различни начина
за изпращане и получаване на данни.
За целите на тази разработка са дефинирани няколко начина за изпращане
на параметрите към сървъра, както и няколко типа резултат връщан от
сървъра.
Задаването на входните параметри може да бъде по един от следните
начини:
• NONE – без параметри;
• URIP – URI parameters: параметри подадени през URI или линка за
връзка;
• FUED – Form URL Encoded Data: данни кодирани за форма;
• FUEP – Form URL Encoded Parameters: кодирани като параметри;
• JSON – JSON кодирани данни.
Резултатът от изпълнението може да бъде в един от следните формати:
• NONE – без резултат.
• TEXT – неформатиран текст.
• HTML – HTML форматиран текст.
• JSON – JSON кодирани данни.
Следва примерен поток на данните.
Заявка от тип URIP:
Стр. 27

28.
Отворена система за управление на потребителите
http://localhost/interlecta/www/ums3/rest/authentication.signin?
username=test&password=test
Отговор от тип JSON:
{
"sessiontoken": "1faEWzyZzrUmbDzkaJeCuweqXaF4o26ZG9Lg2tHu",
"userid": "4",
"username": "test",
"nickname": "Test",
"message": "Hello!"
}
Програмният интерфейс или API е разгледан по-подробно в Глава 3.
Разработка на системата в частта Програмен интерфейс на стр. 39.
2.4. Слоеве в архитектурата на системата
Както всяка сложна компютърна система и структурата ОСУП може да се
раздели на определен брой слоеве.
Система за управление на база данни
Библиотека за работа с база данни Други библиотеки
Бизнес логика Инструментална библиотека
Сървърна библиотека и програмен интерфейс
↕↕↕↕
Интернет
↕↕↕↕
Клиентска библиотека за връзка с програмния интерфейс
Логика на приложението Други библиотеки
Потребителски интерфейс
Стр. 28

29.
Отворена система за управление на потребителите
2.4.1 База данни и структура на базата данни
Системата за управление на база данни се грижи за съхранението на
информацията, нужна за работата на системата, а също така и за
предоставяне на подходящи интерфейси за достъп до данните от език от
високо ниво.
Структурата на таблиците в базата данни е разгледана по-подробно в Глава
3. Разработка на системата на стр. 31.
2.4.2 Библиотека за работа с база данни
Основната задача на библиотеката за работа с база данни е да изолира кодът
от по-горните нива от непосредствената работа със системата за управление
на база данни. Това се постига чрез създаване на функции, които от една
страна работят директно с таблиците в базата данни, а от друга предоставят
интерфейс, който борави с градивните елементи на системата от по-високо
ниво като потребител, потребителски профил и т.н.
2.4.3 Бизнес логика
Бизнес логиката е тази част от системата, в която се изпълняват логическите
и алгоритмични задачи. Тя е сравнително обособен модул и на практика
осъществява задачите, за които се разработва системата.
Бизнес логиката е най-важният компонент на системата.
2.4.4 Инструментална библиотека
Това са набор от функции и помощни инструменти за работа със системата.
Подобни инструменти могат се ползват от други, външни, системи за
интегриран със Системата за управление на потребители.
2.4.5 Сървърна библиотека и програмен интерфейс
Сървърната библиотека имплементира и експонира програмния интерфейс
(API) към външния свят.
Следват слоевете, които обикновено са код разположен в приложението,
ползвано от крайния клиент. Например: уеб сайт, мобилно приложение и
т.н.
Стр. 29

30.
Отворена система за управление на потребителите
2.4.6 Клиентска библиотека за връзка с програмния
интерфейс
Това е библиотека от функции, които осъществяват връзката със сървъра
посредством програмния интерфейс.
2.4.7 Логика на клиентското приложение
В допълнение към логиката, реализирана на сървъра, конкретното
клиентско приложение също изисква своя логика на обработка на данни и
събития. Често това са задачи свързани с потребителския интерфейс,
обработката на данни въведени от потребителя на системата и т.н.
2.4.8 Потребителски интерфейс
Потребителският интерфейс е връзката между системата и крайния
потребител. Това би могло да бъде уеб-базиран интерфейс, мобилно
приложение и .др.
2.4.9 Други клиентски библиотеки
Други клиентски библиотеки, които ползват програмния интерфейс могат да
бъдат такива написани на различни езици като Java, JavaScript, Python и др.,
които допълват функционалността на крайния продукт.
Подобни библиотеки са извън темата на конкретната разработка.
Стр. 30

31.
Отворена система за управление на потребителите
Глава 3. Разработка на системата
В тази глава са разгледани подробно основните градивни елементи на
системата.
Основата върху която се доразвива системата е базирана на 3-та версия на
ОСУП (известна като UMS3) и представлява най-последната версия на
разработката.
Пълен достъп до изходния код на ОСУП заедно със всички необходими
данни и инструменти за работата на системата са достъпни в Интернет.
Повече информация по въпроса в Приложения на стр. 54.
3.1. Структура на базата данни
Списък с таблиците, необходими за работа на системата
profiles Профили на потребителите
profile_parameters Параметри на профилите
profile_parameter_forms Форми (съставени от секции)
profile_parameter_form_sections Секции принадлежащи на форми
profile_parameter_sections Секции (съставени от параметри)
profile_parameter_types Типове параметри
profile_public_privileges Публични привилегии на профилите
profile_shared_privileges Споделени привилегии на профилите
profile_user_privileges Потр. привилегии на профилите
users Потребители на системата
user_notes Бележки за потребителите
user_sessions Сесии на потребителите
3.1.1 Таблици
Следва списък на таблиците подредени по азбучен ред и кратко описание на
тяхното съдържание.
Стр. 31

32.
Отворена система за управление на потребителите
profiles
Профилите, заедно с потребителите, са основна градивна единица в
структурата на базата данни. Всеки профил може да има потребител на
когото принадлежи. Профили без потребител също могат да съществуват.
profile_parameters
Параметрите на профила са списък от двойки (ключ, стойност).
Параметърът има тип, който определя какво съдържат и какъв вид са
данните.
Всеки параметър може да принадлежи на точно един профил.
profile_parameter_forms
Формите представляват множества от една или повече секции.
Релацията между форма и секция се определя от допълнителната таблица
profile_parameter_form_sections. Това обуславя възможността една
секция да бъде част от една или повече форми.
profile_parameter_form_sections
Това е таблица, която определя релациите между форми и секции.
profile_parameter_sections
Секцията е множество от един или повече типове параметри.
Секциите могат да бъдат групирани във форми.
profile_parameter_types
Типовете параметри дефинират разнообразието от данни, които могат да се
записват в параметрите на профила.
Параметърът може да принадлежи на точно една секция.
Стр. 32

33.
Отворена система за управление на потребителите
profile_public_privileges
Публичните привилегии на профила определят режима на публичен достъп
до данните на профила.
profile_shared_privileges
Споделените привилегии на профила определят режима на споделен достъп
до данните на профила.
profile_user_privileges
Потребителските привилегии на профила определят режима на
потребителски достъп до данните на профила.
users
Потребителите, заедно с профилите, са основна градивна единица на базата
данни.
Потребителското име трябва да бъде уникално.
Паролата се пази в базата данни в хеширан вид с помощта на алгоритъма
MD5.
user_notes
Бележки за потребителя. Създадени са като допълнителен инструмент за
системния администратор.
user_sessions
Потребителските сесии определят активните сесии, които потребителят има
след като е получил достъп до системата.
3.1.2 Основни единици
Потребители
Потребителят или user е най-основната градивна единица в структурата на
ОСУП. Повечето от ресурсите на системата които имат отражение в базата
Стр. 33

34.
Отворена система за управление на потребителите
данни имат и поле-ключ към таблицата с потребителите. Обикновено това
поле е userid.
Сесии
Сесията или session е единица, която пази информация за потребител,
който успешно е бил вписан в системата.
Повече подробности за сесиите и вписването са достъпни в частта
3.3.1 Удостоверяване на стр. 38.
Профили
Профилът или profile е единица, която пази лична информация
(параметри) за потребителя, на който принадлежи.
Профилът може да се разгледа и като визитна картичка на потребителя, но
може да включва не само текст и изображения, а също други видове медия
като аудио, видео и т.н.
3.1.3 Релации
Потребители и сесии
Всеки потребител може да притежава множество сесии.
Връзката между потребителите и сесиите в таблиците users и user_sessions
е чрез полето userid.
Една сесия принадлежи на точно един потребител.
Потребители и профили
Всеки потребител може да притежава точно един профил.
Връзката между потребителите и профилите в таблиците users и profiles е
чрез полето userid.
Един профил принадлежи на точно един потребител.
В текущата реализация на ОСУП е позволено профил да няма потребител,
т.е. userid=NULL – това позволява дефинирането на анонимни профили, т.е.
такива които не са собственост на определен потребител. Пример за подобни
Стр. 34

35.
Отворена система за управление на потребителите
данни би бил указател или справочник на бизнес обекти.
3.1.4 Процедури
Създаване на запис
Всички таблици в системата имат винаги един първичен ключ, който е от
тип int и е AUTO_INCREMENT. Това позволява всеки запис да има уникален
идентификатор, с помощта на който да се осъществяват основните операции
с него, а именно четене и запис.
Повечето таблици имат поле active което показва дали конкретния запис се
ползва или не.
Изтриване на запис
На практика в системата не съществува процедура по физическото
изтриване на запис. Това е така, защото взаимовръзките и релациите между
данните и таблиците са сложни и изтриването на запис може да доведе до
неконсистентност на данните 4.
За тази цел в случаите когато определен запис не би трябвало да се ползва
повече, неговото поле active се нулира, т.е. active=0.
Поддръжка
Възможно е периодично преминаване през записите в базата данни и след
внимателна проверка на полетата active и на релациите между таблиците
записите, при които active=0 да бъдат перманентно изтрити от базата
данни.
3.1.5 Примерни данни
Следват примерниданни за таблиците users, profiles,
profile_parameter_types и profile_parameters.
4 Неконсистентност на данните (англ.: inconsistent data) – нецялостни данни, такива при
които липсващи записи могат да доведат до нарушена релационна структура на данните.
Стр. 35