ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ 6
1 ОБЗОР СОСТОЯНИЯ ВОПРОСА 8
2 ЦЕЛЬ И ЗАДАЧИ ПРОЕКТА 13
3 МОДЕЛИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 14
3.1 Логическое моделирование 14
3.1.1 Модель AS-IS 14
3.1.2 Модель TO-BE 16
3.1.3 Выбор методологий моделирования и инструментария 18
3.1.4 Разработка диаграмм вариантов использования 18
3.1.5 Описание вариантов использования 20
3.1.5.1 Описание варианта использования «Вход в систему» 20
3.1.5.2 Описание варианта использования «Управление пользователями» 21
3.1.5.4 Описание варианта использования «Изменение прав пользователя» 22
3.1.5.5 Описание варианта использования «Работа с документом» 22
3.1.5.6 Описание варианта использования «Использование чата» 23
3.1.6 Построение логической модели данных 24
3.1.7 Разработка сценариев и макетов экранных форм 25
3.1.7.1 Вариант использования «Вход в систему» 25
3.1.7.2 Вариант использования «Управление пользователями» 27
3.1.7.3 Вариант использования «Изменение прав пользователя» 28
3.1.7.4 Вариант использования «Работа с документом» 29
3.1.7.5 Вариант использования «Использование чата» 31
3.2 Физическое моделирование 32
3.2.1 Обзор популярных платформ для веб-разработки 32
3.2.2 Сравнение производительности 35
3.2.3 Выбор платформы 38
3.2.4 Выбор компонентов 38
3.2.5 Построение диаграмм компонентов 41
3.2.6 Построение диаграмм размещения 41
4 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 42
4.1 Приложение 42
4.2 Пользовательский интерфейс 45
5 РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ 49
6 ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 53
7 ОХРАНА ТРУДА 54
7.1 Производственная санитария, техника безопасности и пожарная профилактика 54
7.1.1 Метеоусловия 55
7.1.2 Вентиляция и отопление 56
7.1.3 Освещение 58
7.1.4 Шум 59
7.1.5 Электробезопасность 60
7.1.6 Излучение 60
7.1.7 Пожарная безопасность 62
7.2. Расчет величины тока, проходящего через организм человека 63
8 ОПРЕДЕЛЕНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ ПО 66
8.1 Определение трудоемкости разработки ПП 66
8.2 Определение себестоимости создания программного продукта 69
8.3 Определение ожидаемого прироста прибыли в результате внедрения ПП 75
8.2 Расчет показателей эффективности использования программного продукта. 77
ЗАКЛЮЧЕНИЕ 79
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 80
ВВЕДЕНИЕ
С развитием сети Интернет и широким распространением локальных вычислительных сетей все большей популярностью пользуется совместное редактирование информации. Для текстовой информации можно привести в пример различные системы контроля версий (SVN, Git, Mercurial и другие), Википедию и подобные сайты, прочие инструменты, такие как GoogleDocs.
Программное обеспечение для совместного редактирования информации можно разделить на несколько групп:
— Системы контроля версий. Конфликты, как правило, разрешаются вручную, синхронизация происходит только по желанию пользователя;
— Десктопныеприложения, такиекакAbiword, ACE, CoWord, MicrosoftOffice, MoonEdit и другие;
— Работающие в браузере приложения, такие как Kune, GoogleDocs, GoogleWave (разработка и поддержка прекращена), Etherpad (разработка и поддержка прекращена), Firepadи другие.
Оставив за кадром системы контроля версий, подробнее сравним между собой варианты десктопного и браузерного приложения совместного редактирования.
Плюсы десктопных приложений:
— После установки всегда готовы к работе;
— Могут работать без подключения к Интернеру или локальной вычислительной сети;
— Как правило, поддерживают разнообразные форматы файлов.
Минусом таких приложений является то, что они требуют установки на пользовательский компьютер или, как минимум, скачивания дистрибутива.
Плюсы браузерных приложений:
— Доступность. Не нужно скачивать и устанавливать дистрибутивы, зачастую для чтения или редактирования документа достаточно перейти по прямой ссылке;
— Кроссплатформенность. Они не ограничиваются платформой, для которой велась разработка, работая на устройствах с различными операционными системами, в том числе на планшетах и мобильных телефонах;
Минусы браузерных приложений:
— Необходимость подключения к ети Интернет или ЛВС;
— Поддержка разнообразных браузеров и разрешений экрана требует определенных усилий от разработчика;
— Ограниченность протоколом HTTP. Невозможно, например, создать распределенное p2pприложение, не зависящее от центрального сервера.
Поскольку доступность является важным параметром, будет разработано именно браузерное приложение для совместного редактирования текста.
Пояснительная записка содержит следующие разделы:
− Обзор состояния вопроса. В данном разделе дается определение понятию «Управление проектами» и проводится обзор существующих на данный момент систем управления проектами. Также в разделе описывается язык программирования Scala и проводится обзор его преимущества перед другими языками.
− Цель и задачи проекта. Раздел посвящен описанию цели и задач, предстоящих к решению в проекте.
− Моделирование программного обеспечения. Целью раздела является логическое и физическое моделирование приложения. В логическом моделировании приводятся контекстные диаграммы для моделей AS-IS и TO-BE, а также декомпозиция диаграммы AS-ISна процессы.Здесь же рассматриваются различные варианты использования приложения и создаются спецификации процессов, разрабатываются сценарии и макеты экранных форм. В физическом моделировании затрагиваются вопросы выбора языка, программных средств и хранилища, производится построение диаграмм компонентов и диаграмм размещения.
− Реализация программного обеспечения. В разделе приводится описание приложения, скриншоты клиентской части и фрагменты кода серверной части.
− Руководство пользователя. Раздел посвящен подробному описанию возможностей приложения.
− Тестирование программного обеспечения. В данном разделе приводится описание тестовых случаев для критического и углубленного тестирования. Также в разделе содержится описание конфигурации рабочих станций на которых проводилось тестирование.
− Заключение. Здесь анализируется проделанная в рамках проекта работа.
ОБЗОР СОСТОЯНИЯ ВОПРОСА
Системы совместного редактирования позволяют пользователям одновременно просматривать и изменять документы через сеть. В качестве документа могут выступать компьютерные программы и документация к ним, веб-страницы, онлайн-энциклопедии, изображения и даже 3D-сцены [13].
Системы управления базами данных нельзя отнести к системам совместного редактирования, поскольку те, как правило, не сообщают подключенным пользователям о том, что данные изменились. Для того, чтобы узнать об изменении данных, клиент должен явно запросить данные у СУБД.
Важной проблемой создания систем совместного редактирования является проблема контроля синхронизации и разрешения конфликтов: независимо от действий пользователей, все их действия должны быть отображены на всех клиентах через время, мало превышающее реакцию системы. Чем больше время реакции системы, тем острее встает проблема разрешения конфликтов. Не зная о действиях друг друга два пользователя могут, например, удалить один и тот же символ, и система должна распознавать такие случаи и решать подобные проблемы. Существует несколько вариантов решения:
— Блокировка данных. Если пользователь начинает редактировать блок текста (строку, слово или даже весь документ), он блокируется и другие пользователи не могут вносить в него изменения. Этот вариант прост в реализации, но неудобен в пользовании, особенно в случаях, когда несколько пользователей одновременно редактируют блок текста (строку).
— Транзакции. Широко используемый в СУБД механизм, который, однако, достаточно ресурсоемок. Кроме того, для транзакций, реализованных через блокировки, верны все перечисленные выше недостатки. Здесь проявляется также разница в философии. Если в СУБД стараются создать для каждого пользователя иллюзию, что он — единственный пользователь системы, то системы совместного редактирования должны максимально быстро отображать изменения, вносимые другими пользователями.
— Единственный пользователь. В каждый момент времени только один пользователь имеет доступ к редактированию документа, что не подходит для ситуаций с активным участием в редактировании нескольких человек.
— Обнаружение зависимостей. Порядок выполнения операций определяется их временем генерации, все конфликты разрешаются вручную.
— Обратимое исполнение. Все операции исполняются немедленно, но любая из них может быть отменена, для чего приложение может сохранять дополнительную информацию.
— Операциональное преобразование. Техника операционального преобразования впервые предложена в работе [14] и состоит в том, что все последующие операции преобразовываются так, чтобы учитывать эффект предыдущих. При этом не используются блокировки, и в любой момент любому пользователю доступно редактирование любого фрагмента текста. Сегодня операциональное преобразование широко используется в системах совместного редактирования. Дополнительную известность эта группа алгоритмов получила в связи с её использованием в проекте GoogleWave[15].
Техника операционального преобразования, несмотря на сравнительную сложность реализации, предоставляет пользователям наибольшее удобство при работе с текстом, и одновременно обеспечивает достаточно качественное поддержание синхронности текста у разных пользователей. Именно она использована при разработке приложения.
Рассмотрим подробнее эту группу алгоритмов.
Основная идея ОП может быть проиллюстрирована на примере сценария редактирования простого текста следующим образом: Дан текстовый документ со строкой "abc", реплицированный на двух удаленных компьютерах; а также две одновременных операции:
O1 = Insert[0, "x"] (вставить символ "x" в позиции "0")
O2 = Delete[2, "c"] (удалить символ "c" в позиции "2")
генерируемых двумя пользователями на удаленных компьютерах 1 и 2, соответственно. Предположим, что две операции выполняются в следующем порядке: сначала O1, и затем O2 (на сайте 1). После выполнения O1, текст в документе становится "xabc". Для выполнения O2 после O1, O2 должна быть уже преобразована относительно O1 и предстать в следующем виде: O2= Delete[3, "c"], где параметр позиции инкрементирован на единицу, в связи со вставкой символа "x" операцией O1. Выполнение O2 на "xabc" должно удалить правильный символ "c", и текст этого документа становится "xab". Если же выполнять операцию O2 без преобразования, тогда будет неправильно удален символ "b" вместо "c". Основной идеей ОП является преобразование (или изменение) параметров операций редактирования в согласии с эффектами выполнения в предыдущих одновременных операциях, так чтобы преобразованная операция могла сработать корректно и не нарушать согласованность в документе.
Одной из функциональностей ОП является поддержка средств согласованности в системах совместного редактирования. Сообществом исследователей был предложен целый ряд моделей согласованности, несколько из них являются общими для систем совместного редактирования, и несколько — специальными для алгоритмов ОП.
CC модель
В [14] для систем совместного редактирования потребовались два свойства согласованности:
Causality (Каузальность) или свойство старшинства по предшествованию: гарантирует, что порядок выполнения причинно-зависимых операций будет таким же, как их естественный причинно-следственный порядок, согласно процессу совместной работы. Каузальная связь между двумя операциями формально определяется соотношением Лампорта "happened-before". Если две операции каузально независимы, они являются параллельными. Две параллельных операции могут выполняться в различном порядке на двух разных копиях документов.
Сonvergence (Сходимость): гарантирует, что реплицированные копии общего документа будут идентичными на всех сайтах (то есть, все генерируемые операции будут выполнены на всех сайтах).
Так как параллельные операции могут быть выполнены в разном порядке и операции редактирования обычно не коммутативны, копии документа на различных сайтах могут отличаться (быть несовместимыми).
CCI модель
CCI модель была предложена в качестве общего фреймворка для управления согласованностью в системах совместного редактирования. Внутри CCI модели сгруппированы вместе три свойства согласованности:
Сausality Preservation (Сохранность Каузальности): то же самое, что и свойство старшинства по предшествованию в CC модели.
Сonvergence: то же самое, что свойство конвергентности в CC модели.
Intention Preservation (Сохранность Намерения): гарантирует, что эффект выполнения операции в любом состоянии документа, будет таким же, как и намеревалось при выполнении операции. Намерение операции O определяется как эффект выполнения, который может быть достигнут путем применения O на состоянии документа, из которого О была сгенерирована.
CCI модель расширяет CC модель новым критерием: Сохранность Намерения. Существенная разница между конвергенцией и сохранностью намерения состоит в том, что первое всегда может быть достигнуто путем сериализации протокола, однако последнее не может быть достигнуто за счёт сериализации какого-либо протокола, если операции всегда будут выполняться в их первоначальных формах. Обеспечение свойства сохранности несериализуемого намерения являлась главной технической задачей. Обнаружилось, что ОП очень хорошо подходит для обеспечения конвергенции и сохранности намерения в системах совместного редактирования.
CSM модель
Условие сохранности намерения не было формально определено в CCI модели для целей формальных доказательств. Модель согласованностиCSM состоит из следующих формальных условий:
Causality (Каузальность): определяет то же самое, что и в CC модели
Single-operation effects (Следствия выполнения одной операции): следствие от выполнения любой операции в любом состоянии выполнения достигает того же эффекта, что и в его исходном состоянии
Мulti-operation effects (Следствия выполнения нескольких операций): зависимость следствий любых двух операций поддерживаются и после того, как они оба будут выполнены в любых состояниях
CA модель
Приведенная выше CSM модель требует, чтобы в системе был определен общий порядок всех объектов. Следовательно, спецификация сводится к новым объектам, представляемым операциями вставки. Однако, спецификация общего порядка влечет за собой применение зависимых от приложения стратегий, таких как при разрыве связей для вставки (т.е., когда новые объекты вставляются двумя текущими операций в одну и ту же позицию). Таким образом, общий порядок становится зависимым от приложения. Более того, в функциях преобразования и процедуре управления алгоритма общий порядок должен сохраняться, что приводит к увеличению сложности времени/пространства алгоритма.
В качестве альтернативы, CA модель основывается на Admissibilty Theory [11] (Теории допустимости). CA модель включает в себя два аспекта:
Сausality (Каузальность): определяет то же самое, что и в CC модели
Аdmissibility (Допустимость): Вызов каждой операции является допустимым в своем состоянии исполнения, т.е. каждый вызов не должен нарушать каких-либо связанных следствий (построения объектов), которые были созданы более ранними вызовами.
Эти два условия подразумевают собой конвергенцию. Все кооперирущие между собой сайты сходятся в одном и том же состоянии, в котором имеется один и тот же набор объектов, что находятся в одном и том же порядке. Более того, порядок фактически определяет следствия операций, которые они генерируют. Поскольку два условия также вводят дополнительные ограничения на порядок объектов, они фактически имеют больший приоритет, чем конвергенция. CA модель и подходы к его дизайну/обоснованиям были разработаны в 2005 году в статье [11]. Это уже не требовало того, чтобы общий порядок объектов был определен в модели согласованности и поддерживался алгоритмом, что, соответственно, приводит к уменьшению сложности времени/пространства алгоритма. [15]
Именно описанный в статье [11] алгоритм использован при реализации приложения.
ЦЕЛЬ И ЗАДАЧИ ПРОЕКТА
Основная задача данного дипломного проекта — создание браузерного текстового редактора, позволяющего одновременное редактирование текста несколькими пользователями. Приложение должно работать в современных браузерах, поддерживать форматирование текста, обладать возможностью простого отката нежелательных изменений в документе.
Для достижения поставленной цели необходимо решить следующие задачи:
Обосновать выбор платформы и технологию разработки, используемую для достижения цели дипломного проекта;
На основе предлагаемой методики разработать алгоритмы и структуру системы;
На основе предлагаемой структуры разработать программное обеспечение на языке C#;
Провести сравнительный анализ выполненной работы;
МОДЕЛИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
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, AllFusionProcessModeler, графический редактор Visio и другие инструментальные средства. В данном случае предпочтение было отдано средствамEnterpriseArchitectи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, RubyonRails, Django, ASP.NETWebForms, ASP.NET MVC, Node.js.
Первая версия PHP/FI, название которой тогда расшифровывалось как PersonalHomepageTools / FormInterpreter (персональный инструментарий для разработки домашних страниц Интернета / интерпретатор форм), вышла в 1995 году. После выхода в 1997 году PHP/FI 2 к разработке (которая до этого велась в одиночку Расмусом Лердорфом) подключились Энди Гутманс и Зив Сураски. Плодом сотрудничества стала третья версия языка, который теперь носил название PHP (hypertextpreprocessor). Усовершенствования языка включали в себя новый APIдля расширений и позволили языку на порядок увеличить свою популярность.Ещё одним новшеством стали появившиеся в языке зачатки объектно-ориентированного программирования. Появилась возможность создавать классы и объекты на их основе, однако принципы ООП поддерживались не полностью. Так, например, нельзя было задавать области видимости переменных и методов.
Главным новшеством вышедшей в мае 2002 года PHP4 стала компиляция в промежуточный байт-код, позволившая заметно повысить производительность языка. При этом удалось сохранить практически полную обратную совместимость с предыдущей версией. Усовершенствование ООП стало основной задачей при разработке PHP 5 (последней на данный момент версии). Выйдя в 2004 году она принесла с собой новую объектную модель и усовершенствование ООП в дальнейших обновлениях [1].
Django — свободный фреймворк для веб-приложений на языке Python, использующий шаблон проектирования MVC. Первая версия Django была выпущена в конце 2005 года. Django ориентирован на создание сложных приложений для работы с базами данных. Он содержит собственный ORM, мощную систему кэширования, обработчик адресов, основанный на регулярных выражениях, систему шаблонов [2].
RubyonRails— фреймворк с открытым исходным кодом, выпущенный в 2004 году. Основан на языке Ruby. Выпуск RubyonRails в свое время показал преимущества грамотно реализованной архитектуры MVC. Соглашения вместо конфигурирования (большинству приложений не нужна какая-либо конфигурация, за исключением нестандартных), интеграция инструмента объектно-реляционного отображения в ядро фреймворка, поддержка модульного тестирования и простота разработки позволила RubyonRails быстро завоевать популярность. [3]RubyonRailsпредоставляет механизмы повторного использования, позволяющие минимизировать дублирование кода в приложениях. Для упрощения разработки он уже в стандартной поставке содержит многие инструменты, такие как инструмент для скаффолдинга, поддерживает СУБД MySQL, Firebird, PostgreSQL, DB2, Oracle и Microsoft SQL Server. Также RubyonRails имеет систему плагинов. На март 2013 года примерно 211 тысяч сайтов было запущено на RubyonRails[4].
Node.js — вышедшая в 2009 году программная платформа, позволяющая использовать JavaScriptв качестве основного языка для разработки не только клиентской, но и серверной части веб-приложения. Это удобно для разработчиков, которым вместо нескольких языков приходится иметь дело только с одним: применение некоторых нереляционных СУБД, таких как CouchDBи Mongo, позволяет использовать JavaScriptи в качестве языка запросов к базе данных вместо SQL. Node.js основан на высокопроизводительном движке V8, компилирующем JavaScript непосредственно в машинный код, что делает его практически применимым даже в сложных приложениях.
Важной особенностью Node.jsявляется обеспечение полной асинхронности операций. APINode.jsпросто не предоставляет средств для блокирования потока во время ожидания ввода-вывода и других операций. Это означает, что Node.jsпозволяет обрабатывать до нескольких десятков тысяч запросов на один ЦП, что существенно превышает возможности многих других платформ [3].
В 2002 году на смену ASP (ActiveServerPages) от Microsoftпришла технология ASP.NETWebForms. В Microsoftпопытались максимально приблизить разработку веб-приложений к обычным клиентским приложениям. От программиста был скрыт не только протокол HTTP, но и язык разметки HTML. В ASP.NETWebFormsбыла введена такая абстракция как ViewState (состояние представления). Состояние представления сохраняет между запросами состояние клиентских элементов управления, по мере необходимости визуализирует их в виде HTML-разметки и позволяет обрабатывать события элементов управления на сервере. ФактическиViewStateвоссоздает в веб-среде классический управляемый событиями интерфейс пользователя.
Концепция ASP.NETWebFormsбыла необычной и в какой-то степени революционной, однако практическое применение её выявило ряд недостатков:
- Ресурсоемкость.Состояние представления требует передавать блоки данных, хранящие состояние элементов управления, с каждым запросом пользователя. Размер этих блоков может достигать сотен килобайт даже в относительно несложных приложениях, что ухудшает отзывчивость сайта и увеличивает требования к полосе пропускания сервера.
- Ограниченный контроль над HTML- разметкой. ВASP.NETWebForms 3 и более ранних версиях сгенерированная разметка страницы зачастую не соответствовала стандартам, а генерируемые идентификаторы элементов управления затрудняли написание клиентскогоJavaScript.
- Сложность реализации нестандартного поведения.
- Низкая тестируемость. В момент разработки ASP.NETWebForms модульное тестирование не было распространено так широко как сегодня, и тесно связанная архитектура фреймворка плохо подходит для его организации[3].
В 2007 году была представлена платформа ASP.NET MVC, ушедшая от состояния представления. В ней была реализована архитектура модель-представление-контроллер, и в целом ASP.NET MVC напоминала RubyonRails, включая в себя также преимущества других платформ, такие как асинхронные контроллеры, реализующие поведение подобное Node.js.
Однако, в отличие от RubyonRails, содержащей полный стек технологий, ASP.NET MVC ориентирована исключительно на обработку HTTP-запросов с помощью контроллеров и действий. Она не имеет в своем составе таких инструментов как OPM или средств автоматизированного тестирования. Это объясняется тем, что к моменту созданияASP.NET MVC платформа .NETразвивалась уже достаточно долгое время, и все эти инструменты уже были созданы в разных вариациях. Потому ASP.NET MVC обладает модульной архитектурой и позволяет использовать один из множества готовых инструментов [3].Кроме того, в распоряжении программистов находится очень функциональные библиотеки .NETFrameworkи множество библиотек от сторонних разработчиков.
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.NETWebForms в одну платформу 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.NETWebForms и ASP.NET MVC.
При выборе из этих двух платформ нужно учесть, что значительная часть кода приложения должна исполняться на клиентской стороне, чтобы избежать постоянной передачи очень больших объёмов данных между клиентами и сервером и результирующей перегрузки каналов связи. При этом концепция ViewState из ASP.NETWebForms не даст нам никаких преимуществ, и принесет с собой в основном недостатки, такие как ресурсоемкость и низкую тестируемость. Потому в качестве платформы реализации серверной части выберем 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 и Longpolling, поддерживаемых XSockets, SignalR может использовать Server-Sent Events и Forever Frame. Альтернативные транспорты используются когда невозможно использовать WebSockets, например при устаревшем браузере у клиента[10].
В качестве основы для редактора текста будет использоваться CodeMirror, поддерживающий современные браузеры и имеющий развитое APIдля отслеживания изменений в тексте, применения изменений, работы с историей документа и управления стилями. К сожалению, CodeMirror не поддерживает форматирование документа стандартными тегами HTML, такими как <b></b>, но использование CSS-стилей позволяет обойти этот недостаток, а при необходимости экспорта документа в формате HTML стили можно заменить на стороне сервера, вернув клиенту чистый HTML.
3.2.5 Построение диаграмм компонентов
На рисунке 4.23 показанадиаграмма компонентов серверной части приложения
Рисунок 4.23 — Диаграмма компонентов серверной части приложения
3.2.6 Построение диаграмм размещения
На рисунке 4.24 показана диаграмма развёртывания приложения
Рисунок 5.7 — Диаграмма развертывания приложения
РЕАЛИЗАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
4.1 Приложение
Приложение реализовано по схеме клиент-сервер с асинхронным обменом данными между браузерами клиентов и сервером приложения по протоколу WebSockets. При построении приложения использована архитектура Model-View-Controller с «тяжелой», содержащей логику клиентской частью.
Структурно серверная часть приложения состоит из одного решения (solution)MicrosoftVisualStudioи двух входящих в него проектов:
— Pad.Domain. Отвечает за связь с БД, загрузку и сохранение изменений, реализует шаблон проектирования «репозиторий»;
— Pad.WebUI. Отвечает за взаимодействие с пользователем, пользовательский интерфейс и логику.
Клиентская часть отвечает за обеспечение синхронизации клиентов (серверная часть только хранит изменения и пересылает их другим клиентам) и взаимодействие с пользователями.
За синхронизацию отвечает реализация впервые описанного в [12] и [13] алгоритма основанного на допустимости операционального преобразования. По сравнению с оригинальным алгоритмом реализация доработана:
— Поддерживает атомарные многосимвольные операции, например вставку текста из буфера обмена (оригинальный алгоритм поддерживает всего две операции: вставку одного символа и удаление одного символа);
— Реализует структуру текста строка:символы строки (оригинальный алгоритм поддерживает исключительно одномерный массив, где все символы находятся в одной строке, что плохо сочетается с APICodeMirror);
— Поддерживает операции форматирования текста;
Поддерживает вход пользователей в середине сесии и началу работы не с пустого документа;
— Содержит другие, менее значимые изменения, направленные на интеграцию алгоритма с APICodeMirror.
При любом изменении в тексте документа (ввод символов, их удаление, вставка, перемещение блоков текста, изменение форматирования) срабатывает обработчик события “change” CodeMirror, к данным изменения, предоставляемымAPICodeMirror добавляется информация об авторе изменения, времени (не используется при определении порядка изменений) и статус-вектор: словарь (набор пар ключ-значение, где ключ – идентификатор пользователя, в т.ч. и свой, а значение – количество известных операций, сгенерированных этим пользователем). Этот набор данных в формате JSON отправляется на сервер, где преобразовывается в удобный для хранения в базе данных формат (при этом статус-вектор остается в формате JSON из соображений производительности), сохраняется и перенаправляется другим подключенным клиентам, у которых открыт тот же документ и которые имеют право на чтение (и, соответственно, получение новых изменений с сервера). Принятые изменения обрабатываются в соответствии с алгоритмом операционального преобразования, чтобы исключить рассинхронизацию клиентов, и применяются к документу. Для определения порядка применения изменений сравниваются их статус-векторы, сохраненные ранее.
Каждый вводимый пользователем символ подсвечивается т.н. авторским цветом, который пользователь может выбирать произвольно из полной палитры цветов. Авторские цвета служат для наглядной индикации авторства вносимых изменений и мест в документе, куда эти изменения были внесены. Авторские цвета с того или иного участка текста (или из всего документа) могут быть убраны нажатием кнопки «W»на панели инструментов. При отключении пользователя от сервера его пользовательский цвет изменяется на менее насыщенный.
Для каждого документа существует отдельный чат, предназначенный для координации авторов. Отправка сообщения происходит по кнопке «Enter».
Каждый клиент поддерживает актуальный список пользователей, у которых открыт текущий документ. Извещения о подключении или отключении пользователей рассылает сервер. Список пользователей можно увидеть в верхней части правой колонки страницы редактирования документа.
Приложение реализует гибкую систему ролей, позволяющую для каждого пользователя отдельно устанавливать права на те или иные действия, в том числе раздельно на просмотр и редактирование документа, просмотр и отправку сообщений в чат, создание документа и т.д. По умолчанию вновь зарегистрированный пользователь имеет все права кроме доступа к административным функциям, в дальнейшем можно принудительно понизить или понизить уровень доступных привилегий. При необходимости число настраиваемых прав может быть увеличено вплоть до, например, доступа к определенным функциям форматирования текста.
Приведем несколько фрагментов кода серверной части приложения, отвечающих за взаимодействие между клиентами, и содержащихся в контроллере XSocketsDocumentController. Обработкаизменениявдокументе:
[Authorize(Roles = "CanEditDocuments")]
public void ChangeSetFromClient(ChangeSetModel cs)
{
var json = new DataContractJsonSerializer(typeof(JsonChange.RootObject));
var change = (JsonChange.RootObject)json.ReadObject(new ding.UTF8.GetBytes(cs.Change)));
var dbChange = ChangeFromJsonChange(change);
_repository.AddChange(Document, dbChange);
this.SendTo(u => u != this && u.Document == Document, change, "ChangeSetFromServer");
}
Перед выполнением обработчика проверяется, может ли пользователь редактировать документ (принадлежит ли к соответствующей роли) с помощью атрибута [Authorize].Затем из формата JSONданные десериализуются в объект соответствующей структуры, преобразовываются в формат для сохранения в БД и записываются в базу. Исходное изменение без изменений отправляется другим клиентам, у которых открыт тот же документ.
Сообщениечата:
[Authorize(Roles = "CanWriteToChat")]
public void ChatMessage(ITextArgs msg)
{
var json = new DataContractJsonSerializer(typeof(JsonMessage));
var tempMessage = (JsonMessage)json.ReadObject(new (Encoding.UTF8.GetBytes(msg.data)));
tempMessage.Text = tempMessage.Text.Replace("
", "<br>");
var message = new ChatMessage
{
AuthorID = tempMessage.Author,
DocumentID = Document,
Text = tempMessage.Text,
Time = DateTime.Now
};
_repository.AddMessage(message);
tempMessage.Author = FindById(message.AuthorID).UserName;
this.SendTo(u => u.Document == Document&& u. CanReadChat == true, tempMessage, FromServer");
}
Здесь использован несколько иной подход. В целях устойчивости к некорректному (возможно, умышленному) поведению клиента в функцию передается только текст сообщения, остальные данные (авторство, время, принадлежность к документу) заполняются на стороне сервера. Кроме того,явно проверяется, может ли получающий сообщение пользователь читать чат (в ChangeSetFromClient() проверка была опущена, так как пользователи, которые не имеют прав на чтение документа, просто не смогут подключиться к серверу).
4.2 Пользовательский интерфейс
Пользовательский интерфейс приложения реализован средствами ASP.NetMVC 5 с помощью Razorразметки в .cstml файлах. При реализации интерфейса использован фреймворк TwitterBootstrap 3. На рисунках 4.1-4.6 показаны некоторые страницы приложения.
Рисунок 4.1 — Главная страница приложения
Рисунок 4.2 — Главная страница приложенияна дисплее с маленьким разрешением
Рисунок 4.3 — Главная страница приложенияна дисплее с маленьким разрешением, меню открыто
При необходимости на странице просмотра документа, показанной на рис. 4.4 может быть скрыт список пользователей или вся правая панель целиком, что оставит больше места для самого документа.
Рисунок 4.4 — Страница просмотра документа
Рисунок 4.5 — Страница просмотра списка пользователей
Рисунок 4.6 — Страница управления правами пользователя
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
Возможности приложения доступны только зарегистрированным и вошедшим в систему пользователям, потому для начала работы с приложением необходимо зарегистрироваться. Для начала регистрации нужно перейти по ссылке «Register» в верхней части страницы, ввести желаемое имя пользователя (отображаемое имя), адрес электронной почты (будет использоваться для входа), пароль и подтверждение пароля. Минимальная длина пароля равняется шести символам, других ограничений (например, присутствия спецсимволов) нет. После ввода данных нужно нажать на кнопку «Register». Страница регистрации показана на рисунке 5.1
Рисунок 5.1 — Страница регистрации
После регистрации необходимо войти в систему, для чего сначала перейти по ссылке «Login» в заголовке страницы. В появившуюся форму нужно ввести указанные при регистрации адрес электронной почты и пароль и нажать кнопку «Login». Страница входа показана на рисунке 5.2
Рисунок 5.2 — Страница входа
Для того, чтобы открыть существующий документ, нужно перейти по ссылке с названием документа внизу главной страницы, показанной на рисунке 5.3.
Рисунок 5.3 — Главная страница
Для создания нового документа нужно нажать на кнопку «Newdocument», после чего откроется форма ввода информации о документе, показанная на рисунке 5.4 и состоящая из двух полей. «Short name» - идентификатор документа, также будет отображаться в адресной строке браузера при открытом документе и определять постоянную ссылку на документ вида «…/short_name». Короткое имя не может принимать значения, такие как "Home", "CreateDocument", "User", "Admin" и некоторые другие. Поле «Name» - полное имя документа, которое будет отображаться в списке документов на главной странице. После заполнения всех полей формы следует нажать кнопку «Create».
Рисунок 5.4 — Создание документа
На рисунке 5.5 показана страница редактирования документа. Для редактирования просто изменяйте текст документа, все изменения будут автоматически сохраняться на сервере и передаваться другим подключенным клиентам. Для изменения форматирования текста предназначены кнопки на панели инструментов. В сворачиваемой правой боковой панели можно найти список пользователей и чат. Для отправки сообщения в чат введите текст сообщения в поле внизу панели и нажмите клавишу «Enter». Также в правой панели показан список подключенных к документу в данный момент пользователей с их авторскими цветами. Возможно изменить свой авторский цвет, нажав на направленный вниз треугольник возле своего имени пользователя, выбрав нужный цвет и нажав «choose», как показано на рисунке 5.6.
Рисунок 5.5 — Редактирование документа
Рисунок 5.6 — Изменение авторского цвета
ТЕСТИРОВАНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ОХРАНА ТРУДА
В связи с автоматизацией процессов производства и управления, развитием вычислительной техники и разработкой систем автоматизации проектных, исследовательских и технологических работ широкое распространение получили персональные компьютеры (ПК). Персональные компьютеры используются в информационных и вычислительных центрах, в диспетчерских пунктах управления технологическими процессами и т.д.
Основными видами работ на ПЭВМ с использованием видеодисплейных терминалов (ВДТ) являются: считывание информации с экрана с предварительным запросом; ввод информации; творческая работа в режиме диалога с ПЭВМ. Наибольшая нагрузка на орган зрения имеет место при вводе информации в ПЭВМ. Наибольшее общее утомление вызывает работа в режиме диалога. Наибольшее напряжение вызывает выполнение работы при дефиците времени для принятия решения (при управлении непрерывными технологическими процессами). При длительной работе за экраном ВДТ возникает напряжение зрительного аппарата (зрительное утомление, головные боли, раздражительность, болезненные ощущения в глазах и т. д.), напряжение мышц спины, шеи, рук, ног. Неблагоприятное влияние на условия труда работающих с ВДТ оказывает нерациональное естественное и искусственное освещение помещений и рабочих мест, яркие и темные пятна на рабочих поверхностях, засветка экрана посторонним светом, наличие ярких и блестящих предметов.
7.1 Производственная санитария, техника безопасности и пожарная профилактика
Работающие с ПЭВМ могут подвергаться воздействию различных опасных и вредных производственных факторов, основными из которых являются: физические: повышенные уровни: электромагнитного, рентгеновского, ультрафиолетового и инфракрасного излучения; статического электричества; запыленности воздуха рабочей зоны; повышенное или пониженное содержание аэроионов в воздухе рабочей зоны; повышенный или пониженный уровень освещенности рабочей зоны и др.; химические: содержание в воздухе рабочей зоны оксида углерода, озона, аммиака, фенола, формальдегида и полихлорированных фенилов; психофизиологические: напряжение зрения, памяти, внимания; длительное статическое напряжение; большой объем информации, обрабатываемой в единицу времени; монотонность труда; нерациональная организация рабочего места; эмоциональные перегрузки.
Работа с ПЭВМ проводится в соответствии с Санитарными нормами и правилами «Требования при работе с видеодисплейными терминалами и электронно-вычислительными машинами» и Гигиеническим нормативом «Предельно-допустимые уровни нормируемых параметров при работе с видеодисплейными терминалами и электронно-вычислительными машинами», утвержденными постановлением Министерства здравоохранения от 28.06.2013 г. № 59 и Типовой инструкцией по охране труда при работе с персональными ЭВМ, утвержденной постановлением Министерства труда и социальной защиты от 24.12.2013 № 130.
Площадь одного рабочего места для пользователей ВДТ, ЭВМ и ПЭВМ на базе плоских дискретных экранов (жидкокристаллические, плазменные и другое) составляет не менее 4,5 м2.
7.1.1 Метеоусловия
В производственных помещениях, в которых работа с использованием ВДТ, ЭВМ или ПЭВМ является основной (диспетчерские, операторские, расчетные, кабины и посты управления, залы вычислительной техники и др.) или связана с нервно-эмоциональным напряжением, обеспечиваются оптимальные параметры микроклимата для категории работ 1а и 1б, предусмотренные Гигиеническим нормативом (табл. 7.1).
Таблица 7.1 — Оптимальные параметры микроклимата для помещений с ВДТ, ЭВМ и ПЭВМ
Период года Категория работ Температура воздуха, оС, не более Относительная влажность воздуха, % Скорость движения воздуха, м/с
Холодный легкая-1а 22-24 40-60 0,1
легкая-1б 21-23 40-60 0,1
Теплый легкая-la 23-25 40-60 0,1
легкая-1б 22-24 40-60 0,2
Оптимальные микроклиматические условия - это сочетание показателей микроклимата (температура воздуха, относительная влажность воздуха, скорость движения воздуха, интенсивность инфракрасных излучений), которое обеспечивает человеку ощущение теплового комфорта в течение рабочей смены без нарушения механизмов терморегуляции и не вызывает отклонений в здоровье. При этом создаются предпосылки для высокого уровня работоспособности.
Работа с компьютером относится к категории 1а (к данной категории работ относят работы, производимые сидя и сопровождающиеся незначительным физическим напряжением, при которых расход энергии составляет до 120 ккал/ч, т.е. до 139 Вт).
Согласно ГОСТ 12.1.005-88 и Санитарных нормам и правилам интенсивность теплового излучения работающих от нагретых поверхностей технологического оборудования, осветительных приборов, инсоляции на постоянных местах не превышает значений, указанных в табл. 7.2.
Таблица 7.2 — Предельно допустимые уровни интенсивности излучения в инфракрасном и видимом диапазоне излучения на расстоянии 0,5 мсо стороны экрана ВДТ, ЭВМ и ПЭВМ
Диапазоны длин волн 400-760 нм 760-1050 нм свыше 1050 нм
Предельно допустимые уровни 0,1 Вт/м2 0,05 Вт/м2 4,0 Вт/м2
Для создания нормальных метеорологических условий наиболее целесообразно уменьшить тепловыделения от самого источника — монитора, что предусматривается при разработке его конструкции.
В производственных помещениях для обеспечения необходимых показателей микроклимата предусмотрены системы отопления, вентиляции и кондиционирования воздуха.
7.1.2 Вентиляция и отопление
Воздух рабочей зоны производственного помещения соответствует санитарно-гигиеническим требованиям по параметрам микроклимата, содержанию вредных веществ (газа, пара, аэрозоли) и частиц пыли, приведенным в ГОСТе 12.1.005-88 СББТ и Санитарных нормах, правилах и гигиенических нормативах «Перечень регламентированных в воздухе рабочей зоны вредных веществ».
В помещениях, оборудованных ВДТ, ЭВМ или ПЭВМ, проводится ежедневная влажная уборка и систематическое проветривание после каждого часа работы с ВДТ, ЭВМ или ПЭВМ.
Уровни положительных и отрицательных аэроионов, а также коэффициент униполярности в воздухе всех помещений, где расположены ВДТ, ЭВМ или ПЭВМ, соответствуютзначениям, указанным в табл. 7.3.
Таблица 7.3 — Уровни ионизации и коэффициент униполярности воздуха помещений при работе с ВДТ, ЭВМ и ПЭВМ
Уровни Число ионов в 1 см3 воздуха Коэффициент униполярности (У)
n+ n-
Минимально допустимые 400 600 0,4 ≤ У <1,0
Оптимальные 1500-3000 3000-5000
Максимально допустимые 50000 50000
Одним из мероприятий по оздоровлению воздушной среды является устройство вентиляции и отопления. Задачей вентиляции является обеспечение чистоты воздуха и заданных метеорологических условий на рабочих местах. Чистота воздушной среды достигается удалением загрязненного или нагретого воздуха из помещения и подачей в него свежего воздуха. Работа видеотерминалов сопровождается выделением тепла. Для поддержания нормального микроклимата необходим достаточный объем вентиляции, для чего в вычислительном центре предусматривается кондиционирование воздуха, осуществляющее поддержание постоянных параметров микроклимата в помещении независимо от наружных условий.
Параметры микроклимата поддерживаются в указанных пределах в холодное время за счет системы водяного отопления с нагревом воды до 100°С, в теплый - за счет кондиционирования, с параметрами отвечающими требованиям СНБ 4.02.01-03.
7.1.3 Освещение
Важное место в комплексе мероприятий по охране груда и оздоровлению условий труда работающих с ЭВМ занимает создание оптимальной световой среды, т.е. рациональная организация освещения помещения и рабочих мест.
Помещения для эксплуатации ВДТ, ЭВМ и ПЭВМ имеют естественное и искусственное освещение. Естественное освещение на рабочих местах с ВДТ, ЭВМ и ПЭВМ осуществляется через световые проемы, ориентированные преимущественно на север, северо-восток, восток, запад или северо-запад и обеспечивает коэффициент естественной освещенности не ниже 1,5 %. Оконные проемы оборудованы регулируемыми устройствами типа жалюзи, занавесей, внешних козырьков и другое.
Для внутренней отделки интерьера помещений, где расположены ВДТ, ЭВМ и ПЭВМ, используются диффузно отражающие материалы с коэффициентом отражения для потолка – 0,7-0,8; для стен – 0,5-0,6; для пола – 0,3-0,5.
Искусственное освещение в помещениях для эксплуатации ВДТ, ЭВМ и ПЭВМ осуществляется системой общего равномерного освещения. В производственных, административных и общественных помещениях в случаях преимущественной работы с документами применяют системы комбинированного освещения.
Освещенность на поверхности стола в зоне размещения рабочего документа составляет 300-500 люкс. Освещение не создает бликов на поверхности экрана. Освещенность поверхности экрана не превышает 300 люкс.
Неравномерность распределения яркости в поле зрения пользователя ВДТ, ЭВМ и ПЭВМ, при этом соотношение яркости между рабочими поверхностями не превышает 3:1 – 5:1, а между рабочими поверхностями и поверхностями стен и оборудования – 10:1.
В качестве источников света при искусственном освещении применены преимущественно люминесцентные лампы типа ЛБ и компактные люминесцентные лампы.
Коэффициент запаса для осветительных установок общего освещения принимается равным 1,4. Коэффициент пульсации не превышает 5 %.
7.1.4 Шум
Шум, неблагоприятно воздействуя на организм человека, вызывает психические и физиологические нарушения, снижающие работоспособность, приводит к увеличению числа ошибок при работе.
Основными источниками шума в помещениях, оборудованных ЭВМ, являются принтеры, множительная техника и оборудование для кондиционирования воздуха, в самих ЭВМ — вентиляторы систем охлаждения и трансформаторы.
Нормированные уровни шума согласно Санитарных норм и правил «Требования при работе с видеодисплейными терминалами и электронно-вычислительными машинами» и Гигиенических нормативов «Предельно-допустимые уровни нормируемых параметров при работе с видеодисплейными терминалами и электронно-вычислительными машинами» приведены в таблице 6.4 и обеспечиваются путем использования малошумного оборудования, применением звукопоглощающих материалов для облицовки помещений, а также различных звукопоглощающих устройств (перегородки, кожухи и т. д.).
Таблица 7.4 – Предельно-допустимые уровни звука, эквивалентные уровни звука и уровни звукового давления в октавных полосах частот при работе с ВДТ, ЭВМ и ПЭВМ и периферийными устройствами
Категория нормы
шума Уровни звукового давления, дБ, в октавных полосах
со среднегеометрическими частотами, Гц Уровни звука и
эквивалентные уровни звука, дБА
31.5 63 125 250 500 1000 2000 4000 8000
I 86 71 61 54 49 45 42 40 38 50
II 93 79 70 63 58 55 52 50 49 60
III 96 83 74 68 63 60 57 55 54 65
IV 103 91 83 77 73 70 68 66 64 75
Шум не превышает допустимых пределов, так как в вычислительной технике нет вращающихся узлов и механизмов (за исключением вентилятора), а наиболее шумное оборудование (АЦПУ) находится в специально отведенных помещениях.
7.1.5 Электробезопасность
Помещение вычислительного центра по степени опасности поражения электрическим током относится к помещениям без повышенной опасности.
Основные меры защиты от поражения током:
- изоляция и недоступность токоведущих частей;
- защитное заземление (R3 = 4 Ом ГОСТ 12.1.030 - 81).
Первая помощь при поражениях электрическим током состоит из двух этапов: освобождение пострадавшего от действия тока и оказание ему доврачебной медицинской помощи. После освобождения пострадавшего от действия электрического тока необходимо оценить его состояние. Во всех случаях поражения электрическим током необходимо вызвать врача независимо от состояния пострадавшего.
7.1.6 Излучение
При работе с дисплеем могут возникнуть следующие опасные факторы: электромагнитные поля, электростатические поля, ультрафиолетовое и инфракрасное излучение.
Уровни физических факторов, создаваемые ВДТ, ЭВМ, ПЭВМ и периферийными устройствами, не превышают предельно-допустимые уровни: электромагнитных и электростатических полей (табл. 7.5, 7.6), ультрафиолетового (табл. 7.7), установленных Гигиеническим нормативом «Предельно-допустимые уровни нормируемых параметров при работе с видеодисплейными терминалами и электронно-вычислительными машинами».
Таблица 7.5 — Предельно допустимые уровни электромагнитных полей от экранов ВДТ, ЭВМ и ПЭВМ
Наименование параметра Предельно-допустимые уровни
Напряженность электрического поля в диапазоне частот:
5 Гц-2 кГц не более 25,0 В/м
2-400 кГц не более 2,5 В/м
Плотность магнитного потока магнитного поля в диапазоне частот:
5 Гц-2 кГц не более 250 нТл
2-400 кГц не более 25 нТл
Напряженность электростатического поля не более 15 кВ/м
Таблица 7.6 — Предельно допустимые уровни электромагнитных полей при работе с ВДТ, ЭВМ, ПЭВМ от клавиатуры, системного блока, манипулятора «мышь», беспроводных системам передачи информации и иных периферийных устройств
Диапазоны частот 0,3-300
кГц 0,3-3
МГц 3-30
МГц 30-300
МГц 0,3-300
ГГц
Предельно допустимые уровни 25 В/м 15 В/м 10 В/м 3 В/м 10 мкВт/см2
Таблица 7.7 — Предельно допустимые уровни интенсивности излучения в ультрафиолетовом диапазоне на расстоянии 0,5 мсо стороны экрана ВДТ, ЭВМ и ПЭВМ
Диапазоны длин волн 200-280 нм 280-315 нм 315-400 нм
Предельно допустимые уровни не допускается 0,0001 Вт/м2 0,1 Вт/м2
Наиболее эффективным и часто применяемым методом защиты от электромагнитных излучений является установка экранов. Экранируют либо источник излучения, либо рабочее место. Часто экран устанавливают непосредственно на монитор.
При работе монитора на экране кинескопа накапливается электростатический заряд, создающий электростатическое поле. При этом люди, работающие с монитором, приобретают электростатический потенциал. Когда электростатическое поле субъективно ощущается, потенциал пользователя служит решающим фактором при возникновении неприятных субъективных ощущений. Заметный вклад в общее электростатическое поле вносят электризующиеся от трения поверхности клавиатуры и мыши.
7.1.7 Пожарная безопасность
По взрывопожарной и пожарной опасности помещения и здания относятся по ТКП 474-2013 к категории Д в зависимости от выполняемых в них технологических процессов, свойств применяемых веществ и материалов, а также условиями их обработки. Здания для ВЦ и части зданий другого назначения, в которых предусмотрено размещение ЭВМ, относятся к 2 степени огнестойкости согласно ТКП 45-2.02-142-2011.
Для предотвращения распространения огня во время пожара с одной части здания на другую устроены противопожарные преграды в виде стен, перегородок, дверей, окон. Особое требование предъявляется к устройству и размещению кабельных коммуникаций.
Примерные нормы первичных средств пожаротушения приведены в таблице 6.9.
Для ликвидации пожаров в начальной стадии применяются первичные средства пожаротушения: внутренние пожарные водопроводы, огнетушители типа ОВП-10, ОУ-2, асбестовые одеяла и др.
В здании ВЦ пожарные краны установлены в коридорах, на площадках лестничных клеток, у входа, т.е. в доступных и защитных местах. На каждые 100 квадратных метра пола производственных помещений приходится 1-2 огнетушителя.
Эвакуация сотрудников вычислительного центра осуществляется по путям эвакуации через эвакуационные выходы. Количество и общая ширина эвакуационных выходов определяются в зависимости от максимального возможного числа эвакуирующихся через них людей и предельно допустимого расстояния от наиболее удаленного места возможного пребывания людей до ближайшего эвакуационного выхода согласно ТКП 45-2.02-22-2006, ТКП 45-2.02-279-2013.
Таблица 7.9 — Примерные нормы первичных средств пожаротушения для вычислительного центра
Помещение Площадь, м2 Углекислотные огнетушители ручные Порошковые огнетушители
Вычислительный центр 100 1 1
Расчетное время эвакуации установлено по реальному расчету времени движения одного или нескольких потоков людей через эвакуационные выходы из наиболее удаленных мест размещения людей. Необходимое время эвакуации установленона основе данных о критической продолжительности пожара с учетом степени огнестойкости здания, категории производства по взрывной и пожарной опасности. Расчетное время меньше необходимого, что обеспечивает успешную эвакуацию.
7.2. Расчет величины тока, проходящего через организм человека
Определим величину тока, проходящего через человека, при случайном ка¬сании оголенного фазного провода. Человек попадает под фазное напряжение и сила тока, про¬ходящего через него, будет равна Iч = Uф / Rч = 220 / 1000 = 0,22 А.
Ток такой величины безопасен, если время его проте¬кания через человека не более 0,2 с (такую быстроту от¬ключения может обеспечить автоматическая защита). При длительном воздействии такой ток смертелен. Самостоя¬тельное освобождение от воздействия такого тока исключено.
При замыкании двух зажимов человек попадает под линейное напряжение и сила тока, проходящего через человека, составит Iч = Uл / Rч = 380 / 1000 = 0,38 А.
Ток такой величины представляет смертельную опасность.
При прикосновении к проводу с исправной изоляцией:
Iч = Uф / (Rч + Rиз ) = 220 / (1000 + 500000) = 0,44×10–3 А.
Переменный ток менее 0,5×10–3 А не ощущается.
При прикосновении к проводу с ухудшенной изоляцией
Iч = Uф / (Rч + Rиз ) = 220 / (1000 + 10000) = 21,6×10–3 А.
Переменный ток такой величины представляет безусловную опасность, тем более, что с течением времени сопротивление человека уменьшается и опасность смертельного поражения возрастает.
При прикосновении к проводам разных фаз с исправной изоляцией человек попадает под линейное напряжение, но последовательно с ним оказывается вклю¬ченным сопротивлением фазы. Сила тока, проходящего через человека, в этом случае будет Iч = Uл / (Rч + 2Rиз ) = 380 / (1000 + 100000) = 0,38×10–3 А.
Такой ток безопасен.
При прикосновении к двум проводам разных фаз с ухудшенной изоляцией сила тока, проходящего через человека, составит Iч=380/(100+2×10000)=18,0×10–3 А.
Величина тока значительна, руки трудно, но еще возможно самостоятельно оторвать от электродов.
Предположим, что произошло короткое замыкание фазы 1. В этом случае напряжение исправных фаз относительно земли U2 = U3 = ,
где U0 — напряжение нулевой точки при коротком замыкании.
Если принять, что замыкание фазы произошло через сопротивление 1 Ом, то сила тока замыкания на землю будет Iз = = 44 А.
Напряжение нулевой точки равно U0 = IзR0 = 44 × 4 = 176 В.
Напряжение поврежденной фазы относительно земли
Uф1 = IзRз = 44 × 1 = 44 В.
Напряжение исправных фаз U2 = U3 = = 330 В.
Таким образом, при прикосновении к исправной фазе при коротком замыка¬нии соседней, человек попадает под напряжение выше фазного. При хорошем качестве изоляции исправных фаз сила тока, проходящего через человека, в этом случае составит Iч = 380 / (1000 + 500000) = 0,00066 А; при ухудшенном качестве изоляции исправных фаз Iч = 380 / (100 + 10000) = 0,03 А.
Из сопоставления всех рассмотренных вариантов можно сделать вывод, что наиболее опасным для человека является двухфазное прикосновение к токоведущим частям электроустановки; опасность однофазного прикосновения несколько ниже за счет уменьшения напряжения. Прикосновение к проводам с исправной изоляцией безопасно, а к проводам с ухудшенной изоляцией может быть опасно особенно однофазное.
ОПРЕДЕЛЕНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ РАЗРАБОТКИ ПО
Для расчета экономической эффективности разработки программного обеспечения сопоставим затраты на решение задачи при ручном методе ее решения с затратами, связанными с ее автоматизацией.
Определение трудоемкости разработки ПП
Единовременные капитальные затраты представляют собой цену программного продукта (ПП). Различают оптовую и отпускную цену программы. Все расчеты между покупателем и продавцом продукции, к числу которой относят и программные продукты, производятся на основе отпускных цен. В настоящее время в соответствии с законодательством РБ в отпускную цену наряду с оптовой ценой включается налог на добавленную стоимость.
Определяющим фактором оптовой цены разработки является трудоемкость создания ПП.
Трудоемкость разработки ПП может быть определена на основе Типовых норм времени для программирования задач на ЭВМ [11]. Она включает время на постановку задачи и время на программирование задачи и определяется по формуле
Т_рэ= (∑_(i=1)^(n_э)▒〖Т_посi+ ∑_(i=1)^(n_э)▒Т_пргi 〗)*8, (1)
гдеn_э — количество этапов разработки программы;
Т_посi — трудоемкость постановки задачи на i-м этапе разработки программы, дней;
Т_пргi — трудоемкость программирования задачи на i-м этапе разработки программы, дней.
Рассчитаем стоимость разработки проекта.
Техническое задание на разработку проекта предусматривает проведение стадии “Технорабочий проект” взамен стадий “Технический проект” и “Рабочий проект”.
Планируемый срок разработки – 0,5 года.
Исходные данные:
Количество разновидностей форм входной информации – 1, в том числе переменной – 1.
Количество разновидностей форм выходной информации – 1, в том числе информации, наносимой на машинные носители – 1.
Степень новизны комплекса задач – В.
Сложность алгоритма – 2.
Объем входной информации – 50 тыс. документострок.
Сложность организации контроля входной и выходной информации — 22 (документы однообразной формы и содержания, вывод массивов данных на машинные носители) (п. 1.8 Общей части, табл. 1.4).
Проект разрабатывается с учетом обработки информации в режиме работы в реальном времени.
Языки программирования – C# и JavaScript.
Использование типовых проектных решений, типовых проектов, типовых программ и стандартных модулей – 50% (руководителем разработки установлен коэффициент 0,6).
Комплекс задач, принимаемый при расчетах — совершенствование документооборота и контроль исполнения документов.
Таблица 8.1 – Расчет трудоемкости разработки программного продукта
Стадия разработки проекта Затраты времени,
чел.-дней Поправочный коэффициент Затраты времени с учетом поправочного коэффициента
Значение Расчет
Разработка технического задания
Затраты времени разработчика постановки задачи
Затраты времени разработчика программного обеспечения 24
0,65
0,35
Примечание к табл. 4.1 [11]
Примечание к табл. 4.1 [11]
15,6
8,4
Разработка эскизного проекта
Затраты времени разработчика постановки задачи
Затраты времени разработчика программного обеспечения 67
0,7
0,3
Примечание к табл. 4.2 [11]
Примечание к табл. 4.2 [11]
46,9
20,1
Разработка технорабочего проекта
Разработка технического проекта
затраты времени разработчика постановки задачи
затраты времени разработчика программного обеспечения
Разработка рабочего проекта
затраты времени разработчика постановки задачи
затраты времени разработчика программного обеспечения
23 (табл.4.19 [11])
6
(табл.4.19 [11])
6 (табл.4.45 [11])
38 (табл.4.46 [11])
K1=1
K2=1,00
K3=1,26
K4=1
Kобщ=1,26
1,26
K1=1,10
K2=1,16
K3=1,44
K4=0,6
Kобщ=1,1
1,1
п. 1.7 (табл. 1.1) [11]
п. 1.7 (табл. 1.3) [11]
п. 1.9 (табл. 1.5) [11]
п. 1.14[11]
Как затраты времени разработчика постановки задачи
п. 1.7 (табл. 1.2) [11]
п. 1.8 (табл. 1.4) [11]
п. 1.9 (табл. 1.5) [11]
п. 1.12 (табл. 1.6)[11]
Как затраты времени разработчика постановки задачи
28,98
7,56
6,6
41,8
Продолжение таблицы 8.1
Стадия разработки проекта Затраты времени,
чел.-дней Поправочный коэффициент Затраты времени с учетом поправочного коэффициента
Значение Расчет
Внедрение
Затраты времени разработчика постановки задачи
Затраты времени разработчика программного обеспечения
8 (табл.4.71 [11])
8 (табл.4.72 [11]) K1=1,0
K2=1,00
K3=1,21
K4=0,6
Kобщ=0,73
0,73 п. 1.7 (табл. 1.3) [11]
п. 1.8 (табл. 1.4) [11]
п. 1.9 (табл. 1.5) [11]
п. 1.12 (табл. 1.6)[11]
Как затраты времени разработчика постановки задачи
5,8
5,8
Всего на комплекс задач 187,54
Приняв длительность рабочего дня в 8 часов, получим затраты времени в 1500 человеко-часов.
8.2 Определение себестоимости создания программного продукта
Зная трудоемкость разработки программного продукта, найдём себестоимость его создания. Для этого необходимо определить затраты на заработную плату разработчика по формуле
З_рз= Т_рз* Т_чр*(1+q)*(1+a)*(1+b), (2)
где Т_рз —трудоемкость разработки программного продукта, чел-ч.;
Т_чр — среднечасовая ставка работника, осуществлявшего разработку программного продукта, руб;
q — коэффициент, учитывающий процент премий в организации-разработчике( при отсутствии данных может быть принят 0.3...0.4);
а — коэффициент, учитывающий дополнительную заработную плату ( при отсутствии данных может быть принят 0.15 );
b — коэффициент, учитывающий начисления на заработную плату. Численное значение коэффициента b =0.36.
Среднечасовая ставка работника определяется исходя из Единой тарифной системы оплаты труда в Республике Беларусь по следующей формуле:
t_чр= (О1*k_т)/167,4, (3)
где О1 — среднемесячная заработная плата работника 1 разряда (принята равной 1200000 руб);
k_т — тарифный коэффициент работника соответствующего разряда (примем тарифный коэффициент специалиста с высшим образованием без категории равным 2,97);
167,4 — нормативное количество рабочих часов в месяце.
Подставив в формулу (3) численные значения, получим среднечасовую ставку разработчика:
t_чр= (1200000 *2,97)/167,4=21 290 руб. (4)
Подставив в формулу (2) численные значения, получим
З_рз= 1500* 21 290*(1+0,3)*(1+0,15)*(1+0,36)=
=1500*21 290*1,3*1,15*1,36=64 930 242 руб. (5)
В себестоимость разработки ПП включаются также затраты на отладку ПП в процессе его создания. Для определения их величины необходимо рассчитать стоимость машиночаса работы ЭВМ, на которой осуществлялась отладка. Затраты на отладку программы определяются по формуле
З_от= Т_отл* S_мч, (6)
где Т_отл — трудоемкость отладки программы, час (определяется согласно таблице 4.88 [11], принята равной 128 часам);
S_мч — стоимость машиночаса работы ЭВМ, руб/час.
Стоимость машиночаса работы ЭВМ определяется по формуле
S_мч= С_э+(А_эвм+Р_эвм+ А_пл+ Р_пл+Н_н)/Ф_эвм , (7)
где С_э — расходы на электроэнергию за час работы ЭВМ, руб;
А_эвм— годовая величина амортизационных отчислений на реновацию ЭВМ;
Р_эвм— годовые затраты на ремонт и техническое обслуживание ЭВМ, руб;
А_пл— годовая величина амортизационных отчислений на реновацию производственных площадей, занимаемых ЭВМ, руб;
Р_пл— годовые затраты на ремонт и содержание производственных площадей, руб;
Н_н— годовая величина налога на недвижимость, руб;
Ф_эвм— годовой фонд времени работы ЭВМ, час.
Расходы на электроэнергию за час работы ЭВМ определяются по формуле
С_э= Ч_эл* Ц_э, (8)
где Ч_эл— среднечасовое потребление электроэнергии ЭВМ, кВт (при мощности блока питания в 60 ватт и неравномерной загрузке примем равным 50 ваттам или 0,05 кВт);
Ц_э— стоимость 1 квт-часа электроэнергии, руб (745,9 руб.).
Подставив исходные данные, получим
С_э= 0,05* 745,9=37,3 руб. (9)
Годовая величина амортизационных отчислений на реновацию ЭВМопределяется по формуле
А_эвм= (ц_эвм*k_у* k_м*Н_аэвм)/100, (10)
где ц_эвм — цена ЭВМ на момент ее выпуска, руб (примем равной 8 000 000 руб.);
k_у — коэффициент удорожания ЭВМ (зависит от года выпуска) (В том случае, когда в качестве цены используется цена текущего года, коэффициент удорожания k_у=1).
k_м— коэффициент,учитывающий затраты на монтаж и транспортировку ЭВМ (k_м= 1.05);
Н_аэвм— норма амортизационных отчислений на ЭВМ, % (Н_аэвм=10);
Подставив значения, получим
А_эвм= (ц_эвм*k_у* k_м*Н_аэвм)/100= (8000000*1*1,05*10)/100=840 000 руб. (11)
Годовые затраты на ремонт и техническое обслуживание ЭВМ укрупненно могут быть определены по формуле
Р_эвм= Ц_бэвм* k_ро, (12)
где k_ро —коэффициент, учитывающий затраты на ремонт и техническое обслуживание ЭВМ, в том числе затраты на запчасти, зарплату ремонтного персонала и др (k_ро= 0.1).
Подставив значения, получим
Р_эвм= 8400000* 0,1=840000 (13)
Годовая величина амортизационных отчислений на реновацию производственныхплощадей, занятых ЭВМ определяется по формуле:
А_пл=(Ц_бпл*Н_апл)/100= (S_эвм*k_д*Ц_пл*Н_апл)/100, (14)
где Ц_бпл — балансовая стоимость площадей, руб;
S_эвм — площадь, занимаемая ЭВМ, кв.м.;
k_д—коэффициент, учитывающий дополнительную площадь (k_д = 3);
Ц_пл— цена 1 квадратного метра производственной площади, руб (принята равной 5000000 руб.).
Н_апл — норма амортизационных отчислений на производственные площади, % (Н_апл=1,2 );
Подставив значения, получим
А_пл= (1*3*5000000*1,2)/100=180000 руб. (15)
Годовые затраты на ремонт и содержание производственных площадей укрупненно могут быть определены по формуле
Р_пл=Ц_бпл*k_рэ, (16)
где k_рэ—коэффициент, учитывающий затраты на ремонт и эксплуатацию производственных площадей (kрэ = 0.05).
Подставив значения, получим
Р_пл=15000000*0,05=750000 руб. (17)
Величина налога на недвижимость определяется по формуле
Н_н=(Ц_бэвм+ Ц_бпл )*С_нн, (18)
где С_нн — ставка налога на недвижимость (1 процент в год).
Подставив значения, получим
Н_н=(8400000+ 15000000)*0,01=234000 руб. (19)
Годовой фонд времени работы ЭВМ определяется исходя из режима ееработы и может быть рассчитан по формуле
Ф_эвм=t_сс*Т_сг, (20)
где t_сс — среднесуточная фактическая загрузка ЭВМ, час;
Т_сг — среднее количество дней работы ЭВМ в год.
Подставив значения, получим
Ф_эвм=7*300=2100 час. (21)
Вернёмся к формуле (7) и определим стоимость машиночаса работы ЭВМ.
S_мч= С_э+(А_эвм+Р_эвм+ А_пл+ Р_пл+Н_н)/Ф_эвм ==37,3+ (840000 +840000+ 180000+ 750000+234000 )/(2100 )=
=37,3+ 2844000/2100= 37,3+ 1354,3=1391,6 руб/час (22)
Зная стоимость машиночаса работы ЭВМ, определим стоимость отладки программного продукта:
З_от= Т_отл* S_мч=128*1391,6=178123 руб. (23)
Себестоимость разработки ПП определяется по формуле
С_пр= З_рз* F+З_от, (24)
где F— коэффициент накладных расходов проектной организации без учета эксплуатации ЭВМ ( при отсутствии данных может быть принят 1.15...1.2 ).
Подставив значения, получим
С_пр= 64 930 242 * 1,15+178123=74 847 901 руб. (25)
Оптовая цена складывается из себестоимости создания программного продукта и плановой прибыли на программу.
Оптовая цена ПП определяется по формуле
Ц_о= С_пр+Пр, (26)
где Пр — плановая прибыль на программу, руб.
Плановая прибыль на программу определяется по формуле
Пр= С_пр*Н_п, (27)
где Н_п — норма прибыли проектной организации (при отсутствииданных может быть принята Нп = 0.25...0.3)
Подставив значения, получим
Пр= 74 847 901 *0,25=18 711 975 руб. (28)
Найдём оптовую цену программного продукта:
Ц_о= С_пр+Пр=74 847 901 +18 711 975= 93 559 876 руб. (29)
Отпускная цена программы определяется по формуле
Ц_пр= Ц_о+(З_рз+Пр)*Н_доб, (30)
где Н_доб— ставка налога на добавленную стоимость (20% ).
Подставив значения, получим
Ц_пр= 93 559 876 +(64 930 242+18 711 975)*0,2= 110 288 320 руб. (31)
Определение ожидаемого прироста прибыли в результате внедрения ПП
Внедрение ПП может обеспечить пользователю ожидаемый прирост прибыли за счет сокращения трудоемкости решения задачи, являющейся предметом автоматизации и как результат, снижения текущих затрат, связанных с решением данной задачи.
Так как внедряемый ПП заменяет ручной труд, то производится сопоставление текущих затрат, связанных с решением задачи в ручном режиме и автоматизированном.
Годовые эксплуатационные расходы при ручной обработке информации (ручном решении задачи) определяются по формуле:
З_р= Т_р*k*t_чр*(1+q)*(1+a)*(1+b), (32)
где Т_р— трудоемкость разового решения задачи вручную, чел-ч. (предположим, что трудоемкость равна 32 чел-ч).
k — периодичность решения задачи в течение года, раз/год; (предположим, что решение задачи требуется раз в неделю – 52 раза/год)
t_чр— среднечасовая ставка работника, осуществляющего ручной расчет задачи, руб; (21 290 руб/час)
q — коэффициент, учитывающий процент премий (0,3);
q — коэффициент, учитывающий дополнительную заработную плату (0,15);
b — коэффициент, учитывающий начисления на заработную плату (0,36).
Подставив значения, получаем
З_р= 32*52*21 290*(1+0,3)*(1+0,15)*(1+0,36)= 72 029 282 руб. (33)
Для расчета годовых текущих затрат, связанных с эксплуатацией ПП, необходимо определить время решения данной задачи на ЭВМ.
Время решения задачи на ЭВМ определяется по формуле
Т_з=(Т_вв+Т_р+Т_выв )*(1+d_пз)/60, (34)
где Т_вв — время ввода в ЭВМ исходных данных, необходимых для решения задачи, мин;
Т_р— время вычислений, мин (поскольку все необходимые вычисления производятся параллельно с вводом исходных, Т_р равно нулю);
Т_выв— время вывода результатов решения задачи (включая время распечатки на принтере и графопостроителе), мин (равно нулю аналогично Т_р);
d_пз— коэффициент, учитывающий подготовительно-заключительное время (d_пз= 0,1).
Время ввода в ЭВМ исходных данных может быть определено по формуле
Т_вв=(Кz*Hz)/100, (35)
где Кz — среднее количество знаков, набираемых с клавиатуры при вводе исходных данных (8000 символов);
Hz - норматив набора 100 знаков, мин ( Hz = 6 ).
Подставив значения получим
Т_вв=(8000*6)/100=480 минут (36)
Найдем время решения задачи на ЭВМ:
Т_з=(480+0+0)*(1+0,1)/60=8,8 час. (37)
На основе рассчитанного времени решения задачи определим заработную плату пользователя данного приложения.
Зп=Т_з*k*t_чп (1+0,3)*(1+0,15)*(1+0,36)= 4539384 руб. (38)
где Т_з — время решения задачи на ЭВМ, час;
t_чп — среднечасовая ставка пользователя программы (21 290 руб/час).
Подставив значения, получим
Зп=8,8*52*21 290*(1+0,3)*(1+0,15)*(1+0,36)= 19 808 052 руб. (39)
В состав затрат, связанных с решением задачи включаются также затраты, связанные с эксплуатацией ЭВМ.
Затраты на оплату аренды ЭВМ для решения задачи определяются по следующей формуле
З_а=Т_з*k*S_мч, (40)
где S_мч — стоимость одного машиночаса работы ЭВМ , которая будет использоваться для решения задачи, руб (1391,6 руб.).
З_а=8,8*52* 1391,6= 636796,16 руб (41)
Годовые текущие затраты, связанные с эксплуатацией задачи, определяются по формуле
З_т = Зп + З_а= 19 808 052+ 636796= 20 444 848 руб/г (42)
Ожидаемый прирост прибыли в результате внедрения задачи взамен ручного ее расчета укрупненно может быть определен по формуле
П_у=(З_р-З_т )*(1-С_нп), (43)
где С_нп — ставка налога на прибыль (0,18).
П_у=(72 029 282- 20 444 848 )*(1- 0,18)= 42 299 236 руб
(43)
Расчет показателей эффективности использования программного продукта.
Для определения годового экономического эффекта от разработанной программы необходимо определить суммарные капитальные затраты на разработку и внедрения программы по формуле
К_о= К_з+ Ц_пр, (44)
где К_з— капитальные и приравненные к ним затраты;
Ц_пр— отпускная цена программы.
Поскольку для решения задачи необходимо приобретение новой ЭВМ, капитальные и приравненные к ним затраты определяются по формуле:
К_з= (Ц_бэвм*Т_з*k)/Ф_эвм =(8400000*8,8*52)/2100= 1830400 руб. (45)
Определим суммарные капитальные затраты.
К_о= 1830400 + 110288320 = 112 118 720 руб. (44)
Годовой экономический эффект от сокращения ручного труда при обработке информации определяется по формуле
Эф= Пу-Е* К_о, (45)
где Е -коэффициент эффективности, равный ставке за кредиты на рынке долгосрочных кредитов ( Е = 0.2).
Подставив значения получим:
Эф= 42 299 236-0,2*112 118 720 =19 875 492 руб. (46)
Срок возврата инвестиций определяется по формуле
Т_в= К_о/Пу=(112 118 720 )/(42 299 236)=2,7 года, (45)
Таблица 7.2 – Технико-экономические показатели проекта
Наименование показателя Варианты
базовый проектный
1. Трудоемкость решения задачи,час 24 8.8
2. Периодичность решения задачи, раз/год 52 52
3. Годовые текущие затраты, связанные с решением задачи, тыс.руб 72 029 20 445
4. Отпускная цена программы,тыс.руб 110 288
5. Степень новизны программы В
6. Группа сложности алгоритма 2
7. Прирост условной прибыли,тыс.руб 42 299
8. Годовой экономический эффект, тыс.руб 19 875
9. Срок возврата инвестиций, лет 2,7
ЗАКЛЮЧЕНИЕ
При выполнении дипломного проекта было создано работающее приложение, обеспечивающее базовое форматирование текста, поддержание синхронности текстов у различных пользователей и пригодное для реального применения.
Сравним приложение с ближайшим аналогом — Etherpad [17], который во многом использовался при разработке приложения как ориентир.
Недостатки приложения в сравнении с Etherpad:
— Отсутствие возможности разворота рабочей области во всю площадь окна браузера;
— Отсутствие функции экспорта документа в популярные форматы;
— Меньшие возможности для быстрого управления режимом доступа к документу (для этого нужно заходить на отдельную страницу);
— Отсутствие версионности документа (Etherpadпозволяет сохранять «ревизии» документа, который позже можно откатить на одну из них);
— Отсутствие возможности отмены чужих изменений;
По поводу последнего недостатка, однако, необходимо дать пояснение. Реализация этой функции в Etherpad такова, что при попытке использовать её в сколь-нибудь больших документах (уже порядка тысяч правок) серверная часть Etherpad испытывает очень большую нагрузку, что ведет к её зависанию или даже прекращению работы с ошибкой. Это делает практически невозможным применение данной функции на практике.
Достоинства приложения в сравнении с Etherpad:
— Более гибкая (хотя и менее удобная) система управления правами пользователей, позволяющая каждому отдельному пользователю запретить, например, чтение чата, оставив при этом доступ к документу;
— Возможность выбора произвольного авторского цвета. При кажущейся незначимости этой функции на деле ограниченная палитра Etherpadдоставляет определенные неудобства, когда количество редактировавших документ пользователей приближается к полутора-двум десяткам;
— Использование более современного протокола WebSocketsпри взаимодействии с сервером, что дает более высокую отзывчивость приложения и меньшую нагрузку на серверную часть.
— Более полная интеграция с текстовым редактором. В том числе обнаружение изменений не только путем периодического сравнения текста с сохраненной копией, но и путем отслеживания событий клавиатуры и мыши. Это позволяет быстрее передавать изменения на удаленные компьютеры и обеспечивает субъективно более высокий уровень комфорта при работе;
Как видно, несмотря на наличие некоторых недостатков, разработанное приложение вполне сравнимо с Etherpad, и в отдельных моментах обеспечивает больший комфорт м скорость работы.
Разработанное приложение может применяться на практике при совместном написании текстов (автор/авторы и редактор/редакторы), совместных переводах текстов (позволяет как одновременно работать над разными фрагментами и при этом видеть общий прогресс, так и одновременно работать над одним фрагментом текста), обсуждении текстовых документов (при этом возможно делать явно видимые пометки в тексте и пользоваться чатом документа), парном программировании и в других случаях.
Также определим пути дальнейшего развития приложения (по сути — план дальнейшей работы над программой), которые значительно улучшат комфорт при работе, доступность документов, вандалозащищенность и производительность труда:
— Возможность отмены произвольных изменений текста (в т.ч. не по порядку);
— Список всех изменений документа с указанием их авторства;
— Версионность;
— Возможность блокировки доступа к документу или приложению целиком по IP или диапазону IP;
— Возможность запрещать или разрешать доступ к приложению через TORодной настройкой;
— Поддержка анонимных (не прошедших процедуру регистрации) пользователей на том же уровне, что и поддержка зарегистрированных (гибкое изменение прав доступа, полный доступ к документам);
— Доработанный чат документа с поддержкой многострочных сообщений;
— Управление правами пользователей со страницы документа;
— Уведомления об изменении документа и сообщения в чате звуком и всплывающим окном (используя NotificationsAPIHTML5);
— Возможность блокировки изменения отдельных частей документа;
— Возможность установки права на очистку авторских цветов в тексте;
— Подсветка измененных строк документа;
— Всплывающее окно с указанием авторства фрагмента при наведении на текст;
— Возможность вставить в текст или чат ссылку на строку документа, введя текст «#ххх», где «ххх» — номер строки. При клике по ссылке курсор должен устанавливаться на начало этой строки в документе.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Коггзолл, Дж. PHP 5. Полное руководство: пер. с англ. / Джон Коггзолл. — Москва: Вильямс, 2006. — 752 с. ил.
Django (web_framework)[Электронныйресурс] / Википедия. — Электронные данные. — Режим доступа:http://en.wikipedia.org/wiki/Django_(web_framework) .
ФрименА. ASP.NETMVC 3 Frameworkс примерами на C# для профессионалов / Фримен А., Сандерсон С.— Москва: Вильямс, 2012. — 672 с. ил.
Ruby on Rails [Электронныйресурс] / Википедия. — Электронные данные. — Режим доступа:http://en.wikipedia.org/wiki/Ruby_on_Rails.
ASP.NETMVC 2 [Электронныйресурс]/ ScottGu’s. — Электронные данные. — Режим доступа:http://weblogs.asp.net/scottgu/archive/2010/01/10/asp-net-mvc-2.aspx
The Computer Language BenchmarksGame[Электронныйресурс]. — Электронные данные. — Режим доступа:http://benchmarksgame.alioth.debian.org.
Comparisonofwebapplicationframeworks[Электронныйресурс] / Википедия. — Электронные данные. — Режим доступа:http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
Reverse Ajax: Часть 1. Знакомство с концепцией Comet[Электронныйресурс]/ developerWorks. — Электронные данные. — Режим доступа:http://www.ibm.com/developerworks/ru/library/wa-reverseajax1/
ReverseAjax: Часть 2. WebSockets[Электронныйресурс]/ developerWorks. — Электронные данные. — Режим доступа:http://www.ibm.com/developerworks/ru/library/wa-reverseajax2/
XSocketsvsSignalR[Электронныйресурс]/ xsockets.net. — Электронные данные. — Режим доступа:http://xsockets.net/xsockets-vs-signalr
A Lightweight Operational Transformation Approach
An Admissibility-Based Operational Transformation Framework for Collaborative Editing Systems
http://badassjs.com/post/41959599945/verold-studio-a-realtime-webgl-based-collaborative-3d
ELLIS-89
http://en.wikipedia.org/wiki/Operational_transformation
Типовые нормы времени для программирования задач на ЭВМ
Etherpad
Системы «Управление проектами» на языке Scala
Дипломная работа по предмету «Компьютерные сети»