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

Текст из файла (страница 2)

Рисунок 2.5 – Часть схемы данных

Всего в нашем приложении используется примерно 120 таблиц.

Рассмотрим несколько самых важных из них

Таблица Person (таблица 2.1) включает в себя информацию о сотрудниках, по которым будет строиться график.

Таблица 2.1 – Person – сотрудники

Таблица Work (таблица 2.2) – это рабочие данные сотрудника. В ней отображаются группа сотрудников, а так же дополнительная информация о рабочем состоянии сотрудника. Таблица Work соединена с таблицей Person по полю person_id.

Таблица 2.2 – Work – график работы

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

Таблица 2.3 – KDPD

2.4 Разработка диаграммы компонентов

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

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

• спецификация общей структуры исходного кода системы;

• спецификация исполнимого варианта системы.

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

Часть диаграммы компонентов для приложения по работе с персоналом представлена на рисунке 2.6.

Рисунок 2.6 – Диаграмма компонентов

На представленной диаграмме видны все компоненты. Они разделены на три взаимозависимых блока согласно шаблону проектирования дипломной работы: Models (модели), Controllers (контроллеры), Views (представления). Блок Models содержит в себе классы, описывающие модель базы данных. Блок Controllers содержит в себе классы, которые обеспечивают связь между системой и пользователем. Блок Views разделен на разделы и подразделы, которые содержат в себе элементы отображения данных для пользователей то есть элементы пользовательского интерфейса.

2.5 Разработка диаграммы развертывания

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

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

Рисунок 2.7 – Диаграмма развертывания

База данных, необходимая для хранения и обработки данных приложения, размещаются на сервере. Сотрудники находятся в одной сети, поэтому имеют постоянный доступ к приложению. Администратор так же находится в этой сети и имеет полный доступ к приложению.

2.6 Разработка интерфейса приложения

Основными элементами приложения по управлению персоналом будут следующие:

• меню в виде кнопок, находящееся в верхней части страницы;

• данные о сотруднике в центре.

Меню содержит в себе несколько пунктов:

• кнопка файл;

• кнопка с разными реестрами;

• кнопка с разными отчетами;

• кнопка со справочниками;

• различные фильтры сотрудников;

• информация о текущем пользователе;

• вкладки с формами.

Схематичный вид приложения, выполненный с помощью конструктора Visual Studio, представлен на рисунке 2.8.

Рисунок 2.8 – Схематичная структура меню приложения.

2.5 Основные этапы создания приложения

Разработка проекта на основе построенных моделей состоит из следующих этапов:

• написание модели базы данных;

• генерация базы данных на основе написанной модели в СУБД;

• создание и редактирование элементов, обеспечивающих связь между пользователем и системой (контроллеров);

• создание и редактирование элементов пользовательского интерфейса (представлений);

• отладка и тестирование приложения.

3 Практическая часть

3.1 Выбор программных средств

При разработке любого проекта необходимо определиться с выбором программных средств, которые будут использоваться в процессе работы. Разработка приложения по работе с персоналом осуществляется на базе языков XAML и C# с использованием СУБД MS SQL Server 2012. Создание приложения на базе выбранных языков осуществляется в среде разработки Visual Studio 2012.

3.1.1 Entity Framework

Платформа Entity Framework представляет собой набор технологий ADO.NET, обеспечивающих разработку приложений, связанных с обработкой данных. Архитекторам и разработчикам приложений, ориентированных на обработку данных, приходится учитывать необходимость достижения двух совершенно различных целей. Они должны моделировать сущности, связи и логику решаемых бизнес–задач, а также работать с ядрами СУБД, используемыми для сохранения и получения данных. Данные могут распределяться по нескольким системам хранения данных, в каждой из которых применяются свои протоколы, но даже в приложениях, работающих с одной системой хранения данных, необходимо поддерживать баланс между требованиями системы хранения данных и требованиями написания эффективного и удобного для обслуживания кода приложения.

Entity Framework позволяет работать с данными в форме специфических для домена объектов и свойств, таких как клиенты и их адреса, без необходимости обращаться к базовым таблицам и столбцам базы данных, где хранятся эти данные. Entity Framework дает разработчикам возможность работать с данными на более высоком уровне абстракции, создавать и сопровождать приложения, ориентированные на данные, используя меньше кода, чем в традиционных приложениях. Поскольку Entity Framework является компонентом .NET Framework, приложения Entity Framework могут работать на любом компьютере, где установлена платформа .NET Framework, начиная с версии 3.5 с пакетом обновления 1 (SP1).

В следующих секциях этого раздела представлены более подробные сведения о Entity Framework:

• применение моделей на практике;

• сопоставление объектов и данных;

• доступ к данным сущностей и их изменение;

• поставщики данных;

• средства работы с моделью EDM;

• получение дополнительных сведений;

• применение моделей на практике.

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

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

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

Характеристики

Список файлов ВКР