Разработка биллинга для Hot-Spot точек Wi-fi

Версия MySQL 5.1 продолжает путь к стандарту SQL:2003. MySQL 5.1 содержит следующие нововведения.

• сегментирование — возможность разбить одну большую таблицу на несколько частей, размещенных в разных файловых системах, основываясь на определенной пользователем функции. При определенных условиях это может дать серьёзное увеличение производительности и, кроме того, облегчает масштабирование таблиц.
• изменено поведение ряда операторов, для обеспечения большей совместимости со стандартом SQL2003.
• построчная репликация (англ. row-based replication), при которой в бинарный лог будет записываться только информация о реально измененных строках таблицы вместо оригинального (и, возможно, медленного) текста запроса. Построчную репликацию можно использовать только для определенных типов sql-запросов, в терминах MySQL — смешанная репликация (англ. mixed replication).
• встроенный планировщик периодически запускаемых работ. По синтаксису добавление задачи похоже на добавление триггера к таблице, по идеологии — на crontab.
• дополнительный набор функций для обработки XML, реализация поддержки XPath.
• новые средства диагностики проблем и утилиты для анализа производительности. Расширены возможности по управлению содержимым лог-файлов, логи теперь могут быть сохранены и в таблицах general_log и slow_log. Утилита mysqlslap позволяет провести нагрузочное тестирование БД с записью времени реакции на каждый запрос.
• для упрощения операции обновления подготовлена утилита mysql_upgrade, которая выполнит проверку всех существующих таблиц на предмет совместимости с новой версией, и при необходимости выполнит надлежащие корректировки.
• MySQL Cluster отныне выпущен как отдельный продукт, базирующийся на MySQL 5.1 и хранилище NDBCLUSTER.
• значительные изменения в работе MySQL Cluster, такие, как, например, возможность хранения табличных данных на диске.
• возврат к использованию встроенной библиотеки libmysqld, отсутствовавшей в MySQL 5.0.
• API для плагинов, которое позволяет загружать сторонние модули, расширяющие функциональность (например, полнотекстовый поиск), без перезапуска сервера.
• реализация парсера полнотекстового поиска в виде plug-in.
• новый тип таблиц Maria (устойчивый к сбоям клон MyISAM).
• ветка MySQL 5.5 базируется на невыпущенной серии MySQL 5.4 и содержит ряд значительных улучшений, связанных с повышением масштабируемости и производительности, среди которых:
• использование по умолчанию движка InnoDB.
• поддержка полусинхронного (semi-synchronous) механизма репликации, основанного на патчах к InnoDB от компании Google.
• улучшение функций по партицированию данных. Расширенный синтаксис для разбиения больших таблиц на несколько частей, размещенных в разных файловых системах (partitioning). Добавлены операции RANGE, LIST и метод оптимизации «partition pruning».
• новый механизм оптимизации вложенных запросов и JOIN операций.
• переработана система внутренних блокировок.
• интегрированы патчи Google с оптимизацией работы InnoDB на CPU с большим количеством ядер.
• версия MySQL 6.0 была заморожена на стадии альфа-тестирования. Первоначально было принято решение о создании версии 5.2, вскоре эта версия была переименована в 6.0. Однако, позже информация о MySQL 6.0 исчезла с сайта, а разработчики сосредоточились на версии 5.5 и следующей за ней версии 5.6.
• одним из основных нововведений версии 6.0 планировался новый тип таблиц Falcon, разработанный в качестве потенциальной замены для InnoDb компании Inno DB, приобретённой компанией Oracle. В связи с приобретением в 2010 году Sun Microsystems тем же Oracle, судьба Falcon остаётся под вопросом.

 

 

1.4 Требования к внешнему интерфейсу

 

 

1.4.1 Аппаратные интерфейсы

 

 

Данный комплекс работает на любом компьютере или гаджете пользователя, подключенном  и имеющем выход в сеть Internet через WI-FI точку. Сам комплекс установлен на модеме и сервере, который так же подключен к сети Internet.

 

 

 

 

 

1.4.2 Программные интерфейсы

 

 

Для корректного отображения рекламы понадобится интернет браузер.

Например Google Chrome version 3428. Так же для просмотра работоспособности дипломного проекта подойдёт любой другой браузер – Opera, Mozila Firefox и даже Internet Explorer 8. В случае со встроенным программным обеспечением таких платформ как iOS и Android, проблем не возникало.

 

 

1.5 Ограничение по памяти

 

 

На сервере базы данных должно каждый день оставаться не менее 2Гб свободного места. Оперативной памяти после завершения работы каждого из скриптов - не менее 1 ГБ.

 

 

2 Детальные требования

 

 

2.1 Функциональные требования

 

 

Разработать информационный комплекс для показа пользовательской рекламы пользователям. Основные задачи личного кабинета клиента:

а) операции со счетом:

1) пополнение счета;

6) открытые ордера.

б) личные данные:

1) изменить персональные данные;

2) изменить пароль к личному кабинету;

в) обратная связь:

1) новое тикет;

2) список тикетов;

г) загрузка своей html страницы, которая будет показываться пользователям

 

 

2.1.1 Диаграмма вариантов использования

 

 

Диаграмма вариантов использования — диаграмма, на которой отражены отношения, существующие между клиентом, загрузившем рекламную страницу, и пользователям WI-FI точки доступа.

Основная задача - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы.

Диаграмма вариантов использования для «Биллинг для Hot spot WI-FI»» представлена на рисунке 2.1

 

 

Рисунок 2.1 Диаграмма Вариантов использования

 

 

2.1.2 Диаграмма пригодности

 

 

В объектно-ориентированном проектировании большую роль играют выявление и систематизация всех структурных и  поведенческих тонкостей предметной области. Одним из известных современных подходов для этих целей служит, разработанный Дугом Розенбергом и Кендаллом Скоттом процесс ICONIX [9]. Методология процесса заключается в распределении поведения между классами. Для этого используются четыре этапа проектирования: моделирование предметной области, моделирование вариантов использования, анализ пригодности и построение диаграмм последовательности.

Процесс  ICONIX представляет собой нечто среднее между очень громоздким рациональным унифицированным процессом (Rational Unified Process - RUP)  и весьма компактной методологией экстремального программирования. Процесс  ICONIX , как и  RUP   , основан на вариантах использования, но не характеризуется множеством его недостатков. В этом процессе тоже применяется язык моделирования  UML, однако основное внимание уделяется анализу требований. Процесс  ICONIX , по представлению Айвара Джекобсона, основан на вариантах использования, вот почему с помощью этого процесса создаются вполне конкретные и простые для понимания варианты использования, которые легко использовать для разработки системы.

В объектно-ориентированных системах структура кода определяется классами. Поэтому, прежде чем приступать к кодированию, нужно выяснить, какие классы понадобятся. С этой целью следует нарисовать одну или несколько диаграмм классов. Для каждого класса необходимо описать все атрибуты, то есть данные-члены, и операции, которые представляют собой функции программы. Другими словами, мы должны идентифицировать все функции и удостовериться, что у нас есть данные, с которыми эти функции должны работать.  Нужно будет показать, как функции и данные инкапсулируются в классах. В конечном счете мы намерены получить очень детальные диаграммы классов уровня проектирования – такого уровня детализации, при котором диаграмма классов может служить шаблоном для создания кода.

   Вопрос, таким образом, заключается в том, как перейти от вариантов использования к диаграммам классов уровня проектирования. В  UML   для этой цели лучше всего подходят диаграммы последовательности – идеальное средство для принятия решений о распределении поведения. Решения о приписывании поведения классам принимаются по мере создания и анализа диаграмм последовательности.

 Сложность проектирования заключается в том, как перейти от вариантов использования к диаграммам последовательности! В большинстве случаев это непростая задача, так как варианты использования описывают систему на уровне требований, а диаграммы последовательности – дают  детальное представление с точки зрения проектирования.   Именно преодоление пропасти между «что» и «как»  - центральная тема в процессе  ICONIX.

Первоначально диаграммы пригодности были включены в язык UML  лишь частично. Они появились в работе Айвара Джекобсона и были утверждены в стандарте UML  как дополнения. Важность этого вида диаграмм для моделирования никоим образом  не оспаривается.

Диаграмма пригодности – диаграмма классов анализа, на которой вместо обычных прямоугольников – символов классов – изображаются пиктограммы трех видов: граничные объекты, управляющие объекты и сущностные объекты.

Граничные объекты – объекты системы, с которыми непосредственно взаимодействуют актеры. Это могут быть: экранные формы, диалоговые окна и меню, элементы GUI.

Сущностные объекты -   таблицы БД, файлы, результаты поиска, а также все доменные объекты(понятия) предметной области.

Управляющие объекты (контроллеры) – объекты, заключающие в себе логику приложения. В этих объектах инкапсулируются бизнес-правила и стратегии, тем самым локализуются все их изменения и при этом не затрагиваются интерфейс пользователя и схемы базы данных. Эти объекты служат соединением между пользователями и хранимыми данными.

Анализ пригодности для варианта использования, выполняется путем исследования его текста с изображением актеров, граничных,  сущностных и управляющих объектов, а также исследованием связей между различными элементами на диаграмме пригодности. Исследование должно проводиться как с основными, так и с альтернативными сценариями варианта использования, а вся нотация должна поместиться на одной диаграмме.

К основным правилам общения между элементами диаграммы пригодности  следует отнести: актеры могут общаться только с граничными объектами; граничные объекты –только с управляющими объектами и с актерами; сущностные объекты –  только с управляющими объектами; управляющие объекты – с граничными, сущностными и с другими управляющими объектами, но только не с актерами.

Порядок анализа варианта использования:

1. Внимательно прочесть описание последовательности действий в тексте варианта использования.
2. Нарисовать диаграмму пригодности и проверить соответствие. выявленной последовательности действий варианта использования  с последовательностью ассоциаций на диаграмме пригодности, и при необходимости, переписывать текст варианта использования для устранения неоднозначностей, а также для введения явных ссылок на граничные и сущностные объекты.

Результаты анализа пригодности используются не только для улучшения текста варианта использования, но и для постоянного уточнения статической модели системы (диаграммы классов).

Диаграмма пригодности представлена на рисунке 2.2

 

 

Рисунок 2.2 Диаграмма пригодности

 

 

 

 

 

 

2.1.3 Диаграмма последовательности

 

 

Диаграмма последовательности — диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.

Основными элементами диаграммы последовательностей являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.

Диаграмма последовательности для представлена на рисунке 2.3

 

 

Рисунок 2.3 Диаграмма последовательности

 

 

 

 

 

2.1.4 Диаграмма размещения

 

 

Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать размещение объектов и компонентов в распределенной системе.

Каждый узел на диаграмме представляет собой некоторый тип вычислительного устройства, в большинстве случаев часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мейнфреймом.

Диаграмма размещения показывает физическое расположение сети и местонахождения в ней различных компонентов.

Его основные элементы:

- Узел - это вычислительный ресурс - процессор или другое устройства (дисковая память контроллера, различные устройства). Для узла можно задать выполняющиеся на нем процессы.

- Соединение - это канал взаимодействия узлов (сеть).

Диаграмма размещения представлена на рисунке 2.4

 

 

Рисунок 2.4 Диаграмма размещения

 

 

 

 

 

 

2.1.5 Диаграмма базы данных

 

 

Всякая деятельность связана с информацией, с организацией ее сбора, хранения, выборки. Можно сказать, что неотъемлемой частью повседневной жизни стали базы данных, для поддержки которых требуется некоторый организационный метод, или механизм. Такой механизм называется системой управления базами данных (СУБД).

База данных (БД) – совместно используемый набор логически связанных данных (и их описание), предназначенный для удовлетворения информационных потребностей организации.

СУБД (система управления базами данных) – программное обеспечение, с помощью которого пользователи могут определять, создавать и поддерживать базу данных, а также получать к ней контролируемый доступ

Системы управления базами данных существуют уже много лет, многие из них обязаны своим происхождением системам с неструктурированными файлами на больших ЭВМ. Наряду с общепринятыми современными технологиями в области систем управления базами данных начинают появляться новые направления, что обусловлено требованиями растущего бизнеса, все увеличивающимися объемами корпоративных данных и, конечно же, влиянием технологий Internet.

Одной из популярных СУБД является MS SQL Server. Microsoft SQL Server - система управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. В данном дипломном проекте база выполнена на ms sql 2000, потому что он является надежным и защищенным на рисунке 2.6 изображена диаграмма ER отображающая структуру базы данных и связи между таблицами.

Диаграмма базы данных представлена на рисунке 2.5

 

 

Рисунок 2.5 ER-диаграмма

 

Таблица 2.1 tblclients       

Id	int(11)
firstname	char(100)
lastname	char(100)
Email	char(100)
City	char(100)
password	char(100)

 

Таблица 2.2 Таблица tbladvert

Id	int(11)
clientid	Int(11)
Name	char(100)
Code	Text
Img	Text

 

 

 

 

 

 

 

 

 

 

Таблица 2.3 tbllog