43673

Разработка программного модуля расчета статистических данных «Statistics» для Web – приложения «Office Planning System»

Дипломная

Информатика, кибернетика и программирование

Данный дипломный проект посвящен разработке программного модуля расчета статистических данных Sttistics для Web – приложения Office Plnning System. В данной пояснительной записке к дипломному проекту содержится подробное изложение всех этапов разработки программного модуля: изучение предметной области; постановка задачи включающая в себя анализ требований предъявляемых к программному модулю расчета статистических данных Web – приложения Office Plnning System ознакомление с архитектурой Web – приложения изучение...

Русский

2013-11-06

1.25 MB

21 чел.

Введение

Компания «МЕРА» один из крупнейших российских поставщиков услуг по оффшорному программированию для производителей IT и телекоммуникационного оборудования. «МЕРА» осуществляет полный цикл развития продукта, включая создание его концепции и программную разработку, поддержку, тестирование и внедрение, а также выполняет любой из названных этапов по отдельности.

Компания ООО «МЕРА НН» представляет собой комплекс большого числа связанных и взаимодействующих между собой подразделений: пять филиалов компании располагаются в Нижнем Новгороде, один – в Дзержинске. В деятельности такого предприятия оперативность, а также контроль над информацией являются первостепенным и непременным фактором нормального функционирования данной структуры.  

Данный дипломный проект посвящен разработке программного модуля расчета статистических данных «Statistics» для Web – приложения «Office Planning System». С помощью данного приложения у сотрудников компании, отвечающих за распределение персонала по рабочим местам, появится возможность получать всю необходимую им информацию для принятия оперативного и оптимального решения по данному вопросу.

В данной пояснительной записке к дипломному проекту содержится подробное изложение всех этапов разработки программного модуля:  

  1. изучение предметной области;
  2. постановка задачи, включающая в себя анализ требований, предъявляемых к программному модулю расчета статистических данных Web – приложения «Office Planning System»,
  3. ознакомление с архитектурой Web – приложения,
  4. изучение информационных технологий, применяемых для разработки Web – приложения,
  5. составление алгоритма решения поставленной задачи,
  6. разработка интерфейса программного модуля расчета статистических данных и руководства пользователя для работы с ним.

  1. Анализ предметной области

  1. Описание предметной области

В компании ООО «МЕРА НН» разработки в области IT – технологий ведутся в проектах, которые включают в себя ассистента проекта, менеджера проекта, команду программистов и тестировщиков. Работа в проекте предполагает разбиение поставленной задачи на совокупность подзадач, которые распределяются между  сотрудниками соответствующего проекта. В связи с этим, работа над задачей предполагает тесное взаимодействие коллектива проекта, поэтому рабочие места сотрудников, работающих в одном проекте, должны располагаться в одном кабинете. Этот факт должен обязательно учитываться при процедуре назначения рабочего места сотруднику.

Каждый день компания набирает новых сотрудников. При приеме на работу каждый кандидат, желающий получить должность в компании, должен пройти собеседование, по результатам которого, менеджеры проектов решают между собой вопрос, в какой проект его зачислить. В случае принятия положительного решения о трудоустройстве кандидата, менеджер по персоналу регистрирует нового сотрудника в QMS - корпоративной системе управления организацией. Руководитель сотрудника делает запрос на рабочее место. Рассмотрением данного запроса занимается ассистент проекта. В компании есть ещё, так называемые, внутренние вакансии, когда сотрудники переходят из одного проекта в другой. Эта процедура также связана с назначением нового рабочего места сотруднику.

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

  1. Актуальность разрабатываемого приложения

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

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

  1. Анализ предметной области и построение функциональной модели

Функциональное моделирование процессов с использованием методики IDEF0 позволяет получить концептуальные модели бизнес процессов компании. Анализ концептуальной модели поможет выявить узкие места в бизнес процессе планирования размещения сотрудников компании по рабочим местам и предложить пути решения устранения недостатков в бизнес процессе с целью его дальнейшей оптимизации.

Процесс назначения рабочего места сотруднику можно разбить на следующие процессы:

  1. принятие запроса: руководитель сотрудника посылает запрос на назначение рабочего места ассистенту проекта, ассистент принимает запрос, и находит в базе данных QMS всю имеющуюся на тот момент информацию о сотруднике;
  2. анализ возможных вариантов размещения сотрудника: ассистент проекта для выбора наиболее оптимального варианта размещения анализирует информацию о сотруднике, информацию о размещении команды проекта, куда зачислен сотрудник. Также ассистент должен учитывать увольнения, отпуска сотрудников проекта и многие другие факторы. Результатом выполнения данной работы является вариант размещения сотрудника на определенном рабочем месте;
  3. принятие/отклонение варианта: результат выполнения предыдущей работы отправляется менеджеру проекта, который, руководствуясь решением  об оптимальном размещении сотрудников своего проекта, вправе принять вариант или отклонить его. В случае отклонения предложенного варианта, менеджер проекта оправляет запрос на подбор другого варианта размещения сотрудника ассистенту проекта;
  4. запись данных в QMS: в случае, если менеджер проекта принимает вариант размещения сотрудника, предложенный ассистеном, данные о назначенном месте (офис, номер комнаты, номер рабочего места) направляются менеджеру по персоналу, который заносит эти данные в систему QMS.

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

Контекстная диаграмма предметной области, являющаяся вершиной древовидной структуры диаграмм и представляющая собой самое общее описание системы и ее взаимодействия с внешней средой, представлена на рисунке А.1 приложения А. Более детальное описание предметной области – диаграмма декомпозиции представлена на рисунке А.2 в приложении А.

  1. Разработка технического задания

  1. Введение

Настоящее техническое задание распространяется на разработку программного модуля web – приложения, предназначенного для использования менеджерами проектов при планировании и  распределении рабочих мест в компании.

  1. Основание для разработки
    1. Наименование работы: «Программный модуль Statistics».
    2. Исполнитель: ООО «Мера НН»
    3. Соисполнители: нет
    4. Основания разработки

 Каждая организация стремиться минимизировать затраты времени, материальных, трудовых ресурсов в ходе своей деятельности и упростить процесс обработки информации. Значимым фактором успеха в деятельности предприятия является применение информационных технологий, автоматизации процесса работы, обеспечивающие согласованное и четкое функционирование всех служб предприятия. В связи с этим руководство компании приняло решение оптимизировать процесс планирования размещения сотрудников по рабочим местам путем разработки соответствующего приложения.

  1.  Назначение разработки

Программный модуль «Statistics» будет являться составным звеном приложения, которое разрабатывается с целью того, чтобы:

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

Добавление в web – приложение «Office Planning System» модуля расчета статистических данных «Statistics» позволит пользователю получать статистические данные в удобном для восприятия и анализа виде.

  1. Требования к программному модулю
    1. Требования к функциональным характеристикам

 Программный модуль должен обеспечивать возможность выполнения следующих функций:

  1. расчет статистических данных - общее количество рабочих мест, количество свободных и занятых рабочих мест, коэффициент использования помещения по выбранной пользователем категории – комната, этаж, здание;
  2. расчет статистических данных по департаментам (название департамента и количество человек, числящихся в нем) по выбранной пользователем категории – комната, этаж, здание;
  3. вывод статистических данных в удобном для просмотра и анализа виде.
    1. Исходные данные

Исходными данными для работы модуля расчета статистики являются данные, представленные следующими таблицами в базе данных приложения:

  1.  Employee – информация о сотрудниках, содержит ссылки на рабочие места и департаменты;
  2.  Department – информация о департаментах (проектах);
  3.  Workplace  – информация о рабочих местах;
  4.  Room – информация о комнатах;
  5.  Floor – информация о этажах;
  6.  Location – информация о зданиях.
    1. Организация входных и выходных данных

 Входные данные программного модуля, необходимые для расчета статистических данных, хранятся в базе данных приложения.

Выходные данные программного модуля расчета статистических данных отображаются на экране монитора.

  1. Требования к информационной и программной совместимости

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

  1. для работы с базой данных -  систему управления базой данных (СУБД) Microsoft SQL Server;
  2. для реализации логики приложения – среду разработки Microsoft Visual Studio. Для написания приложения используется объектно – ориентированный язык  программирования Visual С#.
  3. для реализации графического пользовательского интерфейса – HTML;
  4. JavaScript для формирования и обработки запросов, используемых для программного доступа к объектам приложения, обеспечивающих интерактивность web – страниц.
    1. Требования к составу и параметрам технических средств

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

  1. процессор c частотой не менее 3GHz;
  2. объем оперативной памяти 4 – 8 Gb;
  3. операционная система Windows 7.

В качестве клиентов web – приложения могут выступать компьютеры со следующими характеристиками:

  1. процессор c минимальной частотой 1,6 GHz;
  2. объем оперативной памяти 2 – 4 Gb;
  3. любая операционная система;
  4. браузер Internet Explorer/FireFox.
    1. Требования к документации

В состав программной документации входят:

  1. техническое задание, подписанное заказчиком, в соответствии с которым будет производиться разработка программного модуля для расчета статистических данных,
  2. руководство пользователя, предназначенное для ознакомления пользователей с правилами работы программного модуля расчета статистических данных.
    1. Требования к интерфейсу

При разработке интерфейса программного модуля необходимо учесть следующие требования:

  1. графический интерфейс программного модуля должен быть дружественным, интуитивно понятным,
  2. дизайн интерфейса должен обеспечивать минимизацию усилий пользователя при выполнении работы,
  3. выбранная цветовая гамма, шрифты, расположение элементов не должны утомлять пользователя при работе с программой.

  1. Технико-экономические показатели

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

  1.  материальные затраты:

а) затрат на материалы,

б) энергетических затрат,

в) затрат на малоценное оборудование,

г) затраты на оплату услуг сторонних организаций.

  1.   затраты на накладные расходы,
  2.  затраты по заработной плате специалистам, участвующим в разработке программного модуля для web – приложения (фонд заработной платы, начисления на заработную плату).
  3. Порядок контроля и приемки

После разработки отдельного функционального модуля программы он передается тестерам, входящим в состав проекта. Тестеры составляют тест – план, который покрывает всю функциональность программного модуля. Тестирование проводится с помощью Test Manager в составе среды Microsoft Visual Studio.

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

  1. Стадии и этапы разработки

Весь процесс разработки программного модуля для расчета статистических данных необходимо разбить на определенные этапы, время выполнения которых также оговаривается заказчиком и исполнителем. Этапы разработки программного модули расчета статистических данных приведены в таблице 1.

Таблица 1 – Этапы разработки программного модуля

Наименование этапа разработки

Результат

Формирование требований к программному модулю и разработка концепции:

- исследование предметной области,

- формирование требований к программному модулю приложения.

Функциональные требования к программному модулю

Разработка концепций

Утверждение концепции разработки программного модуля

Продолжение таблицы 1

Разработка технического задания: формулирование четких требований к программному модулю

Подписанное техническое задание на разработку программного модуля

Проектирование программного модуля

Разработанный программный модуль

Тестирование программного модуля

Отчет об успешном тестировании программного модуля/отчет о выявленных недостатках в работе модуля

Доработка программного модуля

Конечный вариант программного модуля

 

  1. Выбор и обоснование структуры программного обеспечения «Office Planning System»
  2. Преимущества работы с web – приложением

Было принято решение, приложение «Office Planning System» реализовать в качестве web – приложения. Используя web – приложение, сотрудники получат возможность в любое время работать с данными, сосредоточенными в информационном массиве непосредственно на отдаленном сервере. При этом пользователь не нуждается в установке тяжеловесного программного обеспечения. Все, что требуется для полноценной работы – это браузер, обычно поставляемый вместе с операционной системой, и доступ в интернет. Web – приложения не требовательны к ресурсам и не предъявляют никаких требований к аппаратной платформе в отличии от настольных приложений. Использование web – приложений даст такие преимущества, как независимость от типа операционной системы клиента, объема оперативной памяти компьютера пользователя. Кроме того, нет никаких проблем с поддержкой старых версий программ и обратной совместимостью. Когда появляется новая версия настольного приложения, пользователям нередко приходится решать проблемы, связанные с обновлением уже установленной на их машине копии. В случае с web – приложениями таких проблем не возникает - существует только одна версия, в которой работают все пользователи, и в случае выхода новой все без исключения автоматически переходят на нее, порой даже не замечая этого. И наконец, web – приложения позволяют своим пользователям быть по-настоящему мобильными: работать в сети, сохранять результаты своей работы на сервере и, в случае необходимости, иметь к ним доступ отовсюду, где есть выход в интернет.

  1. Принцип работы Web – приложения

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

Web – приложение  «Office Planning System» состоит из двух частей:

  1.  серверная,
  2.  клиентская.

Серверная часть предназначена для:

  1.  хранения копии данных QMS;
  2.  обновления данных QMS;
  3.  хранения карт помещений;
  4.  хранения несоответствий данных и реальной ситуации (коллизий);
  5.  хранения плана по перемещению персонала.

Клиентская (менеджерская) часть предназначена для:

  1.  отображения расположения сотрудников в кабинетах компании;
  2.  планирования перемещения персонала;
  3.  просмотра данных о коллизиях;
  4.  поиска сотрудников;
  5.  обзора статистических данных.

  1. Требования к функционалу приложения

Приложение  «Office Planning System» должно предоставлять следующие возможности пользователю:

  1. изучение содержания зданий и комнат;
  2. поиск и просмотр месторасположения сотрудника;
  3. планирование и управление перемещением работников;
  4. просмотр статистических данных;
  5. поиск несоответствий реального расположения сотрудников и данных из QMS;
  6. создание и редактирование карты комнат и этажей;

Более подробные требования к функциональности разрабатываемого приложения можно представить с помощью диаграммы прецедентов использования.

Диаграммы прецедентов составляют модель прецедентов (вариантов использования, use-cases). Прецедент - это функциональность системы, позволяющая пользователю получить некий значимый для него, ощутимый и измеримый результат. Каждый прецедент соответствует отдельному сервису, предоставляемому моделируемой системой в ответ на запрос пользователя, то есть определяет способ использования этой системы. Именно по этой причине use cases, или прецеденты, часто в русской терминологии фигурируют как варианты использования. Варианты использования чаще всего применяются для спецификации внешних требований к проектируемой системе или для спецификации функционального поведения уже существующей системы. Кроме этого, варианты использования неявно описывают типичные способы взаимодействия пользователя с системой, позволяющие корректно работать с предоставляемыми системой сервисами. Диаграмма прецедентов использования для web – приложения планирования перемещения персонала представлена на рисунке ? На диаграмме прецедентов обычно изображают действующее лицо, то есть пользователя приложения, в виде схематичного изображения человека, а также прецеденты, которые на диаграмме изображают в овалах.

Рисунок – Диаграмма прецедентов использования

  1. Состав модулей приложения

Приложение «Office Planning System» организованно по модульному принципу. Модульное приложение является приложением, которое можно разделить на ряд функциональных блоков (модули), интегрированных в одно приложение.  Модульный подход к построению приложения может помочь выделить функциональные области и разрабатывать или тестировать их независимо, что сделает разработку и тестирование легче, а приложение более гибким и легко расширяемым в будущем. После анализа предметной области и вышеперечисленных требований к приложению, было принято решение разбить его на пять функциональных модулей.

  1. Модуль «Plan»

Модуль «Plan» отвечает за графическое отображение выбранной пользователем комнаты. На плане схематически отображена комната с рабочими местами. Каждое рабочее место имеет свой номер и цвет – в зависимости  от того, занято оно или свободно. Если место занято, на схеме отображается фамилия, имя и отчество сотрудника, занимающего данное место, а также название департамента, за которым числится данный сотрудник. С помощью данного модуля можно изучать содержание комнат и легко находить свободные места.

  1. Модуль «Search»

Модуль «Search» отвечает за поиск и просмотр информации о месторасположении сотрудника. Поиск может осуществляться по трем параметрам – фамилия (Last Name), имя (First Name) и название департамента (Department). Найденная информация содержит такие данные, как фамилия, имя, отчество сотрудника, название департамента, за которым числиться сотрудник, а также подробная информация о его месторасположении – название офиса(Location), номер этажа(Floor), номер комнаты(Room), номер рабочего места(Workplace).

  1. Модуль «Replacement Tasks»

Модуль «Replacement Tasks» отвечает за планирование и управление перемещением сотрудника. Пользователь, создавая новую задачу перемещения (Add task), выбирает из списка работника, которого хочет переместить, а также все параметры его планируемого рабочего места - название офиса(Location), номер этажа(Floor), номер комнаты(Room), номер рабочего места(Workplace). При этом к этим данным автоматически добавляется дата создания задачи перемещения и статус задачи («активна»). Задача перестает быть активна, когда данные о рабочем месте сотрудника в базе данных QMS будут совпадать с данными, указанными при создании задачи перемещения. Также в этом модуле есть возможность отмены задачи перемещения (кнопка Delete task).

  1. Модуль «Collisions»

Модуль «Collisions» отвечает за поиск несоответствий реального расположения сотрудников и данных об их расположении в корпоративной базе данных QMS, например, когда по данным QMS за одним рабочим местом закреплены два работника.  Подобные несоответствия возникают из-за того, что данные в QMS заносятся вручную и есть вероятность опечатки, либо же из-за того, что изначально недостоверные данные предоставлены для занесения в базу данных, в которой нет функции проверки того, занято ли данное место или нет. При запуске приложения «Office Planning System» модуль обработает данные QMS и в случае нахождения коллизии, выведет параметры рабочего места - название офиса(Location), номер этажа(Floor), номер комнаты(Room), номер рабочего места(Workplace) и данные о сотрудниках, за которыми закреплено это рабочее место в QMS. После этого в QMS находят ошибку, данные редактируются и несоответствие устраняется.

  1. Модуль «Statistics»

Модуль «Statistics» отвечает за просмотр статистических данных по выбранной категории – офис(Location), номер этажа(Floor), номер комнаты(Room). К статистическим данным относится данные об общем количестве рабочих мест, свободном и занятом количестве мест, коэффициенте использования, то есть  отношении занятых рабочих мест к общему количеству мест в категории. Так как немаловажным фактором при назначении сотруднику рабочего места является департамент, за которым тот числиться, то модуль «Statistics»  предоставляет статистику и по департаментам – название департамента и количество сотрудников, числящихся в данной департаменте в выбранной категории.

На рисунке 1 приведена структурная схема приложения, на которой отображены состав компонентов приложения (совокупность вышеперечисленных модулей), источники и потребители информации.

 

Рисунок 1 – Структурная схема приложения «Office Planning System»

  1. Обеспечение задачи

  1.  По информационному обеспечению

Исходными данными для работы приложения «Office Planning System» являются общедоступные данные из корпоративной базы данных QMS. Эти данные представлены следующими таблицами:

  1.  работник (Employee) – информация о сотрудниках, содержит ссылки на рабочие места и департаменты;
  2.  проект (Department) – информация о департаментах (проектах);
  3.  рабочее место (Workplace)  – информация о рабочих местах;
  4.  комната (Room) – информация о комнатах;
  5.  этаж (Floor) – информация об этажах;
  6.  офис (Location) – информация о зданиях.

Для взаимодействия базы данных приложения и корпоративной базы данных имеется специальное приложение Rooms Updater, запускаемое на сервере раз в сутки для актуализации и обновления данных приложения из корпоративной базы данных QMS. Приложение Rooms Updater обновляет все данные в базе данных приложения «Office Planning System», за исключением тех, которые хранятся в таблице план помещения (Plan) и в таблице объектов, необходимых для отображения плана помещения (PlanObject). Схема взаимодействия баз данных приведена на рисунке 2.

Рисунок 2 – Схема взаимодействия базы данных QMS и базы данных  приложения

Также в базе данных приложения хранятся данные, которых нет в корпоративной базе данных QMS, но которые также необходимы для функционирования «Office Planning System»:

  1.  планируемые перемещения сотрудников (Replacement Task) – информация о планируемых перемещениях сотрудников;
  2. план помещения (Plan) – данные, необходимые для графического отображения комнат;
  3. объекты, необходимые для построения плана (PlanObject) – данные, необходимые для графического отображения рабочих мест в комнатах.

Все вышеперечисленные данные составляют базу данных приложения «Office Planning System». База данных приложения является реляционной. В таких базах данных данные в одних таблицах, как правило, связаны с данными других таблиц, откуда и произошло название "реляционные". Кратко особенности реляционной базы данных можно описать следующим образом:

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

Основные понятия, характеризующие реляционные базы данных:

  1. первичный ключ (сокращенно обозначают как PK primary key) представляет собой один из примеров уникальных индексов и применяется для уникальной идентификации записей таблицы. Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа;
  2. внешний ключ (сокращенно обозначают как FK foreign key): внешний ключ одной таблицы ссылается на первичный ключ другой таблицы, устанавливая однозначную логическую связь между записями таблиц;
  3. уникальный индекс представляет собой список значений, в котором каждое значение уникально.

Схема базы данных приложения «Office Planning System» приведена на рисунке ?

Рисунок – База данных приложения «Office Planning System»

  1. По программному обеспечению

Для функционирования приложения на сервере необходимо следующее программное обеспечение:

  1. Microsoft SQL Server 2008 Express – это мощная и надежная система управления базами данных, обеспечивающая множество функций, защиту данных и высокую производительность для внедренных приложений-клиентов, «легких» веб-приложений и локальных хранилищ данных;
  2.  Microsoft.NET Framework 4.5 - набор библиотек и системных компонентов, которые необходимы для работы приложений, основанных на архитектуре .NET Framework;
  3. операционная система Windows 7, работу с которой поддерживают СУБД Microsoft SQL Server 2008 Express и платформа .NET Framework.

Для функционирования приложения на клиенте необходимо следующее программное обеспечение:

  1. браузер, с которым данное приложение поддерживает работу, а именно Internet Explorer, FireFox.

  1. По техническому обеспечению

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

На рабочих местах установлены машины, имеющие следующие технические характеристики:

  1. процессор – Intel Core i3 540 с мощностью 3,07GHz;
  2. разрядность операционной системы – 64 бит;
  3. объем оперативной памяти – 8 Гб.

Для работы с приложением «Office Planning System» такого технического обеспечения достаточно, то есть модернизации технических средств, установленных на местах будущих пользователей приложения, не требуется.

  1. Проектирование архитектуры web – приложения

  1. Обоснование выбора типа архитектуры приложения

В качестве архитектуры web – приложения «Office Planning System» был выбран шаблон Domain Driven Design (DDD). Основным преимуществом использования данного подхода при проектировании приложения является то, что части разрабатываемого приложения можно легко сделать масштабируемыми и независимыми. При использовании данного шаблона основное внимание уделяется созданию модели предметной области или модели домена. Domain Driven Design - способ проектирования, который фокусируется прежде всего на предметной области, на объектах реального мира, их поведении и взаимодействии, то есть фокусируется на модели и бизнес-логике, а не на структуре данных. Результатом подобного подхода становится то, что мы стараемся перевести объекты предметной области и их поведение сразу в сущности приложения, пытаясь передать в них не только свойства и атрибуты этих объектов, но и поведение.  

При разработке приложения необходимо по – максимуму минимизировать внутренние связи: архитектура создаваемого приложения должна позволять без особых усилий и риска менять компоненты, входящие в состав приложения. В связи с этим, приложение «Office Planning System» имеет четырехуровневую архитектуру, которая разделяет приложение на четыре логических слоя:

  1. слой Persistence – это слой доступа к данным, хранящимся в базе данных приложения;
  2. слой Domain – слой, представляющий логическую модель предметной области, то есть слой, на котором описаны все классы – сущности, отражающие объекты реального мира;
  3. слой Application – это слой приложения, на котором осуществляется обработка данных;
  4. слой Presentation – это слой представления, предназначенный для взаимодействия с пользователем приложения.

Четырехуровневая архитектура построения приложения отражена в проводнике Solution Explorer. Проводник решений Solution Explorer пакета Microsoft Visual Studio, в котором ведется разработка web – приложения «Office Planning System» показан на рисунке 3.


                     Рисунок 3 – Проводник решений Solution Explorer

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

  1. Слой доступа к данным «Persistence Layer»

Слой «Persistence Layer» или слой доступа к данным включает в себя совокупность репозиториев. Репозитории – это объекты представления основной базы данных. Вместо того, чтобы не работать непосредственно с базой данных приложения с использованием SQL – запросов, доменная модель (слой Domain) вызывает методы, определенные в репозитории, который в свою очередь делает запросы в базу данных для сохранения и извлечения данных модели. Репозитории касаются только загрузки и хранения данных – они не содержат доменной логики вообще.

Так как приложение работает с данными в объектно – ориентированном виде, а данные в базе данных приложения хранятся в реляционной форме, при работе необходимо постоянно преобразовывать объектные структуры приложения в форму, удобную для сохранения в реляционной базе данных, а также выполнять обратную задачу – развертывания реляционной модели в объектную с сохранением свойств объектов и отношений между ними. Для решения этой проблемы используется специальная технология – Entity Framework. ADO.NET Entity Framework (EF) — объектно-ориентированная технология доступа к данным, является ORM (Object-Relation Mapping) решением для .NET Framework от Microsoft. ORM или объектно – реляционное отображение – это технология программирования, которая связывает базу данных с концепциями объектно – ориентированного программирования, создавая «виртуальную базу данных». Entity Framework поддерживает подход "Code first". Вне зависимости от наличия базы имеется возможность вручную написать код классов и свойств (POCO – классы, Pretty Old CLR Objects), соответствующих сущностям в базе и использовать этот код с Entity Framework. Если базы ещё нет, Entity Framework может создать, удалить или пересоздать её в случае изменений в модели. В терминологии Entity Framework множество сущностей относится к таблице базы данных, и сущность относится к записи в таблице.

  1.  Слой модели предметной области «Domain Layer»

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

Доменной модель предметной области представлена следующими сущностями:

  1.  Location (офис), которая имеет такие свойства как DisplayName (название офиса);
  2.  Floor (этаж), которая такие свойства как DisplayName (номер этажа), QMSLocalId (уникальный номер этажа в QMS);
  3.  Room (комната), которая имеет такие свойства как DisplayName (номер комнаты), QMSFloor (номер этажа, на котором располагается комната), QMSLocalId (уникальный номер комнаты в QMS);
  4.  Workplace (рабочее место) , которая имеет такие свойства как DisplayName (номер рабочего места), QMSRoomId (уникальный номер комнаты, в которой располагается рабочее место), WorkplaceOnPlan (уникальный номер комнаты в QMS);
  5.  Plan (план комнаты), которая имеет такие свойства как DisplayName (название комнаты), Height (длина комнаты), Width (ширина комнаты), PathRoom (путь для комнаты), Room (ID комнаты);
  6.  PlanObject (объекты для построения плана), которая имеет такие свойства как AssociatedId (Id рабочего места), DirectionValue (направление), DisplayName (название объекта), Height (длина), Width (ширина), ObjectTypeValue (тип объекта), PathObject (путь к объекту), X (), Y ();
  7.  Departament (департамент), которая имеет такие свойства как DisplayName (название департамента), QMSId (уникальный номер департамента в QMS), ColorHex (Цвет);
  8.  Employee (работник), которая имеет такие параметры как DepartamentsEmployee (название департаментов, к которым относится работник), FirstName (имя), LastName (фамилия), MiddleName (отчество), QMSId (уникальный номер работника в QMS), Workplace (номер рабочего места);
  9.  ReplacementTask (задачи перемещения), которая имеет такие параметры как CreateBy (), Date (дата создания), State (статус).

 Доменная модель предметной области представлена на рисунке 4.

Рисунок 4 – Доменная модель предметной области

  1. Слой приложения «Application Layer»

Слой «Application Layer» – это слой приложения, на котором осуществляется обработка данных. На этом слое создаются так называемые сервисы, которые содержат методы обработки данных.

В сервисе осуществляется взаимодействие с репозиториями, откуда он берет данные для обработки, но не напрямую, а через интерфейс. Взаимодействие данного уровня с вышестоящим уровнем (Presentation Layer) осуществляется также при помощи интерфейса. Интерфейс представляет собой не более чем просто именованный набор абстрактных членов. Абстрактные методы являются чистым протоколом, поскольку не имеют никакой стандартной реализации. Интерфейс выражает поведение, которое класс или структура может избрать для поддержки. Более того, каждый класс или структура может поддерживать столько интерфейсов, сколько необходимо, и, следовательно, тем самым поддерживать множество поведений. Для имплементации интерфейса, при объявлении класса необходимо указать, что данный класс наследуется от соответствующего интерфейса.

Кроме интерфейса и сервиса  на уровне приложения описываются классы DTO. DTO (Data Transfer Object) – это объекты классов, предназначенные для передачи данных. Данные объекты создаются перед передачей данных на уровень представления и содержат именно те параметры, которые необходимы для представления пользователю.

  1. Слой представления «Presentation Layer»

Слой «Presentation Layer» - это слой представления, предназначенный для взаимодействия с пользователем. Для организации уровня представления использовалась технология ASP.NET MVC.

ASP.NET MVC – это фреймворк для создания web – приложений, который реализует шаблон MVC (ModelViewController). Это дает разделение модели данных приложения, пользовательского интерфейса и взаимодействия с пользователем на три отдельных компонента. При таком подходе модификация одного из компонентов оказывает минимальное воздействие на остальные компоненты. Назначение компонентов MVC шаблона можно описать следующим образом:

  1. модель (Model) – это компонент, отвечающий за описание данных, с которыми работает приложение, то есть набора классов, позволяющих работать с данными;
  2. представление (View) – это компонент, отвечающий за отображение информации пользователю, то есть это компонент визуализации;
  3. контроллер (Controller) – это компонент, который обеспечивает взаимодействие приложения с пользователем, используя модель и представление для реализации необходимой реакции.

Паттерн MVC работает по следующему принципу:

  1. браузер пользователя отправляет запрос на сервер, тот передает его ASP.NET MVC;
  2.  MVC при помощи маршрутов определяет, какой из контроллеров должен выполнить запрос;
  3. управление передается соответствующему контроллеру;
  4. на основании запроса выполняется определенный метод контроллера во взаимодействии с моделью данных;
  5. генерируется некоторая модель (модель представления), которая передается представлению;
  6. представление в соответствии с полученной моделью генерирует разметку;
  7. браузер отображает полученную разметку, то есть пользователь получает результат своего запроса.

В приложении «Office Planning System» используется не классический архитектурный MVC шаблон, а его разновидность - Web API. Разница заключается в принципе работы контроллера – методы контроллера Web API возвращают браузеру не представление, а данные. Схематическое представление принципов работы классического MVC и его частного случая – WebApi приведено на рисунке 5.

а)

б)

а – классический MVC; б – MVC WebApi

Рисунок 5 – Архитектурный шаблон MVC

Unity:

Архитектура приложения «Office Planning System» приведена на рисунке Б.1 в приложении Б.

Все программные модули приложения должны быть построены по одному принципу. К моменту начала разработки модуля «Statistics» были разработаны модули «Plan», «Search» и «Replacement Tasks». Поэтому разработка модуля «Statistics» велась в соответствии с теми проектными решениями, которые были применены для разработки уже функционирующих модулей в приложении «Office Planning System» – в среде Microsoft Visual Studio на языке программирования Visual С#, позволяющем создавать веб – приложения для платформы .Net Framework

  1. Реализация решения задачи, сформулированной в техническом задании

На момент начала разработки программного модуля «Statistics» была описана логическая модель предметной области и создана база данных приложения, так как часть его уже была разработана. Модуль будет производить только математические вычисления с данными для предоставления статистики, при этом, не внося в них корректировки, то есть данные не будут изменяться, добавляться и удаляться. Вследствие чего разработка модуля затронула только два слоя архитектуры DDD (Domain Driven Design) – слоя приложения (Application Layer), на котором производится обработка данных и слоя представления (Presentation Layer), который предназначен для взаимодействия с пользователем.

Схема базы данных приведена на рисунке В.1 в приложении В.

 

Слой Application предназначен для обработки данных по запросу, приходящему от пользователя через слой Presentation. Так как некоторые модули к моменту разработки модуля «Statistics» были уже готовы и функционировали, то в слое Application уже был создан сервис, в котором описана реализация различных методов по обработке данных приложения. Именно в этом сервисе мы создадим методы, которые будут возвращать нам статистические данные. Так как статистика по наличию мест должна рассчитываться отдельно для офиса, этажа и комнаты, а также предоставляться статистика по департаментам, в сервисе мы реализуем пять методов:

  1. метод, определяющий, по какой категории пользователь запросил статистические данные (офису, этажу или комнате);
  2. метод, предоставляющий статистику по офису;
  3. метод, предоставляющий статистику по этажу;
  4. метод, предоставляющий статистику по комнате;
  5. метод, предоставляющий статистику по департаментам.

Взаимодействие сервиса с вышестоящим уровнем, уровнем представления, осуществляется не напрямую, а через интерфейс. Благодаря наличию интерфейса уровень представления не видит конкретной реализации методов  уровня приложения.   Код интерфейса и методов, реализующих подсчет статистических данных, приведен в приложении Г.

Код реализации DTO – классов приведен в приложении Д.

Уровень представления реализован по технологии MVC WebApi. В качестве представления (View) выступает веб – часть, то есть клиентская часть приложения, которая обращается к контроллеру (Controller) за получением необходимых данных. Тот в свою очередь обращается через интерфейс к сервису уровня приложения. Когда контроллер получает необходимую информацию по своему запросу, он передает ее обратно в представление. Передача DTO – объектов между контроллером и представлением осуществляется в формате JSON. JSON (JavaScript Object Notation) - простой формат обмена данными, удобный для чтения и написания, как человеком, так и компьютером. Это текстовый формат, полностью независимый от языка реализации, но он использует соглашения, знакомые программистам C-подобных языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других. Эти свойства делают JSON идеальным языком обмена данными. Код контроллера приведен в приложении Е. Клиентская часть, предназначенная для взаимодействия с пользователем, находится в стадии разработки.

Заключение

Прохождение преддипломной практики в компании ООО «МЕРА НН» можно дало возможность проверить готовность к самостоятельной трудовой деятельности по специальности и получить новые теоретические знания и практические навыки. В ходе прохождения преддипломной практики был получен опыт разработки приложений, а также изучены следующие аспекты:

  1. архитектурные шаблоны построения приложений;
  2. информационные технологии, применяемые для написания веб – приложений;
  3. новые языки программирования – С#, JavaScript;
  4. современные средства работы с базами данных.

По итогам преддипломной практики был собран материал для дипломного проектирования. Предварительная тема дипломного проекта определена как «Разработка программного модуля по расчету статистических данных для веб – приложения планирования перемещения сотрудников компании».

Список литературы

  1. Шилдт Герберт. Полный справочник по С#.: Пер. с англ. – М.: Издательский дом «Вильямс», 2004. – 752 с.: ил. – Парал. тит. англ.
  2. Лабор В. В. Си Шарп: Создание приложений для Windows/В. В. Лабор. – Мн.: Харвест, 2003. – 384 с.
  3. Тоелсен Э. С# и платформа .NET. Библиотека программиста. – СПб.: Питер, 2004. – 796с.
  4. Сандерсон Стивен. ASP.NET MVC Framework с примерами на С# для профессионалов. : Пер. с англ. – М.: ООО «И. Д. Вильямс», 2010.  – 560 с.: ил. – Парал. тит. англ.
  5. Рихтер Джеффри. CLR via C#. Программирование на платформе Microsoft .NET Framework 2.0 на языке С#. – СПб.: Питер, 2007. – 656с.
  6.  http://www.somewheresomehow.ru/magic-of-entity-framework
  7.  http://www.techdays.ru/videos
  8.  http://msdn.microsoft.com/ru-ru/asp.net/
  9.  http://ab-w.net/HTML/HTML.php

Приложение А

Диаграммы IDEF0

Рисунок А.1 – Контекстная диаграмма IDEF0

Рисунок А.2  - Диаграмма декомпозиции IDEF0

Приложение Б

Архитектура веб – приложения

Рисунок Б.1 – Архитектура веб – приложения «Office Planning System»

Приложение В

Модели данных предметной области

Рисунок В.1 – Физическая модель данных предметной области

Приложение Г

Уровень приложения (Application Layer)

  1. Код интерфейса

public interface IRoomsService

 {

  .....

 NodeStatisticsDTO GetStatistics (Guid nodeId);

 .....

 }

  1. Код сервиса

public class RoomsService : IRoomsService

   {

public NodeStatistcsDTO GetStatistics(Guid nodeId)

       {

           var locations = _locationRepository.GetFiltered(l => l.Id == nodeId);

           if (locations != null && locations.Any())

           {

               return GetStatisticsForLocation(locations.First());

           }

           var floors = _floorRepository.GetFiltered(f => f.Id == nodeId);

           if (floors != null && floors.Any())

           {

               return GetStatisticsForFloor(floors.First());

           }

           

    var rooms = _roomRepository.GetFiltered(r => r.Id == nodeId);

           if (rooms != null && rooms.Any())

           {

               return GetStatisticsForRoom(rooms.First());

           }

           return new NodeStatistcsDTO();

       }

       private NodeStatistcsDTO GetStatisticsForLocation(Location location)

       {

           var result = new NodeStatistcsDTO();

           result.InnerStatistics = new List<NodeStatistcsDTO>();

           result.DepartmentStatistcs = new List<StatisticDepartmentDTO>();

           result.NodeId = location.Id;

           result.DisplayName = location.DisplayName;

        foreach (var floor in location.Floors)

        {

            var rs = GetStatisticsForFloor(floor);

            result.Total += rs.Total;

            result.Free += rs.Free;

            result.Employees += rs.Employees;

                 

 if (result.Total > 0)

        {

          result.Index = result.Employees / result.Total;

        }

          result.InnerStatistics.Add(rs);

       }

           var employees = GetEmployeesFromLocation(location);

           result.DepartmentStatistcs = GetDepartmentStatistics(employees).ToList();

           

           return result;

       }

       private NodeStatistcsDTO GetStatisticsForFloor(Floor floor)

       {

           var result = new NodeStatistcsDTO();

           result.InnerStatistics = new List<NodeStatistcsDTO>();

           result.DepartmentStatistcs = new List<StatisticDepartmentDTO>();

           result.NodeId = floor.Id;

           result.DisplayName = floor.DisplayName;

         

           foreach (var room in floor.Rooms)

           {

                   var rs = GetStatisticsForRoom(room);    

                   result.Index = 0;

                   result.Free += rs.Free;

                   result.Total += rs.Total;

                   result.Employees += rs.Employees;

                  

                   if (result.Total > 0)

                   {

                       result.Index = result.Employees / result.Total;

                   }

                   result.InnerStatistics.Add(rs);

            }

           var employees = GetEmployeesFromFloor(floor);

           result.DepartmentStatistcs = GetDepartmentStatistics(employees).ToList();

           return result;

       }

       private NodeStatistcsDTO GetStatisticsForRoom(Room room)

       {

           var result = new NodeStatistcsDTO();

           

           result.Index = 0;

           result.Total = room.Workplaces.Count();

           result.Free = room.Workplaces.Count(w => w.Employee == null);

           result.Employees = room.Workplaces.Count(w => w.Employee != null);

           result.InnerStatistics = new List<NodeStatistcsDTO>();

           result.DepartmentStatistcs = new List<StatisticDepartmentDTO>();

           result.NodeId = room.Id;

           result.DisplayName = room.DisplayName;

           if (result.Total > 0)

           {

             result.Index = (result.Employees) / (result.Total);

           }

           

           var employees = GetEmployeesFromRoom(room);

           if (employees.Any())

           {

               result.DepartmentStatistcs = GetDepartmentStatistics(employees).ToList();

           }  

           return result;

       }

       private IEnumerable<StatisticDepartmentDTO>GetDepartmentStatistics(IEnumerable<Employee> employees)

       {

           var dic = new Dictionary<string, int>();

           foreach (var employee in employees)

           {

               if (dic.ContainsKey(employee.Department.DisplayName))

               {

                   dic[employee.Department.DisplayName] += 1;

               }

               else

               {

                   dic.Add(employee.Department.DisplayName, 1);

               }

           }

           var departmentStatistcs = new List<StatisticDepartmentDTO>();

           foreach (var d in dic)

           {

               departmentStatistcs.Add

                   (

                       new StatisticDepartmentDTO()

                       {

                           DepartmentName = d.Key,

                           Employees = d.Value

                       }

                   );

           }

           return departmentStatistcs;

       }

       

   }

Приложение Д

Объекты передачи данных (DTO)

  1.  DTO – класс для статистики по рабочим местам

public class NodeStatistcsDTO

   {

       [Required]

       public string DisplayName { get; set; }

       [Required]

       public int Total { get; set; }

       [Required]

       public Guid NodeId { get; set; }

       [Required]

       public int Employees { get; set; }

       [Required]

       public int Free { get; set; }

       [Required]

       public float Index { get; set; }

       [Required]

       public List<StatisticDepartmentDTO> DepartmentStatistcs { get; set; }

       [Required]

       public List<NodeStatistcsDTO> InnerStatistics { get; set; }

   }

  1.  DTO – класс для статистики по департаментам

   public class StatisticDepartmentDTO

   {

       public string DepartmentName { get; set; }

       public int Employees { get; set; }

   }

Приложение Е

Уровень представления (Presentation Layer)

Код контроллера (Controller)

public class StatisticsController : ApiController

   {

       private readonly IRoomsService _roomsService;

       public StatisticsController(IRoomsService roomsService)

       {

           _roomsService = roomsService;

       }

       public List<NodeStatistcsDTO> Get()

       {

           return new List<NodeStatistcsDTO>();

       }

       public NodeStatistcsDTO Get(Guid nodeId)

       {

           return _roomsService.GetStatistics(nodeId);

       }

       

       public void Post(string value)

       {

       }

       

       public void Put(int id, string value)

       {

       }

      

       public void Delete(int id)

       {

       }

   }

}

26

Изм.

Лист

№ докум.

Подпись

Дата

Лист

ДП-ДПИ-НГТУ-230201-05-13 ПЗ

 


 

А также другие работы, которые могут Вас заинтересовать

4130. Дослідження кореляційної та автокореляційної функції прийнятого сигналу 206.5 KB
  Дослідження кореляційної та автокореляційної функції прийнятого сигналу Мета роботи: 1) дослідити основні характеристики кореляційної функції 2) побудувати графіки функцій формування відео- та радіоімпульсу 3) побудувати графіки адитивної суміші д...
4131. Изучение алгоритма цифровой сверки 98 KB
  Изучение алгоритма цифровой сверки Целью работы является изучение алгоритмов цифровой свертки изучение функций MatLab, позволяющих автоматизировать процесс вычисления цифровой свертки получение навыков расчета низкочастотных фильтров с использо...
4132. Визначення концентрації вільних носіїв заряду в напівпровіднику 112.5 KB
  Визначення концентрації вільних носіїв заряду в напівпровіднику Мета роботи. Визначити питому електропровідність та концентрацію вільних носіїв заряду в напівпровідниковому монокристалі з електронною провідністю. Теоретичні відомості. В напівпров...
4133. Вивчення вільних затухаючих коливань математичного маятника 138.5 KB
  Вивчення вільних затухаючих коливань математичного маятника Мета роботи. Вивчити затухаючі коливання математичного маятника i визначити характеристики затухаючих коливань (період затухаючих коливань, логарифмічний декремент затухання, коефіцієнт зат...
4134. Типи зображень по глибині кольору 532 KB
  Типи зображень по глибині кольору Установка глибини кольору необхідна на початку роботи із зображенням і визначає його тип і кількість можливих відтінків тони (кольори). Розглянемо можливості перенесення кольорів і поняття глибини кольору, використо...
4135. Спусковое регенеративное устройство триггер 502 KB
  Триггеры Триггер — это спусковое регенеративное устройство с двумя или более устойчивыми состояниями, переключаемыми в соответствии с сигналом, поступающим на информационные входы. Существует большое количество разновидностей триггеров, к...
4136. Шифраторы и дешифраторы 375.5 KB
  Шифраторы и дешифраторы Шифратор – специфический преобразователь кодов, - устройство, обеспечивающее выдачу определенного кода в ответ на возбуждение одного из входов. Шифраторы реализуют преобразование унитарного кода (другое название – к...
4137. Дослідження роботи служби www 107.91 KB
  Дослідження роботи служби www 1.Мета роботи Дослідити різноманітні види пошуку та пошукових систем, які використовуються в Internet Хід роботи Досить вказати пошуковий запит і клацнути мишкою на відповідній кнопці, на екрані буде відобра...
4138. Санітарний паспорт кабінету інформатики та інформаційно-комунікаційних технологій 43.5 KB
  Санітарний паспорт кабінету інформатики та інформаційно-комунікаційних технологій Паспортна частина Адреса: Смільчинецький навчально-виховний комплекс Черкаська обл. Лисянський район, с.Смільченці Побудована: по типовому проекту Розташ...