МОДЕЛИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
3.1 Логическое моделирование
3.1.1 Модель AS-IS
Построению модели AS-IS предшествовало исследование обычно использующихся методик работы нескольких человек над одним документом. Упомянутое включало в себя работу автора документа (редактирование текста документа, изменение форматирования).
При этом один из редакторов открывает документ (никто другой не должен в данный момент времени его изменять), вносит правки в текст или форматирование и сохраняет файл. После этого монопольный доступ к файлу может получить другой автор. Возможно только последовательное редактирование одного файла разными авторами, поскольку при одновременной работе более позднее сохранение файла перезапишет все внесенные ранее изменения. Для хранения редактируемых файлов может использоваться FTP-сервер или облачное хранилище.
На основании полученной при этом информации была построена модель AS-IS, показанная на диаграммах рис. 3.1-3.3 и представляющая собой «снимок» существующего положения дел.
Рисунок 3.1 – Контекстная диаграмма.
Рисунок 3.2 - Декомпозиция контекстной диаграммы
Здесь используется последовательное редактирование документа несколькими пользователями, сам документ хранится в облачном хранилище, FTP-сервере или другом месте с удобным доступом к нему пользователей (например, в локальной сети). После редактирования документа одним пользователем он вновь сохраняется в хранилище, откуда следующий пользователь может взять свежую версию и продолжить работу.
Рисунок 3.3 – Диаграмма дерева узлов
3.1.2 Модель TO-BE
Существенным недостатком модели AS-IS является невозможность действительно одновременного редактирования документа. На самом деле это процесс последовательных изменений файла разными пользователями. Два человека не могут работать над файлом одновременно, поскольку последний пользователь, сохранивший документ, перепишет все изменения, внесенные в документ между открытием документа пользователем и его сохранением. Это снижает удобство процесса и предъявляет требования к координации работы, а также замедляет её: вместо того, чтобы одновременно работать над разными участками документа, пользователям приходится ждать, когда тот станет доступным для редактирования. Ещё одним недостатком такого метода является то, что, как правило, сообщение другим пользователям о внесенных в документ изменениях требует дополнительных усилий. Это или пометки в самом документе (требующие удаления впоследствии) или сообщение лично, что в случае размещения пользователей в разных помещениях (или даже в разных странах) требует применения дополнительных технических средств: телефона, систем мгновенного обмена сообщениями, электронной почты.
На наш взгляд для улучшения существующей ситуации следует изменить существующую систему так, чтобы было возможно одновременное редактирование документа несколькими пользователями. При этом сам документ будет храниться в базе данных веб-сервера, а доступ к нему будет предоставляться через специальное приложение. С учетом сказанного была построена модель TO-BE, показанная на диаграммах 3.4-3.6
Рисунок 3.4 – Контекстная диаграмма
Рисунок 3.5 – Декомпозиция контекстной диаграммы
Здесь представлена декомпозиция контекстного процесса «совместное редактирование документа» на процессы «запрос документа», «редактирование документа и «серверная обработка данных».
Рисунок 3.6 – Декомпозиция дерева узлов
3.1.3 Выбор методологий моделирования и инструментария
Для построения моделей бизнес-процессов можно использовать CASE-средства BЗwin, AllFusion Process Modeler, графический редактор Visio и другие инструментальные средства. В данном случае предпочтение было отдано средствам Enterprise Architect и ERWin — развитию BPwin.
3.1.4 Разработка диаграмм вариантов использования
Перед разработкой диаграммы вариантов использования определим список вариантов использования:
- Вход в систему;
- Редактирование прав пользователя;
- Работа с документом:
- Создание документа;
- Редактирование документа;
- Использование привязанного к документу чата:
- Просмотр сообщений;
- Отправка сообщений;
На рисунке 3.7 показана разработанная диаграмма вариантов использования.
Рисунок 3.7 – диаграмма вариантов использования
3.1.5 Описание вариантов использования
3.1.5.1 Описание варианта использования «Вход в систему»
Назначение. Данный вариант использования описывает вход пользователя в систему.
Основной поток событий. Данный вариант использования выполняется, когда Пользователь хочет войти в систему.
Система запрашивает имя пользователя и пароль;
Пользователь вводит имя и пароль;
Система проверяет введенные имя и пароль, после чего открывает доступ в систему в соответствии с ролью Пользователя в ней;
Альтернативные потоки событий:
1) Неправильное имя и/или пароль. Если во время выполнения основного потока обнаружится, что пользователь ввел неверное имя и/или пароль, то система выводит сообщение об ошибке. Пользователь может вернуться к началу основного потока или отказаться от входа в систему (при этом выполнение варианта использования завершается).
2) Пользователь заблокирован в системе. Во время выполнения основного потока может обнаружиться, что доступ пользователя в систему заблокирован администратором. В этом случае система выводит сообщение об ошибке.
Предусловия. Отсутствуют.
Постусловие. Если вариант использования выполнен успешно, пользователь входит в систему. В противном случае состояние системы не изменится.
3.1.5.2 Описание варианта использования «Управление пользователями»
Назначение. Данный вариант использования позволяет Администратору устанавливать определенным пользователям разрешения на выполнение тех или иных действий.
Основной поток событий. Данный вариант использования начинает выполняться, когда Администратор хочет изменить права определенного пользователя.
Система запрашивает имя пользователя для изменения;
Администратор вводит имя;
Система отображает страницу редактирования информации пользователя;
Администратор изменяет права пользователя и запрашивает сохранение информации;
Система сохраняет изменения;
Альтернативный поток событий. Не существует пользователя с таким именем. Если во время выполнения основного потока обнаружится, что в системе отсутствует пользователь с заданным именем, система выдаст ошибку и вернет Администратора к шагу 1 основного потока.
Предусловие. Перед началом выполнения данного варианта использования Администратор должен войти в систему.
Постусловие. Если вариант использования завершится успешно, права пользователя будут изменены. В противном случае состояние системы не изменится.
3.1.5.4 Описание варианта использования «Изменение прав пользователя»
Назначение. Данный вариант использования позволяет Администратору устанавливать необходимость наличия у пользователей определенных прав для выполнения тех или иных операций над документом.
Основной поток событий:
Администратор страницу изменения прав пользователя.
Администратор устанавливает права доступа
Система сохраняет измененные права и приводит их в исполнение.
Альтернативный поток событий. Документ просматривают пользователи, которым согласно вновь установленным правам просмотр запрещён. В данном случае пользователю должно быть выдано соответствующее сообщение и закрыт доступ к документу.
Предусловие. Перед началом выполнения данного варианта использования Администратор должен войти в систему.
Постусловие. Если вариант использования завершится успешно, права доступа будут изменены, а сам документ сохранится в неизменном состоянии.
3.1.5.5 Описание варианта использования «Работа с документом»
Назначение. Данный вариант использования позволяет Пользователю просматривать, изменять и экспортировать документ.
Основной поток событий. Пользователь открывает документ из списка документов, доступных ему, или воспользовавшись постоянной прямой ссылкой на документ. Система отображает выбранный документ. После этого выполняется один из подчиненных потоков: просмотр документа, его редактирование или экспорт
Просмотр документа. Документ отображается в отдельном поле на веб-странице вместе со списком просматривающих документ пользователей и чатом.
Изменение документа
— Пользователь изменяет документ, пользуясь клавиатурным вводом и командами с панели инструментов;
— Все изменения в документе в реальном времени передаются на сервер и сохраняются в базе данных;
— С сервера внесенные изменения рассылаются остальным пользователям, просматривающим документ, и отображаются в теле документа.
Альтернативные потоки:
Пользователь не имеет прав на просмотр документа. Система выдает сообщение об ошибке и перенаправляет Пользователя к списку документов.
Пользователь не имеет прав на редактирование документа. Система блокирует попытки пользователя изменить документ на локальной машине и не принимает его изменения на сервере.
Потеряна связь с сервером во время редактирования. Изменения, внесенные после потери связи с сервером, отменяются, а возможность внесения новых блокируется. Пользователю должно быть выдано сообщение об ошибке и предложение переподключиться к серверу.
Предусловие. Пользователь должен иметь права на необходимые действия.
Постусловия. Нет
3.1.5.6 Описание варианта использования «Использование чата»
Назначение. Данный вариант использования позволяет Пользователю просматривать сообщения чата и писать новые.
Основной поток событий. Пользователь открывает документ из списка документов, доступных ему, или воспользовавшись постоянной прямой ссылкой на документ. Система отображает выбранный документ. После этого выполняется один из подчиненных потоков: просмотр сообщений или их написание
Просмотр сообщений чата:
— Система отображает 25 последних сообщений чата документа;
— При появлении новых сообщений те показываются внизу списка;
Отправка сообщений в чат:
— Пользователь пишет и отправляет сообщение;
— Все сообщения в реальном времени передаются на сервер и сохраняются в базе данных;
— С сервера сообщения рассылаются остальным пользователям, просматривающим документ, и отображаются в области чата;
Альтернативный поток. Пользователь не имеет прав на просмотр документа. Система блокирует пользователю доступ к отправке сообщений на локальной машине и не принимает его сообщения на сервере.
Предусловия. Нет
Постусловия. Нет
3.1.6 Построение логической модели данных
В результате анализа входящих/исходящих потоков и оптимизации их содержимого были выделены сущности пользователя, документа, атомарного изменения в документе, пользовательского цвета, сообщения в чате и роли.
После выявления отношений между сущностями была построена логическая модель, показанная ниже на различных уровнях: сущностей (рис 3.8) и атрибутов (рис 3.9).
Рисунок 3.8 — Уровень сущностей
Рисунок 3.9 — Уровень атрибутов
3.1.7 Разработка сценариев и макетов экранных форм
3.1.7.1 Вариант использования «Вход в систему»
Рисунок 3.10 - Диаграмма последовательности «Вход в систему»
Рисунок 3.11 - Диаграмма кооперации «Вход в систему»
Рисунок 3.12 – Макет страницы «Вход в систему»
3.1.7.2 Вариант использования «Управление пользователями»
Рисунок 3.13 - Диаграмма последовательности «Управление пользователями»
Рисунок 3.14 – Диаграмма кооперации «Управление пользователями»
Рисунок 4.10 – Макет страницы «Управление пользователями»
3.1.7.3 Вариант использования «Изменение прав пользователя»
Рисунок 4.11 - Диаграмма последовательности «Изменение прав пользователя»
Рисунок 4.12 - Диаграмма кооперации «Изменение прав пользователя»
Рисунок 4.13 – Макет диалога «Изменение прав пользователя»
3.1.7.4 Вариант использования «Работа с документом»
Рисунок 4.14 - Диаграмма последовательности «Работа с документом»
Рисунок 4.15 - Диаграмма кооперации «Работа с документом»
Рисунок 4.16 – Экранная форма «Работа с документом»
3.1.7.5 Вариант использования «Использование чата»
Рисунок 4.17 - Диаграмма последовательности «Использование чата»
Рисунок 4.18 - Диаграмма кооперации «Использование чата»
Рисунок 4.19 – Экранная форма «Чат документа»
3.2 Физическое моделирование
3.2.1 Обзор популярных платформ для веб-разработки
Сегодня для разработки серверной части приложений применяются различные языки программирования и фреймворки. Можно выделить наиболее популярные из них: PHP, Ruby on Rails, Django, ASP.NET Web Forms, ASP.NET MVC, Node.js.
Первая версия PHP/FI, название которой тогда расшифровывалось как Personal Homepage Tools / Form Interpreter (персональный инструментарий для разработки домашних страниц Интернета / интерпретатор форм), вышла в 1995 году. После выхода в 1997 году PHP/FI 2 к разработке (которая до этого велась в одиночку Расмусом Лердорфом) подключились Энди Гутманс и Зив Сураски. Плодом сотрудничества стала третья версия языка, который теперь носил название PHP (hypertext preprocessor). Усовершенствования языка включали в себя новый API для расширений и позволили языку на порядок увеличить свою популярность. Ещё одним новшеством стали появившиеся в языке зачатки объектно-ориентированного программирования. Появилась возможность создавать классы и объекты на их основе, однако принципы ООП поддерживались не полностью. Так, например, нельзя было задавать области видимости переменных и методов.
Главным новшеством вышедшей в мае 2002 года PHP 4 стала компиляция в промежуточный байт-код, позволившая заметно повысить производительность языка. При этом удалось сохранить практически полную обратную совместимость с предыдущей версией. Усовершенствование ООП стало основной задачей при разработке PHP 5 (последней на данный момент версии). Выйдя в 2004 году она принесла с собой новую объектную модель и усовершенствование ООП в дальнейших обновлениях [1].
Django — свободный фреймворк для веб-приложений на языке Python, использующий шаблон проектирования MVC. Первая версия Django была выпущена в конце 2005 года. Django ориентирован на создание сложных приложений для работы с базами данных. Он содержит собственный ORM, мощную систему кэширования, обработчик адресов, основанный на регулярных выражениях, систему шаблонов [2].
Ruby on Rails — фреймворк с открытым исходным кодом, выпущенный в 2004 году. Основан на языке Ruby. Выпуск Ruby on Rails в свое время показал преимущества грамотно реализованной архитектуры MVC. Соглашения вместо конфигурирования (большинству приложений не нужна какая-либо конфигурация, за исключением нестандартных), интеграция инструмента объектно-реляционного отображения в ядро фреймворка, поддержка модульного тестирования и простота разработки позволила Ruby on Rails быстро завоевать популярность. [3] Ruby on Rails предоставляет механизмы повторного использования, позволяющие минимизировать дублирование кода в приложениях. Для упрощения разработки он уже в стандартной поставке содержит многие инструменты, такие как инструмент для скаффолдинга, поддерживает СУБД MySQL, Firebird, PostgreSQL, DB2, Oracle и Microsoft SQL Server. Также Ruby on Rails имеет систему плагинов. На март 2013 года примерно 211 тысяч сайтов было запущено на Ruby on Rails [4].
Node.js — вышедшая в 2009 году программная платформа, позволяющая использовать javascript в качестве основного языка для разработки не только клиентской, но и серверной части веб-приложения. Это удобно для разработчиков, которым вместо нескольких языков приходится иметь дело только с одним: применение некоторых нереляционных СУБД, таких как CouchDB и Mongo, позволяет использовать javascript и в качестве языка запросов к базе данных вместо SQL. Node.js основан на высокопроизводительном движке V8, компилирующем javascript непосредственно в машинный код, что делает его практически применимым даже в сложных приложениях.
Важной особенностью Node.js является обеспечение полной асинхронности операций. API Node.js просто не предоставляет средств для блокирования потока во время ожидания ввода-вывода и других операций. Это означает, что Node.js позволяет обрабатывать до нескольких десятков тысяч запросов на один ЦП, что существенно превышает возможности многих других платформ [3].
В 2002 году на смену ASP (Active Server Pages) от Microsoft пришла технология ASP.NET Web Forms. В Microsoft попытались максимально приблизить разработку веб-приложений к обычным клиентским приложениям. От программиста был скрыт не только протокол HTTP, но и язык разметки HTML. В ASP.NET Web Forms была введена такая абстракция как View State (состояние представления). Состояние представления сохраняет между запросами состояние клиентских элементов управления, по мере необходимости визуализирует их в виде HTML-разметки и позволяет обрабатывать события элементов управления на сервере. Фактически View State воссоздает в веб-среде классический управляемый событиями интерфейс пользователя.
Концепция ASP.NET Web Forms была необычной и в какой-то степени революционной, однако практическое применение её выявило ряд недостатков:
- Ресурсоемкость. Состояние представления требует передавать блоки данных, хранящие состояние элементов управления, с каждым запросом пользователя. Размер этих блоков может достигать сотен килобайт даже в относительно несложных приложениях, что ухудшает отзывчивость сайта и увеличивает требования к полосе пропускания сервера.
- Ограниченный контроль над HTML- разметкой. В ASP.NET Web Forms 3 и более ранних версиях сгенерированная разметка страницы зачастую не соответствовала стандартам, а генерируемые идентификаторы элементов управления затрудняли написание клиентского javascript.
- Сложность реализации нестандартного поведения.
- Низкая тестируемость. В момент разработки ASP.NET Web Forms модульное тестирование не было распространено так широко как сегодня, и тесно связанная архитектура фреймворка плохо подходит для его организации [3].
В 2007 году была представлена платформа ASP.NET MVC, ушедшая от состояния представления. В ней была реализована архитектура модель-представление-контроллер, и в целом ASP.NET MVC напоминала Ruby on Rails, включая в себя также преимущества других платформ, такие как асинхронные контроллеры, реализующие поведение подобное Node.js.
Однако, в отличие от Ruby on Rails, содержащей полный стек технологий, ASP.NET MVC ориентирована исключительно на обработку HTTP-запросов с помощью контроллеров и действий. Она не имеет в своем составе таких инструментов как OPM или средств автоматизированного тестирования. Это объясняется тем, что к моменту создания ASP.NET MVC платформа .NET развивалась уже достаточно долгое время, и все эти инструменты уже были созданы в разных вариациях. Потому ASP.NET MVC обладает модульной архитектурой и позволяет использовать один из множества готовых инструментов [3]. Кроме того, в распоряжении программистов находится очень функциональные библиотеки .NET Framework и множество библиотек от сторонних разработчиков.
ASP.NET MVC 2, вышедшая спустя год после первой версии, принесла множество улучшений: асинхронные контроллеры, облегчающие обработку большого количества одновременных запросов или обработку долго исполняющихся запросов, разбиение больших приложений на области (Areas), возможность отрисовки части страницы с помощью метода Html.RenderAction, улучшение проверки достоверности модели [5].
В третьей версии ASP.NET MVC появился новый, более удобный механизм визуализации Razor, улучшена поддержка внедрения зависимостей, поддержка формата JSON и javascript, более тесная интеграция с jQuery [3]. Четвертая версия сконцентрировалась на ASP.NET Web API и мобильных версиях приложений: новые шаблоны, представления в зависимости от браузера и разрешения экрана.
ASP.NET MVC 5 объединила ASP.NET MVC и ASP.NET Web Forms в одну платформу ASP.NET. Добавились новые средства для идентификации и аутентификации, стандартные шаблоны получили поддержку Twitter Bootstrap.
3.2.2 Сравнение производительности
Поскольку серверная часть приложения при работе с большим количеством пользователей будет испытывать высокую нагрузку из-за требуемой обработки поступающих от пользователей данных, производительность является одним из ключевых факторов выбора платформы.
Для сравнения производительности использовались данные тестов производительности языков программирования [6]. Поскольку синтетические тесты не всегда отображают реальную производительность, вместо них тестировались реальные программы, решающие следующие задачи:
Задача N тел: рассчитать орбитальное движение планет-гигантов вокруг Солнца.
Перестановка в массивах: каждая программа должна сгенерировать 7! массивов из элементов от 1 до 7. После чего в каждом массиве переставляются в обратном порядке m первых элементов, где m – первый элемент.
Генерация ДНК: сгенерировать и записать в выходной файл ДНК на основе заданной входной последовательности.
Спектральная норма: расчет спектральной нормы бесконечной матрицы А, где элементы матрицы a11=1, a12=1/2, a21=1/3, a13=1/4, a22=1/5, a31=1/6 и так далее.
Комплементарность: найти комплементарные пары для белков в ДНК.
Множество Мандельборта: нарисовать множество Мандельборта в bmp-файле размером 16000х16000 пикселей.
Число Пи: расчет числа Пи с точностью 27 знаков.
Бинарные деревья: создание в памяти, обход и удаление бинарных деревьев.
k-нуклеотид: создание и обновление хэш-таблицы с кодами ДНК.
ДНК: использование регулярных выражений для работы со строками на примере ДНК.
Для каждого тестируемого языка испытывалось несколько программ, в зачет шел лучший по скорости выполнения результат. Каждая задача во всех программах решалась по одинаковому алгоритму.
Все тесты проводились на компьютере следующей конфигурации: четырехъядерный центральный процессор Intel® Q6600® с частотой 2.4Ghz, 4GB ОЗУ, жесткий диск 250GB SATA II. Операционная система — Ubuntu™ 13.10, версия ядра ОС 3.11.0-15-generic. Все программы выполнялись привязанными к одному (четвёртому) ядру центрального процессора.
В таблице 3.1 показано время в секундах, затраченное программами для решения соответствующих задач. Прочерки в таблицах 3.1-3.3 означают отсутствие соответствующей программы.
Таблица 3.1 — Время выполнения программ
Задача PHP Ruby Python 3 javascript C#
Комплементарность 6.42 8.36 5.40 8.96 2.39
Генерация ДНК 63.38 149.94 221.68 18.72 6.49
Бинарные деревья 641.07 184.65 480.87 40.85 25.60
Задача N тел 704.12 659.95 916.59 35.69 22.90
Перестановка в массивах 2,959.76 2,361.65 2,349.26 76.40 50.41
k-нуклеотид 42.66 112.31 388.47 103.45 89.34
Спектральная норма 431.94 344.78 787.62 15.71 21.84
ДНК 26.35 25.21 21.77 3.71 74.99
Число Пи 2.15 11.14 2.40 - 0.28
Множество Мандельборта 1,208.59 1,864.92 1,730.60 - 0.23
В таблице 3.2 показана память в килобайтах, использованная (не просто выделенная) при решении задач.
Таблица 3.2 — Выделенная память
Задача PHP Ruby Python 3 javascript C#
Комплементарность 444,380 130,036 675,272 380,564 172,552
Генерация ДНК 3,600 7,512 6,216 9,280 16,136
Бинарные деревья 1,025,292 825,196 1,209,444 895,868 180,164
Задача N тел 3,340 7,520 6,296 9,564 15,588
Перестановка в массивах 3,264 7,512 6,152 7,232 15,540
k-нуклеотид 247,832 501,972 487,132 69,512 559,816
Спектральная норма 7,240 9,504 7,096 9,260 15,676
ДНК 219,356 164,804 200,012 418,060 282,848
Число Пи 4,284 75,152 6,928 - 868
Множество Мандельборта 4,276 7,508 100,660 - 608
В таблице 3.3 показан объём программного кода в байтах программ, использовавшихся при решении задач.
Таблица 3.3 — Объём кода
Задача PHP Ruby Python 3 javascript C#
Комплементарность 262 255 325 787 1099
Генерация ДНК 1110 987 792 791 1180
Бинарные деревья 472 412 626 467 654
Задача N тел 1082 1137 1181 1287 1305
Перестановка в массивах 441 384 385 539 564
k-нуклеотид 1036 449 647 1249 1696
Спектральная норма 397 326 328 328 1063
ДНК 459 442 424 373 594
Число Пи 394 240 255 - 1026
Множество Мандельборта 443 307 777 - 872
Как видно из таблиц, в большинстве задач программы, написанные на языке C#, являются быстрейшими по скорости выполнения. В ключевых для данного дипломного проекта задачах манипуляции структурами данных — бинарных деревьях и перестановках в массивах — преимущество перед такими языками как PHP, Ruby и Python достигает 7-45 раз. javascript в этих задачах уступает C# примерно в полтора раза. Явный лидер в краткости кода — язык Ruby, который выигрывает у худшего по объему программ C# до четырех раз.
3.2.3 Выбор платформы
По функциональности представленные платформы отличаются не сильно [7], притом имея модульную структуру, позволяющую быстро нарастить недостающую функциональность. Потому на первый план выходит производительность, и тут лучшим является язык C#, на котором основаны платформы ASP.NET Web Forms и ASP.NET MVC.
При выборе из этих двух платформ нужно учесть, что значительная часть кода приложения должна исполняться на клиентской стороне, чтобы избежать постоянной передачи очень больших объёмов данных между клиентами и сервером и результирующей перегрузки каналов связи. При этом концепция View State из ASP.NET Web Forms не даст нам никаких преимуществ, и принесет с собой в основном недостатки, такие как ресурсоемкость и низкую тестируемость. Потому в качестве платформы реализации серверной части выберем ASP.NET MVC.
3.2.4 Выбор компонентов
Ключевой частью проекта является обмен данными между клиентами и сервером. Нужно найти технологию, которая позволит передавать пакеты данных между клиентами и сервером без перезагрузки страницы.
Изначально для этого использовался AJAX, но ключевым его недостатком является то, что он предназначен для передачи данных от клиента к серверу. При этом сервер не имеет возможности в произвольный момент отправить данные клиенту. Для обхода этого можно использовать регулярный опрос сервера (см. рис. 2.1).
Рисунок 4.20 — Регулярный опрос сервера
У этого метода есть крупный недостаток. Постоянные запросы на сервер создают нагрузку даже при отсутствии данных, передача которых необходима. Если увеличить интервал между запросами, увеличатся задержки, что неприемлемо.
Для устранения этого недостатка была создана модель Comet, в которой запрос отправляется на сервер и сохраняется в нем в течение длительного времени, пока не сработает таймер или не произойдет событие на сервере. Когда запрос выполнен, отправляется следующий долгоживущий Ajax-запрос в ожидании других событий на сервере. Comet позволяет Web-серверу отправлять данные клиенту без явного запроса с его стороны.
Рисунок 4.21 — Модель Comet
Преимуществом Comet является простота реализации, недостатками - отсутствие обработки ошибок, невозможность получить информацию о состоянии соединения или прервать его [8].
С приходом HTML5 появилось еще одно средство реализации клиент-серверного обмена данными: WebSockets. WebSockets создает двунаправленные, дуплексные каналы связи (см. рис. 2.3). Соединение открывается посредством HTTP-запроса со специальными заголовками, который называется рукопожатием WebSockets. Это соединение сохраняется постоянно, и через него можно записывать и получать данные посредством javascript, как при использовании стандартного сокета TCP [9].
Рисунок 4.22 — WebSockets
Недостатком WebSockets изначально была слабая поддержка браузерами, но к настоящему моменту все современные браузеры полностью поддерживают этот протокол.
Потому в качестве протокола клиент-серверного обмена данными будет использоваться WebSockets. Для практической реализации WebSockets на платформе ASP.NET MVC наиболее известны две библиотеки: SignalR и XSockets.NET. При этом у XSockets.NET есть несколько существенных преимуществ. В отличие от SignalR, этой библиотеке не обязателен установленный IIS 8 в качестве сервера, что не ограничивает список серверных операционных систем Windows 2012 Server и Windows 8. Это на порядок расширяет список доступных хостингов. Ещё одной важной функцией XSockets является сохранение на сервере состояния клиента, что очень удобно на практике. Кроме того, XSockets может передавать клиенту сообщения «в оффлайн», которые тот получит после подключения к серверу. К преимуществам SignalR стоит отнести больший список поддерживаемых транспортов: сверх WebSockets и Long polling, поддерживаемых XSockets, SignalR может использовать Server-Sent Events и Forever Frame. Альтернативные транспорты используются когда невозможно использовать WebSockets, например при устаревшем браузере у клиента [10].
В качестве основы для редактора текста будет использоваться CodeMirror, поддерживающий современные браузеры и имеющий развитое API для отслеживания изменений в тексте, применения изменений, работы с историей документа и управления стилями. К сожалению, CodeMirror не поддерживает форматирование документа стандартными тегами HTML, такими как , но использование CSS-стилей позволяет обойти этот недостаток, а при необходимости экспорта документа в формате HTML стили можно заменить на стороне сервера, вернув клиенту чистый HTML.
3.2.5 Построение диаграмм компонентов
На рисунке 4.23 показана диаграмма компонентов серверной части приложения
Рисунок 4.23 — Диаграмма компонентов серверной части приложения
3.2.6 Построение диаграмм размещения
На рисунке 4.24 показана диаграмма развёртывания приложения
Рисунок 5.7 — Диаграмма развертывания приложения
3.1 Логическое моделирование
3.1.1 Модель AS-IS
Построению модели AS-IS предшествовало исследование обычно использующихся методик работы нескольких человек над одним документом. Упомянутое включало в себя работу автора документа (редактирование текста документа, изменение форматирования).
При этом один из редакторов открывает документ (никто другой не должен в данный момент времени его изменять), вносит правки в текст или форматирование и сохраняет файл. После этого монопольный доступ к файлу может получить другой автор. Возможно только последовательное редактирование одного файла разными авторами, поскольку при одновременной работе более позднее сохранение файла перезапишет все внесенные ранее изменения. Для хранения редактируемых файлов может использоваться FTP-сервер или облачное хранилище.
На основании полученной при этом информации была построена модель AS-IS, показанная на диаграммах рис. 3.1-3.3 и представляющая собой «снимок» существующего положения дел.
Рисунок 3.1 – Контекстная диаграмма.
Рисунок 3.2 - Декомпозиция контекстной диаграммы
Здесь используется последовательное редактирование документа несколькими пользователями, сам документ хранится в облачном хранилище, FTP-сервере или другом месте с удобным доступом к нему пользователей (например, в локальной сети). После редактирования документа одним пользователем он вновь сохраняется в хранилище, откуда следующий пользователь может взять свежую версию и продолжить работу.
Рисунок 3.3 – Диаграмма дерева узлов
3.1.2 Модель TO-BE
Существенным недостатком модели AS-IS является невозможность действительно одновременного редактирования документа. На самом деле это процесс последовательных изменений файла разными пользователями. Два человека не могут работать над файлом одновременно, поскольку последний пользователь, сохранивший документ, перепишет все изменения, внесенные в документ между открытием документа пользователем и его сохранением. Это снижает удобство процесса и предъявляет требования к координации работы, а также замедляет её: вместо того, чтобы одновременно работать над разными участками документа, пользователям приходится ждать, когда тот станет доступным для редактирования. Ещё одним недостатком такого метода является то, что, как правило, сообщение другим пользователям о внесенных в документ изменениях требует дополнительных усилий. Это или пометки в самом документе (требующие удаления впоследствии) или сообщение лично, что в случае размещения пользователей в разных помещениях (или даже в разных странах) требует применения дополнительных технических средств: телефона, систем мгновенного обмена сообщениями, электронной почты.
На наш взгляд для улучшения существующей ситуации следует изменить существующую систему так, чтобы было возможно одновременное редактирование документа несколькими пользователями. При этом сам документ будет храниться в базе данных веб-сервера, а доступ к нему будет предоставляться через специальное приложение. С учетом сказанного была построена модель TO-BE, показанная на диаграммах 3.4-3.6
Рисунок 3.4 – Контекстная диаграмма
Рисунок 3.5 – Декомпозиция контекстной диаграммы
Здесь представлена декомпозиция контекстного процесса «совместное редактирование документа» на процессы «запрос документа», «редактирование документа и «серверная обработка данных».
Рисунок 3.6 – Декомпозиция дерева узлов
3.1.3 Выбор методологий моделирования и инструментария
Для построения моделей бизнес-процессов можно использовать CASE-средства BЗwin, AllFusion Process Modeler, графический редактор Visio и другие инструментальные средства. В данном случае предпочтение было отдано средствам Enterprise Architect и ERWin — развитию BPwin.
3.1.4 Разработка диаграмм вариантов использования
Перед разработкой диаграммы вариантов использования определим список вариантов использования:
- Вход в систему;
- Редактирование прав пользователя;
- Работа с документом:
- Создание документа;
- Редактирование документа;
- Использование привязанного к документу чата:
- Просмотр сообщений;
- Отправка сообщений;
На рисунке 3.7 показана разработанная диаграмма вариантов использования.
Рисунок 3.7 – диаграмма вариантов использования
3.1.5 Описание вариантов использования
3.1.5.1 Описание варианта использования «Вход в систему»
Назначение. Данный вариант использования описывает вход пользователя в систему.
Основной поток событий. Данный вариант использования выполняется, когда Пользователь хочет войти в систему.
Система запрашивает имя пользователя и пароль;
Пользователь вводит имя и пароль;
Система проверяет введенные имя и пароль, после чего открывает доступ в систему в соответствии с ролью Пользователя в ней;
Альтернативные потоки событий:
1) Неправильное имя и/или пароль. Если во время выполнения основного потока обнаружится, что пользователь ввел неверное имя и/или пароль, то система выводит сообщение об ошибке. Пользователь может вернуться к началу основного потока или отказаться от входа в систему (при этом выполнение варианта использования завершается).
2) Пользователь заблокирован в системе. Во время выполнения основного потока может обнаружиться, что доступ пользователя в систему заблокирован администратором. В этом случае система выводит сообщение об ошибке.
Предусловия. Отсутствуют.
Постусловие. Если вариант использования выполнен успешно, пользователь входит в систему. В противном случае состояние системы не изменится.
3.1.5.2 Описание варианта использования «Управление пользователями»
Назначение. Данный вариант использования позволяет Администратору устанавливать определенным пользователям разрешения на выполнение тех или иных действий.
Основной поток событий. Данный вариант использования начинает выполняться, когда Администратор хочет изменить права определенного пользователя.
Система запрашивает имя пользователя для изменения;
Администратор вводит имя;
Система отображает страницу редактирования информации пользователя;
Администратор изменяет права пользователя и запрашивает сохранение информации;
Система сохраняет изменения;
Альтернативный поток событий. Не существует пользователя с таким именем. Если во время выполнения основного потока обнаружится, что в системе отсутствует пользователь с заданным именем, система выдаст ошибку и вернет Администратора к шагу 1 основного потока.
Предусловие. Перед началом выполнения данного варианта использования Администратор должен войти в систему.
Постусловие. Если вариант использования завершится успешно, права пользователя будут изменены. В противном случае состояние системы не изменится.
3.1.5.4 Описание варианта использования «Изменение прав пользователя»
Назначение. Данный вариант использования позволяет Администратору устанавливать необходимость наличия у пользователей определенных прав для выполнения тех или иных операций над документом.
Основной поток событий:
Администратор страницу изменения прав пользователя.
Администратор устанавливает права доступа
Система сохраняет измененные права и приводит их в исполнение.
Альтернативный поток событий. Документ просматривают пользователи, которым согласно вновь установленным правам просмотр запрещён. В данном случае пользователю должно быть выдано соответствующее сообщение и закрыт доступ к документу.
Предусловие. Перед началом выполнения данного варианта использования Администратор должен войти в систему.
Постусловие. Если вариант использования завершится успешно, права доступа будут изменены, а сам документ сохранится в неизменном состоянии.
3.1.5.5 Описание варианта использования «Работа с документом»
Назначение. Данный вариант использования позволяет Пользователю просматривать, изменять и экспортировать документ.
Основной поток событий. Пользователь открывает документ из списка документов, доступных ему, или воспользовавшись постоянной прямой ссылкой на документ. Система отображает выбранный документ. После этого выполняется один из подчиненных потоков: просмотр документа, его редактирование или экспорт
Просмотр документа. Документ отображается в отдельном поле на веб-странице вместе со списком просматривающих документ пользователей и чатом.
Изменение документа
— Пользователь изменяет документ, пользуясь клавиатурным вводом и командами с панели инструментов;
— Все изменения в документе в реальном времени передаются на сервер и сохраняются в базе данных;
— С сервера внесенные изменения рассылаются остальным пользователям, просматривающим документ, и отображаются в теле документа.
Альтернативные потоки:
Пользователь не имеет прав на просмотр документа. Система выдает сообщение об ошибке и перенаправляет Пользователя к списку документов.
Пользователь не имеет прав на редактирование документа. Система блокирует попытки пользователя изменить документ на локальной машине и не принимает его изменения на сервере.
Потеряна связь с сервером во время редактирования. Изменения, внесенные после потери связи с сервером, отменяются, а возможность внесения новых блокируется. Пользователю должно быть выдано сообщение об ошибке и предложение переподключиться к серверу.
Предусловие. Пользователь должен иметь права на необходимые действия.
Постусловия. Нет
3.1.5.6 Описание варианта использования «Использование чата»
Назначение. Данный вариант использования позволяет Пользователю просматривать сообщения чата и писать новые.
Основной поток событий. Пользователь открывает документ из списка документов, доступных ему, или воспользовавшись постоянной прямой ссылкой на документ. Система отображает выбранный документ. После этого выполняется один из подчиненных потоков: просмотр сообщений или их написание
Просмотр сообщений чата:
— Система отображает 25 последних сообщений чата документа;
— При появлении новых сообщений те показываются внизу списка;
Отправка сообщений в чат:
— Пользователь пишет и отправляет сообщение;
— Все сообщения в реальном времени передаются на сервер и сохраняются в базе данных;
— С сервера сообщения рассылаются остальным пользователям, просматривающим документ, и отображаются в области чата;
Альтернативный поток. Пользователь не имеет прав на просмотр документа. Система блокирует пользователю доступ к отправке сообщений на локальной машине и не принимает его сообщения на сервере.
Предусловия. Нет
Постусловия. Нет
3.1.6 Построение логической модели данных
В результате анализа входящих/исходящих потоков и оптимизации их содержимого были выделены сущности пользователя, документа, атомарного изменения в документе, пользовательского цвета, сообщения в чате и роли.
После выявления отношений между сущностями была построена логическая модель, показанная ниже на различных уровнях: сущностей (рис 3.8) и атрибутов (рис 3.9).
Рисунок 3.8 — Уровень сущностей
Рисунок 3.9 — Уровень атрибутов
3.1.7 Разработка сценариев и макетов экранных форм
3.1.7.1 Вариант использования «Вход в систему»
Рисунок 3.10 - Диаграмма последовательности «Вход в систему»
Рисунок 3.11 - Диаграмма кооперации «Вход в систему»
Рисунок 3.12 – Макет страницы «Вход в систему»
3.1.7.2 Вариант использования «Управление пользователями»
Рисунок 3.13 - Диаграмма последовательности «Управление пользователями»
Рисунок 3.14 – Диаграмма кооперации «Управление пользователями»
Рисунок 4.10 – Макет страницы «Управление пользователями»
3.1.7.3 Вариант использования «Изменение прав пользователя»
Рисунок 4.11 - Диаграмма последовательности «Изменение прав пользователя»
Рисунок 4.12 - Диаграмма кооперации «Изменение прав пользователя»
Рисунок 4.13 – Макет диалога «Изменение прав пользователя»
3.1.7.4 Вариант использования «Работа с документом»
Рисунок 4.14 - Диаграмма последовательности «Работа с документом»
Рисунок 4.15 - Диаграмма кооперации «Работа с документом»
Рисунок 4.16 – Экранная форма «Работа с документом»
3.1.7.5 Вариант использования «Использование чата»
Рисунок 4.17 - Диаграмма последовательности «Использование чата»
Рисунок 4.18 - Диаграмма кооперации «Использование чата»
Рисунок 4.19 – Экранная форма «Чат документа»
3.2 Физическое моделирование
3.2.1 Обзор популярных платформ для веб-разработки
Сегодня для разработки серверной части приложений применяются различные языки программирования и фреймворки. Можно выделить наиболее популярные из них: PHP, Ruby on Rails, Django, ASP.NET Web Forms, ASP.NET MVC, Node.js.
Первая версия PHP/FI, название которой тогда расшифровывалось как Personal Homepage Tools / Form Interpreter (персональный инструментарий для разработки домашних страниц Интернета / интерпретатор форм), вышла в 1995 году. После выхода в 1997 году PHP/FI 2 к разработке (которая до этого велась в одиночку Расмусом Лердорфом) подключились Энди Гутманс и Зив Сураски. Плодом сотрудничества стала третья версия языка, который теперь носил название PHP (hypertext preprocessor). Усовершенствования языка включали в себя новый API для расширений и позволили языку на порядок увеличить свою популярность. Ещё одним новшеством стали появившиеся в языке зачатки объектно-ориентированного программирования. Появилась возможность создавать классы и объекты на их основе, однако принципы ООП поддерживались не полностью. Так, например, нельзя было задавать области видимости переменных и методов.
Главным новшеством вышедшей в мае 2002 года PHP 4 стала компиляция в промежуточный байт-код, позволившая заметно повысить производительность языка. При этом удалось сохранить практически полную обратную совместимость с предыдущей версией. Усовершенствование ООП стало основной задачей при разработке PHP 5 (последней на данный момент версии). Выйдя в 2004 году она принесла с собой новую объектную модель и усовершенствование ООП в дальнейших обновлениях [1].
Django — свободный фреймворк для веб-приложений на языке Python, использующий шаблон проектирования MVC. Первая версия Django была выпущена в конце 2005 года. Django ориентирован на создание сложных приложений для работы с базами данных. Он содержит собственный ORM, мощную систему кэширования, обработчик адресов, основанный на регулярных выражениях, систему шаблонов [2].
Ruby on Rails — фреймворк с открытым исходным кодом, выпущенный в 2004 году. Основан на языке Ruby. Выпуск Ruby on Rails в свое время показал преимущества грамотно реализованной архитектуры MVC. Соглашения вместо конфигурирования (большинству приложений не нужна какая-либо конфигурация, за исключением нестандартных), интеграция инструмента объектно-реляционного отображения в ядро фреймворка, поддержка модульного тестирования и простота разработки позволила Ruby on Rails быстро завоевать популярность. [3] Ruby on Rails предоставляет механизмы повторного использования, позволяющие минимизировать дублирование кода в приложениях. Для упрощения разработки он уже в стандартной поставке содержит многие инструменты, такие как инструмент для скаффолдинга, поддерживает СУБД MySQL, Firebird, PostgreSQL, DB2, Oracle и Microsoft SQL Server. Также Ruby on Rails имеет систему плагинов. На март 2013 года примерно 211 тысяч сайтов было запущено на Ruby on Rails [4].
Node.js — вышедшая в 2009 году программная платформа, позволяющая использовать javascript в качестве основного языка для разработки не только клиентской, но и серверной части веб-приложения. Это удобно для разработчиков, которым вместо нескольких языков приходится иметь дело только с одним: применение некоторых нереляционных СУБД, таких как CouchDB и Mongo, позволяет использовать javascript и в качестве языка запросов к базе данных вместо SQL. Node.js основан на высокопроизводительном движке V8, компилирующем javascript непосредственно в машинный код, что делает его практически применимым даже в сложных приложениях.
Важной особенностью Node.js является обеспечение полной асинхронности операций. API Node.js просто не предоставляет средств для блокирования потока во время ожидания ввода-вывода и других операций. Это означает, что Node.js позволяет обрабатывать до нескольких десятков тысяч запросов на один ЦП, что существенно превышает возможности многих других платформ [3].
В 2002 году на смену ASP (Active Server Pages) от Microsoft пришла технология ASP.NET Web Forms. В Microsoft попытались максимально приблизить разработку веб-приложений к обычным клиентским приложениям. От программиста был скрыт не только протокол HTTP, но и язык разметки HTML. В ASP.NET Web Forms была введена такая абстракция как View State (состояние представления). Состояние представления сохраняет между запросами состояние клиентских элементов управления, по мере необходимости визуализирует их в виде HTML-разметки и позволяет обрабатывать события элементов управления на сервере. Фактически View State воссоздает в веб-среде классический управляемый событиями интерфейс пользователя.
Концепция ASP.NET Web Forms была необычной и в какой-то степени революционной, однако практическое применение её выявило ряд недостатков:
- Ресурсоемкость. Состояние представления требует передавать блоки данных, хранящие состояние элементов управления, с каждым запросом пользователя. Размер этих блоков может достигать сотен килобайт даже в относительно несложных приложениях, что ухудшает отзывчивость сайта и увеличивает требования к полосе пропускания сервера.
- Ограниченный контроль над HTML- разметкой. В ASP.NET Web Forms 3 и более ранних версиях сгенерированная разметка страницы зачастую не соответствовала стандартам, а генерируемые идентификаторы элементов управления затрудняли написание клиентского javascript.
- Сложность реализации нестандартного поведения.
- Низкая тестируемость. В момент разработки ASP.NET Web Forms модульное тестирование не было распространено так широко как сегодня, и тесно связанная архитектура фреймворка плохо подходит для его организации [3].
В 2007 году была представлена платформа ASP.NET MVC, ушедшая от состояния представления. В ней была реализована архитектура модель-представление-контроллер, и в целом ASP.NET MVC напоминала Ruby on Rails, включая в себя также преимущества других платформ, такие как асинхронные контроллеры, реализующие поведение подобное Node.js.
Однако, в отличие от Ruby on Rails, содержащей полный стек технологий, ASP.NET MVC ориентирована исключительно на обработку HTTP-запросов с помощью контроллеров и действий. Она не имеет в своем составе таких инструментов как OPM или средств автоматизированного тестирования. Это объясняется тем, что к моменту создания ASP.NET MVC платформа .NET развивалась уже достаточно долгое время, и все эти инструменты уже были созданы в разных вариациях. Потому ASP.NET MVC обладает модульной архитектурой и позволяет использовать один из множества готовых инструментов [3]. Кроме того, в распоряжении программистов находится очень функциональные библиотеки .NET Framework и множество библиотек от сторонних разработчиков.
ASP.NET MVC 2, вышедшая спустя год после первой версии, принесла множество улучшений: асинхронные контроллеры, облегчающие обработку большого количества одновременных запросов или обработку долго исполняющихся запросов, разбиение больших приложений на области (Areas), возможность отрисовки части страницы с помощью метода Html.RenderAction, улучшение проверки достоверности модели [5].
В третьей версии ASP.NET MVC появился новый, более удобный механизм визуализации Razor, улучшена поддержка внедрения зависимостей, поддержка формата JSON и javascript, более тесная интеграция с jQuery [3]. Четвертая версия сконцентрировалась на ASP.NET Web API и мобильных версиях приложений: новые шаблоны, представления в зависимости от браузера и разрешения экрана.
ASP.NET MVC 5 объединила ASP.NET MVC и ASP.NET Web Forms в одну платформу ASP.NET. Добавились новые средства для идентификации и аутентификации, стандартные шаблоны получили поддержку Twitter Bootstrap.
3.2.2 Сравнение производительности
Поскольку серверная часть приложения при работе с большим количеством пользователей будет испытывать высокую нагрузку из-за требуемой обработки поступающих от пользователей данных, производительность является одним из ключевых факторов выбора платформы.
Для сравнения производительности использовались данные тестов производительности языков программирования [6]. Поскольку синтетические тесты не всегда отображают реальную производительность, вместо них тестировались реальные программы, решающие следующие задачи:
Задача N тел: рассчитать орбитальное движение планет-гигантов вокруг Солнца.
Перестановка в массивах: каждая программа должна сгенерировать 7! массивов из элементов от 1 до 7. После чего в каждом массиве переставляются в обратном порядке m первых элементов, где m – первый элемент.
Генерация ДНК: сгенерировать и записать в выходной файл ДНК на основе заданной входной последовательности.
Спектральная норма: расчет спектральной нормы бесконечной матрицы А, где элементы матрицы a11=1, a12=1/2, a21=1/3, a13=1/4, a22=1/5, a31=1/6 и так далее.
Комплементарность: найти комплементарные пары для белков в ДНК.
Множество Мандельборта: нарисовать множество Мандельборта в bmp-файле размером 16000х16000 пикселей.
Число Пи: расчет числа Пи с точностью 27 знаков.
Бинарные деревья: создание в памяти, обход и удаление бинарных деревьев.
k-нуклеотид: создание и обновление хэш-таблицы с кодами ДНК.
ДНК: использование регулярных выражений для работы со строками на примере ДНК.
Для каждого тестируемого языка испытывалось несколько программ, в зачет шел лучший по скорости выполнения результат. Каждая задача во всех программах решалась по одинаковому алгоритму.
Все тесты проводились на компьютере следующей конфигурации: четырехъядерный центральный процессор Intel® Q6600® с частотой 2.4Ghz, 4GB ОЗУ, жесткий диск 250GB SATA II. Операционная система — Ubuntu™ 13.10, версия ядра ОС 3.11.0-15-generic. Все программы выполнялись привязанными к одному (четвёртому) ядру центрального процессора.
В таблице 3.1 показано время в секундах, затраченное программами для решения соответствующих задач. Прочерки в таблицах 3.1-3.3 означают отсутствие соответствующей программы.
Таблица 3.1 — Время выполнения программ
Задача PHP Ruby Python 3 javascript C#
Комплементарность 6.42 8.36 5.40 8.96 2.39
Генерация ДНК 63.38 149.94 221.68 18.72 6.49
Бинарные деревья 641.07 184.65 480.87 40.85 25.60
Задача N тел 704.12 659.95 916.59 35.69 22.90
Перестановка в массивах 2,959.76 2,361.65 2,349.26 76.40 50.41
k-нуклеотид 42.66 112.31 388.47 103.45 89.34
Спектральная норма 431.94 344.78 787.62 15.71 21.84
ДНК 26.35 25.21 21.77 3.71 74.99
Число Пи 2.15 11.14 2.40 - 0.28
Множество Мандельборта 1,208.59 1,864.92 1,730.60 - 0.23
В таблице 3.2 показана память в килобайтах, использованная (не просто выделенная) при решении задач.
Таблица 3.2 — Выделенная память
Задача PHP Ruby Python 3 javascript C#
Комплементарность 444,380 130,036 675,272 380,564 172,552
Генерация ДНК 3,600 7,512 6,216 9,280 16,136
Бинарные деревья 1,025,292 825,196 1,209,444 895,868 180,164
Задача N тел 3,340 7,520 6,296 9,564 15,588
Перестановка в массивах 3,264 7,512 6,152 7,232 15,540
k-нуклеотид 247,832 501,972 487,132 69,512 559,816
Спектральная норма 7,240 9,504 7,096 9,260 15,676
ДНК 219,356 164,804 200,012 418,060 282,848
Число Пи 4,284 75,152 6,928 - 868
Множество Мандельборта 4,276 7,508 100,660 - 608
В таблице 3.3 показан объём программного кода в байтах программ, использовавшихся при решении задач.
Таблица 3.3 — Объём кода
Задача PHP Ruby Python 3 javascript C#
Комплементарность 262 255 325 787 1099
Генерация ДНК 1110 987 792 791 1180
Бинарные деревья 472 412 626 467 654
Задача N тел 1082 1137 1181 1287 1305
Перестановка в массивах 441 384 385 539 564
k-нуклеотид 1036 449 647 1249 1696
Спектральная норма 397 326 328 328 1063
ДНК 459 442 424 373 594
Число Пи 394 240 255 - 1026
Множество Мандельборта 443 307 777 - 872
Как видно из таблиц, в большинстве задач программы, написанные на языке C#, являются быстрейшими по скорости выполнения. В ключевых для данного дипломного проекта задачах манипуляции структурами данных — бинарных деревьях и перестановках в массивах — преимущество перед такими языками как PHP, Ruby и Python достигает 7-45 раз. javascript в этих задачах уступает C# примерно в полтора раза. Явный лидер в краткости кода — язык Ruby, который выигрывает у худшего по объему программ C# до четырех раз.
3.2.3 Выбор платформы
По функциональности представленные платформы отличаются не сильно [7], притом имея модульную структуру, позволяющую быстро нарастить недостающую функциональность. Потому на первый план выходит производительность, и тут лучшим является язык C#, на котором основаны платформы ASP.NET Web Forms и ASP.NET MVC.
При выборе из этих двух платформ нужно учесть, что значительная часть кода приложения должна исполняться на клиентской стороне, чтобы избежать постоянной передачи очень больших объёмов данных между клиентами и сервером и результирующей перегрузки каналов связи. При этом концепция View State из ASP.NET Web Forms не даст нам никаких преимуществ, и принесет с собой в основном недостатки, такие как ресурсоемкость и низкую тестируемость. Потому в качестве платформы реализации серверной части выберем ASP.NET MVC.
3.2.4 Выбор компонентов
Ключевой частью проекта является обмен данными между клиентами и сервером. Нужно найти технологию, которая позволит передавать пакеты данных между клиентами и сервером без перезагрузки страницы.
Изначально для этого использовался AJAX, но ключевым его недостатком является то, что он предназначен для передачи данных от клиента к серверу. При этом сервер не имеет возможности в произвольный момент отправить данные клиенту. Для обхода этого можно использовать регулярный опрос сервера (см. рис. 2.1).
Рисунок 4.20 — Регулярный опрос сервера
У этого метода есть крупный недостаток. Постоянные запросы на сервер создают нагрузку даже при отсутствии данных, передача которых необходима. Если увеличить интервал между запросами, увеличатся задержки, что неприемлемо.
Для устранения этого недостатка была создана модель Comet, в которой запрос отправляется на сервер и сохраняется в нем в течение длительного времени, пока не сработает таймер или не произойдет событие на сервере. Когда запрос выполнен, отправляется следующий долгоживущий Ajax-запрос в ожидании других событий на сервере. Comet позволяет Web-серверу отправлять данные клиенту без явного запроса с его стороны.
Рисунок 4.21 — Модель Comet
Преимуществом Comet является простота реализации, недостатками - отсутствие обработки ошибок, невозможность получить информацию о состоянии соединения или прервать его [8].
С приходом HTML5 появилось еще одно средство реализации клиент-серверного обмена данными: WebSockets. WebSockets создает двунаправленные, дуплексные каналы связи (см. рис. 2.3). Соединение открывается посредством HTTP-запроса со специальными заголовками, который называется рукопожатием WebSockets. Это соединение сохраняется постоянно, и через него можно записывать и получать данные посредством javascript, как при использовании стандартного сокета TCP [9].
Рисунок 4.22 — WebSockets
Недостатком WebSockets изначально была слабая поддержка браузерами, но к настоящему моменту все современные браузеры полностью поддерживают этот протокол.
Потому в качестве протокола клиент-серверного обмена данными будет использоваться WebSockets. Для практической реализации WebSockets на платформе ASP.NET MVC наиболее известны две библиотеки: SignalR и XSockets.NET. При этом у XSockets.NET есть несколько существенных преимуществ. В отличие от SignalR, этой библиотеке не обязателен установленный IIS 8 в качестве сервера, что не ограничивает список серверных операционных систем Windows 2012 Server и Windows 8. Это на порядок расширяет список доступных хостингов. Ещё одной важной функцией XSockets является сохранение на сервере состояния клиента, что очень удобно на практике. Кроме того, XSockets может передавать клиенту сообщения «в оффлайн», которые тот получит после подключения к серверу. К преимуществам SignalR стоит отнести больший список поддерживаемых транспортов: сверх WebSockets и Long polling, поддерживаемых XSockets, SignalR может использовать Server-Sent Events и Forever Frame. Альтернативные транспорты используются когда невозможно использовать WebSockets, например при устаревшем браузере у клиента [10].
В качестве основы для редактора текста будет использоваться CodeMirror, поддерживающий современные браузеры и имеющий развитое API для отслеживания изменений в тексте, применения изменений, работы с историей документа и управления стилями. К сожалению, CodeMirror не поддерживает форматирование документа стандартными тегами HTML, такими как , но использование CSS-стилей позволяет обойти этот недостаток, а при необходимости экспорта документа в формате HTML стили можно заменить на стороне сервера, вернув клиенту чистый HTML.
3.2.5 Построение диаграмм компонентов
На рисунке 4.23 показана диаграмма компонентов серверной части приложения
Рисунок 4.23 — Диаграмма компонентов серверной части приложения
3.2.6 Построение диаграмм размещения
На рисунке 4.24 показана диаграмма развёртывания приложения
Рисунок 5.7 — Диаграмма развертывания приложения