Разработка автоматизированного приложения "График рабочего дня"

Кроме того, в состав IBProvider Professional Edition входит C++ библиотека, которая предоставляет самый быстрый способ работы с OLE DB провайдерами из Visual C++ 2005-2008, а так же из C++ Builder.

1.4.3 Утилиты администрирования Firebird

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

FlameRobin- поддерживает Firebird. Кросс-платформенная архитектура. Есть редактор SQL, DDL, управление пользователями. Лицензия: open source, распространяется бесплатно.

IBExpert- Поддерживает Firebird, Interbase, Yaffil. Редакторы DDL и DML. Визуальный построитель запросов. Автозавершение кода, Metadata Extractor, а так же множество других возможностей. Лицензия: Бесплатный для exUSSR, для остальных: от 179 евро.

IB/FB Development Studio- Визуальный дизайнер баз данных, встроенный MERGE, scheduler, Code auto completion, анализатор запросов, монитор производительности. Лицензия: Бесплатно для России, для остальных: от 149 евро.

Blaze Top- Инструмент разработчика и администратора баз данных. Поддерживает Firebird и Interbase. Лицензия: Бесплатно для России, для остальных: от 129 евро.

Database Workbench- поддерживает несколько серверов баз данных, среди которых есть Firebird и Interbase. Отладка хранимых процедур, анализ планов, встроенные средства переноса данных и метаданных. Лицензируется отдельно на Interbase и отдельно на Firebird. 171$ за каждую копию (Interbase или Firebird).

1.4.4 Обоснование выбора среды разработки приложения

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

Отношения подчиненности между таблицами баз аданных (БД) создаются путем определения первичных ключей у родительских и внешних ключей у дочерних таблиц.

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

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

В составе записи БД могут определяться BLOB-поля (Binary Large Object --большой двоичный объект), предназначенные для хранения больших объемов данных в виде последовательности байтов. Таким образом могут храниться текстовые и графические документы, файлы мультимедиа, звуковые файлы и т. д. Интерпретация BLOB-поля выполняется в приложении, однако разработчик может определить так называемые BLOB-фильтры для автоматического преобразования содержимого blob-поля к другому виду.

InterBase дает возможность использовать функции, определяемые пользователем (User Defined Function, UDF), в которых могут реализовываться функциональности, отсутствующие в стандартных встроенных функциях InterBase (вычисление максимума, минимума, среднего значения, преобразование типов и приведение букв к заглавным). Например, в UDF можно реализовать извлечение из значения даты номера дня, года; определение длины символьного значения; усечение пробелов; разные математические алгоритмы и т. п. Функция пишется на любом алгоритмическом языке, позволяющем разрабатывать DLL (библиотеки динамического вызова), например, на Object Pascal.

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

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

InterBase был разработан в начале 80-х годов группой разработчиков из американской корпорации DEC. В дальнейшем разработка данного продукта велась независимыми компаниями InterBase Software и впоследствии слившейся с ней Ashton-Tate. Borland приобрела права на InterBase у Ashton-Tate после слияния с нею.

InterBase активно используется в государственном и военном секторах США. Однако, интерес к этому серверу возрос только в последнее время в связи с включением его локальной (а начиная с Delphi 3 и 4-пользовательской) версии в состав Delphi Client/Server Suite и Delphi Enterprise. Внимание разработчиков БД InterBase привлек, во-первых, потому, что это «родной» продукт Borland (а средства разработки приложений этой компании давно зарекомендовали себя с положительной стороны), во-вторых, потому, что InterBase весьма прост в установке, настройке и администрировании по сравнению с другими SQL-серверами, и в-третьих, потому, что он обладает прекрасными функциональными возможностями. Однако Borland развивает только платную версию своего сервера InterBase, а помимо него есть и менее приметные, но не менее востребованные решения, например PostgreSQL или Sybase ASA. Но настоящим «серым кардиналом» можно назвать, пожалуй, лишь одну-- FireBird (в переводе с англ. «жар-птица»).

Многим программистам знакома аббревиатура IB/FB. Так четырьмя буквами обозначаются целых две системы управления базами данных -- InterBase и FireBird. Обе системы нетребовательны к ресурсам, платформонезависимы, просты в использовании и относительно легки в освоении. Очень часто клиентские программные утилиты поддерживают эти две СУБД одновременно.

Firebird - это мощная, компактная реляционная система управления базами данных (РСУБД) с архитектурой клиент-сервер. Она может выполняться на разнообразных серверных и клиентских платформах, включая Windows, Linux и на некоторых других платформах UNIX, включая FreeBSD и Mac OS X. Это РСУБД промышленного применения, чьи возможности имеют высокий уровень соответствия стандартам SQL, при этом она реализует некоторые мощные расширения языка процедурного программирования конкретного производителя.

Этот сервер может практически всё, что обычно требуется для приложений. Иными словами - сервер должен как минимум поддерживать ANSI SQL-92, транзакции, хранимые процедуры и триггеры, развитую систему разграничения прав доступа, архивирование баз данных, быть надёжным и простым в администрировании, не иметь серьёзных ограничений на размер базы, количество таблиц, полей, индексов и т.п.

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

В дополнение к этому всему, как результат изучения, хочу отметить:

- Триггеры могут быть Before и After, причем в неограниченном, практически, количестве (срабатывают в последовательности, которую легко указать при создании триггера). В отличие от MS SQL, срабатывают они отдельно для каждой записи, а не единожды для всего кортежа.

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

- Для создания уникальных идентификаторов предусмотрены генераторы. Это отдельные объекты, не привязанные к конкретным полям или таблицам, что позволяет с лёгкостью создавать идентификаторы, уникальные в любом контексте.

- Кроме хранимых процедур, существуют ещё UDF, оформленные как внешние dll. Стандартный набор UDF и готовые их библиотеки сторонних разработчиков включают в себя практически все функции, какие только могут понадобиться.

- Есть контроль ссылочной целостности.

- Есть полноценная поддержка кириллицы.

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

2. Проектная часть

2.1 Характеристика средств проектирования

2.1.1 Case-средства

Проектирование на основе CASE-технологии (Computer-Aided Software / System Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимосвязанных средств автоматизации. CASE предоставляет системным аналитикам, проектировщикам и программистам инструментарий для автоматизации проектирования и разработки ПО.

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

CASE-технологии широко применяются для многих типов систем ПО, но чаще всего они используются в следующих областях:

- Разработка делового и коммерческого ПО. Широкое применение CASE-технологий обусловлено массовостью этой прикладной области, в которой CASE применяется не только для разработки ПО, но и для создания моделей систем, помогающих коммерческим структурам решать задачи стратегического планирования, управления финансами, определения политики фирм, обучение персонала (этот направление получил собственное название - бизнес-анализ).

- Создание системного и управляющего ПО. Использование CASE-технологии в этой отрасли вызвано высокой сложностью данного вида работ и необходимостью повышения их производительности.

Помимо автоматизации структурных методологий и возможности применения современных методов системной и программной инженерии, CASE-средства имеют следующие преимущества:

• повышают качество создаваемого ПО благодаря использованию средств автоматического контроля, в частности контроля проекта;

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

• ускоряют процесс проектирования и разработки;

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

• поддерживают развитие и сопровождение разработки;

• обеспечивают технологии повторного использования компонентов разработки.

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

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

2.1.2 Методология проектирования IDEF0

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

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

В стандарте IDEF0 (рисунок 12) c помощью входа показывают объекты - информационные и материальные потоки данных, которые преобразуются в внутри процесса. С помощью управления показывают объекты - материальные и информационные потоки, которые не преобразуются в процессе, но необходимы для его выполнения. С помощью механизмов показываются средства, при помощи которых бизнес-процесс реализуется: технические средства, люди, информационные системы и т.д. Выход бизнес-процесса, описанного в стандарте IDEF0 полностью соответствует по смыслу выходу процесса, описанному при помощи DFD-схемы.

Рисунок 12 - Функциональный блок модели

Четыре типа объектов, применяемых для описания входов и выходов в стандарте IDEF0, в английском варианте образуют сокращение ICOM и на схеме IDEF0 размещаются в строго отведенных местах относительно работ, которые называются функциональными блоками (таблица 2).

Таблица 2 - Название и размещение входов и выходов в стандарте IDEF0 относительно функционального блока.

Название объектов	Размещение
Русский вариант	Английский вариант
Вход	Input	Подходит к работе слева
Управление	Control	Подходит к работе сверху
Выход	Output	Исходит от работы справа
Механизм	Mechanism	Подходит к рабете снизу

Стандарт IDEF0 получил большое распространение в США и активно используется в России. Ввиду того, что в стандарте IDEF0 появилась дополнительная аналитика по сравнению с классическим стандартом DFD, схемы бизнес-процессов, получаемые при описании в стандарте IDEF0 выглядят более сложными с точки зрения менеджеров компании, в виду ограниченного наличия у них свободного времени. Данная сложность часто приводит к тому, что менеджеры, особенно высшего уровня, которые должны принимать активное участие в проекте по описанию и оптимизации деятельности компании, "отказываются" от работы с IDEF0. В данном случае IDEF0 - является излишне информационно насыщенным и сложным стандартом.

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

Практика показала, что стандарт IDEF0 целесообразно использовать в проектах по описанию и оптимизации малых бизнес-процессов, в небольших проектах в которых больше участвуют и принимают решения непосредственно разработчики и специалисты предметных областей, а руководители высшего уровня привлекаются для принятия решений относительно редко.

2.2 Функционально-ориентированное программирование приложения

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

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

Построение модели DFD [28] начинается с определения внешних сущностей, источников и приемников данных. А так же, с данных которыми они обмениваются через нашу систему (рисунок 13). В итоге, у нас есть все необходимое, чтобы построить контекстную диаграмму, которая представляет нашу систему как один большой черный ящик.



Рисунок 13 - DFD диаграмма потоков данных

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

Пользователь на диаграмме представляет собой любого работника организации, в обязанности которого входит планирование своего рабочего дня и предоставление какого-либо отчёта руководителю о выполненных им мероприятиях за день/неделю/месяц.

Руководитель же имеет полномочия выдавать сотрудникам задания, распоряжния, и, требовать их выполнения. Для автоматизация и упрощения этих процессов и служит приложение «График раочего дня» в которое пользователь и руководитель заносят свою информацию, а приложение в зависимости от даты, срочности и степени важности задания определяет момент и назначает его на выполнение пользователю.

2.3 Структурно-функциональная модель приложения

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

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

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

Рисунок 14 - Структурно-функциональная модель приложения ГРД

Модуль «Расписание» должен выполнять сбор, сортировку и формирование общего списка мероприятий по конкретному сотруднику (текущему пользователю системы или заданному по ФИО) и выводить всю собранную информацию в единую форму по выбранной пользователем дате.

Модуль «Отчёты» служит для формирования, заполнения и вывода на принтер печатных форм в соответствии с правилами документооборота, установленными в организации.

2.4 Функциональная модель IDEF0

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

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

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

На вход приложения подаются данные о мероприятиях с заданиями для пользователя (сотрудника организации) для формирования мероприятий на текущий день и планирования мероприятий на будущее время. На выходе приложение формирует список мероприятий на текущий день предназначенного для пользователя, а также отчёты, предназначенные для сдачи руководителю предприятия. Управляющей информацией является положение о работе пользователей с программой ГРД и руководство пользователя по программе ГРД. Механизмами процесса являются - пользователь работающий с программой и компьютер, проводящий вычисления и обработку информации.

Декомпозиция процессов внутри приложения представлена на рис. 15.

Рисунок 15 - Контекстная диаграмма модели приложения.

Рисунок 16 - Диаграмма процессов обработки информации в приложении

Описание диаграммы:

Номер процесса: А1.1. Имя: Работа с модулем «Задачи». Описание: Создание, внесение и редактирование мероприятий классифицирующихся как задачи (цели) для сотрудника. Дополнение: Основным результатом работы будет являться сформированный общий список задач, соотнесённый с датой выполнения.

Номер процесса: А1.2. Имя: Работа с модулем «Заявки». Описание: Создание, внесение и редактирование мероприятий классифицирующихся как заявки для сотрудника. Дополнение: Основным результатом работы будет являться сформированный общий список заявок, соотнесённый с датой их выполнения.

Номер процесса: А1.3. Имя: Работа с модулем «Регламенты». Описание: Создание, внесение и редактирование мероприятий классифицирующихся как регламенты для сотрудника. Дополнение: Основным результатом работы будет являться сформированный общий список регламентов, соотнесённый с датой их выполнения.

Номер процесса: А1.4. Имя: Работа с модулем «События». Описание: Создание, внесение и редактирование мероприятий классифицирующихся как события для сотрудника. Дополнение: Основным результатом работы будет являться сформированный общий список событий, соотнесённый с датой их выполнения и типом события.

Номер процесса: А1.5. Имя: Формирование личного расписания на рабочий день. Описание: В модуле происходит выборка по заданной дате всех мероприятий, запрос состояния каждого мероприятия и вывод их в единую форму для наглядного отображения общего плана работ на день. Дополнение: Основным результатом работы будет являться сформированный общий список мероприятий, соотнесённый с датой их выполнения и типом события на конкретную дату.

Номер процесса: А1.6. Имя: Отчётность. Описание: Модуль служит для формирования и обработки печатных форм отчёта по списку выполненных и не выполненных мероприятий за день. Дополнение: Основным результатом работы будет являться сформированная и сгруппированная печатная форма, подготовленная для вывода на принтер.

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

Рисунок 17 - Диаграмма работы происходящей внутри модуля приложения

Описание диаграммы: Номер процесса: А2.1. Имя: Создание события. Описание: Пользователь должен занести мероприятие в соответствии с выбранным типом и заполнить необходимые реквизиты формы создания события. Дополнение: Пользователь, занося информацию, руководствуется правилами работы с программой, описанными в руководстве пользователя.

Номер процесса: А2.2. Имя: Редактирование события. Описание: Проверка введенных данных на корректность, некорректные данные подлежат редактированию или повторному вводу. Дополнение: Пользователь занося информацию руководствуется правилами работы с программой, описанными в руководстве пользователя.

Номер процесса: А2.3. Имя: Удаление (отмена) события. Описание: Отмена регистрации события и удаление его из базы данных. Дополнение: Пользователь в процессе руководствуется правилами работы с программой, описанными в руководстве пользователя.

Номер процесса: А2.4. Имя: Флаг состояния события. Описание: При создании каждого мероприятия ему автоматически изначально должен быть присвоен флаг «Ожидание». Дополнение: В зависимости от текущей даты и состояния события (отметки пользователя) каждое мероприятие может иметь одно из нескольких состояний (ожидание, перенос, выполнено, не выполнено, отменено и т.п.). Пользователь в процессе руководствуется правилами работы с программой, описанными в руководстве пользователя.

Номер процесса: А2.5. Имя: Формирование списка событий. Описание: На основе всех полученных данных должен быть сформирован в таблицу единый список событий и занесён в базу данных приложения. Дополнение: Список формируется автоматически на основе заложенного алгоритма работы приложения в соответствии с действующим регламентом ведения ГРД.

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

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

2.5 Разработка информационного обеспечения системы

Этапы проектирования базы данных:

- определение цели создания базы данных;

- определение таблиц, которые должна содержать база данных;

- определение необходимых в таблице полей;

- задание индивидуального значения каждому полю;

- определение связей между таблицами;

- обновление структуры базы данных;

- добавление данных и создание других объектов базы данных;

- использование средств анализа в IBExpert;

- определение соответствию цели создания базы данных.

На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать. То есть нужно определить основные темы таблиц базы данных и информацию, которую будут содержать поля таблиц.

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

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

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

- информация в таблице не должна дублироваться;

- не должно быть повторений и между таблицами.

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

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

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

- каждое поле должно быть связано с темой таблицы;

- не рекомендуется включать в таблицу данные, которые являются результатом выражения;

- в таблице должна присутствовать вся необходимая информация;

- информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «Имя»).

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

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

- желательно изучить связи между таблицами в уже существующей базе данных;

- обновление структуры базы данных

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

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

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

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

В процессе реализации задачи при разработке структуры для хранения данных, первым объектом выступают информация о пользователе (работнике организации) и данные о занесённых им мероприятиях. В нашем случае БД будет состоять из 5 таблиц.

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

Таблица 3 - Пользователи (USERS_INDEX)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникальный идентификатор пользователя.
CAPTION	Строковый	VARCHAR 1000	Логин пользователя
USER_PASS	Строковый	VARCHAR 1000	Пароль пользователя
FIRSTNAME	Строковый	VARCHAR 1024	Имя пользователя
LASTNAME	Строковый	VARCHAR 1024	Фамилия пользователя
MIDDLENAME	Строковый	VARCHAR 1024	Отчество пользователя
BIRTHDAY	Дата	DATE	Дата дня рождения пользователя.

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

Таблица 4 - Пользователи (USERS_OPTIONS)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникальный идентификатор.
USER_ID	Целый	INTEGER	Уникальный идентификатор пользователя
VALUE_GROUP	Целый	INTEGER	Идентификатор группы
VALUE_DATA	Целый	INTEGER	Идентификатор уровня доступа

Таблица PROJECT_INDEX будет создана для хранения информации о задачах (таблица 5).

Таблица 5 - Задачи (PROJECT_INDEX)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникальный идентификатор задачи
OWNER_ID	Целый	INTEGER	Идентификатор создателя задачи
CAPTION	Строковый	VARCHAR(1024)	Текст задачи
PROJECT_TYPE	Целый	INTEGER	Идентификатор типа задачи
PROJECT_DATE	Целый	INTEGER	Дата исполнения задачи
EXECUTOR	Целый	INTEGER	Идентификатор пользователя, назначенного исполнителем
PRIORITY	Целый	INTEGER	Статус важности
COMPLETE	Целый	INTEGER	Отметка о выполнении
STATUS	Целый	INTEGER	Статут задачи
COMMENTARY	Строковый	VARCHAR(1024)	Комментарий

В таблице STATES_INDEX будут храниться все дополнительные нужные сведения о сотрудниках организации - с указанием контактных данных (должность, место (отдел работы), телефон внутренний и мобильный, адреса). Описание STATES_INDEX представлено в таблице 6.

Таблица 6 -Личные данные (STATES_INDEX)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникальный идентификатор (первичный ключ)
GROUP_ID	Целый	INTEGER	Уникальный идентификатор группы
CAPTION	Строковый	VARCHAR(1024)	Полное название должности сотрудника
SHORTCUT	Строковый	VARCHAR(255)	Сокращенное название должности сотрудника
WORKPLACE	Строковый	VARCHAR(1024)	Номер кабинета абинет или другое место работы
PHONE	Строковый	VARCHAR(255)	Внутренний номер телефона
MOBILE	Строковый	VARCHAR(255)	Мобильный номер телефона
MAIL	Строковый	VARCHAR(1024)	Адрес электронной почты
ALLOW_MULTY_USERS	Целый	INTEGER	Флаг, разрешающий одновременно несколько подключений под одним. логином
WORK_KIND	Целый	INTEGER	Образование (разряд)
WORK_TARGET	Целый	INTEGER	Рабочие цели

Третья таблица SHEDULES_INDEX будет содержать сведения о запланированных мероприятиях и делах, ометки о выполнении, статусе записи и комментариях к ней. Описание SHEDULES_INDEX представлено в таблице 7.

Таблица 7 -Запланированные мероприятия(SHEDULES_INDEX)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникальный идентификатор мероприятия (первичный ключ)
USER_ID	Целый	INTEGER	Идентификатор ответственного пользователя
OWNER_ID	Целый	INTEGER	Идентификатор создателя мероприятия
CAPTION	Целый	INTEGER	Текст запланированного мероприятия
DATE_VALUE	Строковый	VARCHAR 1000	Дата занесения мероприятия
TIME_START	Время	TIME	Время начала
TIME_FINISH	Время	TIME	Время окончания
RATING	Малое целое	SMALLINT	Важность
STATUS	Малое целое	SMALLINT	Статус мероприятия
TIME_SUSPEND	Дата	DATE	Время окончания
COMMENTARY	Строковый	VARCHAR 1000	Комментарий
PRIORITY	Целый	INTEGER	Флаг оповещения о начале мероприятия.
SUSPEND_REASON	Целый	INTEGER	Код, обозначающий причину переноса.
ALL_DAY	Целый	INTEGER	Флаг указывающий на ежедневное выполнение мероприятия
COMPLETE_LEVEL	Целый	INTEGER	Процент завершения
SUSPEND_ID	Целый	INTEGER	ID отложенного мероприятия

Таблица EVENTS_INDEX будет содержать в себе все события с разделением их по типу. Таблица 8 - Запланированные задачи (EVENTS_INDEX) будет содержать в себе всю информацию относящуюся к событиям и работе с ними.

Таблица 8 - Запланированные мероприятия(SHEDULES_INDEX)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникальный идентификатор события
USER_ID	Целый	INTEGER	Идентификатор польщователя
CAPTION	Строковый	VARCHAR (1000)	Текст события
EVENT_DATE	Дата	DATE	Дата начала события
TIME_START	Время	TIME	Время начала
TIME_FINISH	Время	TIME	Время завершения
TIME_SUSPEND	Дата	DATE	Дата окончания события
EVENT_TYPE	Малое целое	SMALLINT	Тип события
STATUS	Малое целое	SMALLINT	Идентификатор состояние события
RATING	Малое целое	SMALLINT
PRIORITY	Целый	INTEGER	Важность события
OPTION_REMIND	Малое целое	SMALLINT	Флаг включения уведомления
OPTION_POPUP	Малое целое	SMALLINT	Флаг включения уведомления всплывающим сообщением
OPTION_REFERENCE	Малое целое	SMALLINT	Опция указывающая на отображение события в расписании
COMMENTARY	Строковый	VARCHAR (1000)	Комментарий
SUSPEND_REASON	Целый	INTEGER	Метка об причине отмены
COMPLETE_LEVEL	Целый	INTEGER	Прогресс завершения

Таблица TASKS_INDEX выполняет практическу ту же самую роль, что и SHEDULES_INDEX, с той лишь разницей, что оптимизирована для потребностей свойственным задачам, а не разовым заметкам или заданиям на день. Описание TASKS_INDEX представлено в таблице9.

Таблица 9 - Запланированные задачи (TASKS_INDEX)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникальный идентификатор записи
CAPTION	Строковый	VARCHAR (1024)	Полный текст порученного мероприятия
TASK_TYPE	Целый	INTEGER	Тип задачи (на день, на неделю, на месяц)
SENDER	Целый	INTEGER	ID поручителя (ФИО пользователя)
EXECUTOR	Целый	INTEGER	ID исполнителя (ФИО пользователя)
CREATION_DATE	Дата	DATE	Дата создания поручения
DATE_VALUE	Дата	DATE	Крайняя дата выполнения поручения
STATUS	Целый	INTEGER	Статус задачи
SENDER_STATUS	Целый	INTEGER	Отметка о выполненении поручителем
EXECUTOR_STATUS	Целый	INTEGER	Отметка о выполнении исполнителем
RATING	Целый	INTEGER	Оценка полноты выполненной работы
COMMENTARY	Строковый	VARCHAR (1024)	Комментарий

Для записи регламентных мероприятий будет заведена своя таблица. Регламенты отличаются от обычных задач периодичностью повторения. Достаточно будет лишь один раз записать задачу и выбрать с какой периодичностью она должна повторяться в таблице расписания дня. Описание REGLAMENT_INDEX представлено в таблице10.

Таблица 10 - Регламенты(REGLAMENT_INDEX)

Название поля	Тип данных	Тип Firebird	Описание поля
ID	Целый	INTEGER	Уникакльный идентификатор записи регламента.
USER_ID	Целый	INTEGER	ФИО пользователя
CAPTION	Строковый	VARCHAR (1024)	Текст регламентного задания
ACTION_ALWAYS	Целый	INTEGER	Флаг «Без временных рамок»
ACTION_START	Дата	DATE	Дата начала
ACTION_FINISH	Дата	DATE	Дата окончания
ALL_DAY	Целый	INTEGER	Флаг «Без срока действия»
TIME_START	Время	TIME	Время начала
TIME_FINISH	Время	TIME	Время окончания
PRIORITY	Целый	INTEGER	Степень важности(1,2,3 - Обычная, Важно, Очень важно)
REGLAMENT_ TYPE	Целый	INTEGER	Тип регламента (0,1,2 - Еженедельный, Ежегодный, Последний в месяце)
FREQUENCY	Целый	INTEGER	Частота повторения рагламента (дни)
STATE	Целый	INTEGER	Флаг «Должностной регламент»
STATUS	Целый	INTEGER	Статус выполнения регламента

Визуальные средства разработки запросов обеспечивают удобное представление решаемой задачи, помогают определить связи и условия запроса. Но в Firebird нет как таковых визуальных средств разработки запросов. Однако можно обращаться с Firebird при помощи ibExpert. Это гибкий и мощный инструмент. В нем присутствует возможность разрабатывать структуру самой БД, сохранять и выполнять скрипты на SQL, использовать множество встоенных утилит, облегчающих работу, как разработчика, так и администратора.

Используя ibExpert в меню Tools->Query Builder, нужно перетащить требуемые таблицы, после чего, станет возможно определить связи между ними (рисунок 18) и отметить поля, необходимые для вывода.

Центральной (главной таблицей) будет являтся таблица USERS_INDEX, содержащая уникальный идентификатор пользователя, и другую основную информацию (ФИО, дата рождения, пароль). Данные этой таблицы можно назвать совокупностью ключей для других таблиц. Ключи связывают каждую строку таблицы данных с ассоциированной строкой в дочерних таблицах.

Рисунок 18 - Схема взаимосвязи таблиц

2.6 Руководство пользователя приложения

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

2.6.1 Обзор интерфейса программы

Интерфейс администратора представлен на рисунке 19.

Рисунок 19 - Интерфейс приложения.

Основное окно программы разделено на 4 главные области. В левом верхнем углу размещен календарь, служащий для перехода по дням и выбора нужной даты для работы с расписанием этого дня (рисунок 20).

Рисунок 20 - Календарь выбора дат

Левый блок интерфейса информационный (рисунок 21) и служит для развёрнутого представления о выбранном пункте в таблице мероприятий.

Правый верхний блок (рисунок 22) вмещает в себя показ запланированных задач на текущую дату. В случае если ни одной задачи нет в базе - блок будет скрыт.

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

Рисунок 21 - Информационный блок

Рисунок 22 - Блок вывода задач

Рисунок 23 - Расписание на рабочий день

Главное меню (рисунок 24) дублирует кнопки управления мероприятиями и содержит ряд дополнительных пунктов которые становятся доступны, только если у пользователя при регистрации в базе будет установлен флаг администратора или руководителя подразделения. Так, например, пункты меню «События» и «Пользователи» будут недоступны у рядового пользователя.

Рисунок 24 - Главное меню приложения.

Административный интерфейс приложения так же позволяет добавлять, редактировать или удалять пользователя из программы (рис. 25).

Рисунок 25 - Управление пользователями

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

2.6.2 Работа с приложением

Вход в программу осуществляется посредством двойного клика по ярлыку на рабочем столе (рисунок 26).

Рисунок 26 - Ярлык запуска приложения

Процедура регистрации в программе ГРД основана на проверке имени пользователя операционной системы Windows, и происходит автоматически поскольку на этапе планирования было решено отказаться от дополнительного запроса логина и пароля в пользу удобства дальнейшей работы с программой. Основой данного решения послужило то, что в локальной сети организации создана доменная структура предприятия, в которой каждый пользователь имеет уникальное имя и логин под которым он может работать с любого компьютера на предприятии. Программа при запуске проверяет системную переменную USERNAME текущего пользователя и на основе её значения формирует запросы к серверу БД на вывод информации.

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

Рисунок 27 - Пример списка мероприятий

Что бы добавить новое мероприятие - необходимо:

- Выбрать месяц и дату на которые будет заноситься запланированное мероприятие,

- Нажать кнопку «Добавить запись»,

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

- Нажать кнопку «Новое мероприятие».

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

2.6.3 Управление пользователями

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

Добавление или удаление сотрудников осуществляется через дополнительную форму, вызываемую нажатием кнопки «Управление сотрудниками». Все существующие должности и сотрудники будут представлены в виде многоуровневого списка в соответствии с отделом в котором каждый из них работает, в левой части рабочей области программы. (рисунок 28)

Перед добавлением сотрудника следует создать (если еще не существует) подразделение (отдел) к которому относится добавляемый сотрудник. Таким образом в дальнейшем станет возможным назначить добавляемого сотрудника руководителем этого подразделения и выбрать для него подчинённых. (Рисунок 29)



Рисунок 28 - Список сотрудников

Рисунок 29 - Управление пользователем

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



Рисунок 30 - Регистрация нового пользователя

2.6.4 Работа со списком мероприятий

Работа со списком мероприятий осуществляется посредством выделения нужной строки и вызова контекстного меню правой кнопкой мыши (рисунок 31).

Рисунок 31 - Контекстное меню

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

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

Пункт «Не выполнено» вызовет форму для указания причины о том, что помешало выполнению запланированного мероприятия.

После отметки о невыполнении строка изменит статус на «Не вып.» и окрасится в красный цвет.

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

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

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

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

Все мероприятия в ГРД можно разделить на 5 групп:

а) долгосрочные (задачи) - мероприятия, для выполнения которых требуется несколько дней (от 3-х и более). Мероприятия данной группы предусматривают наличие краткосрочных мероприятий (заданий);

б) краткосрочные - мероприятия (отдельные задания), для выполнения которых требуется от 1 до 2-х дней, Данная группа тесно связана с первой, так как детализирует и раскрывает суть работы по долгосрочным мероприятиям;

Рисунок 32 - Перенесенные мероприятия

в) заявки - разовые мероприятия, которые выполняются сотрудником в течение дня по специфике работы;

г) регламент - мероприятие, которое несет в большей степени функцию напоминания о выполнении той или иной работы (например: проверка электронной почты, заполнение ГРД).

д) события - разовое мероприятие обязательное для выполнения, которое задаётся исполнителю по оперативным, текущим вопросам руководителем организации единолично или руководителем подразделения.

2.6.5 Работа с модулем «Задачи»

Для того что бы создать задачу на месяц пользователю необходимо перейти на вкладку «Задачи» главного интерфейса программы. Далее следует нажать кнопку «Создать задачу», которая вызовет форму для добавления. В поле «Наименование» необходимо кратко записать суть поставленной задачи и назначить в поле «Ответственный» сотрудника для её выполнения. Это может быть, как сам пользователь ГРД, так и его подчиненные, если задачу ставит руководитель ,подразделения. Кроме того, следует выбрать тип задачи «На день», «На неделю», «На месяц» и степень её важности «Обычная», «Важная», «Очень важная»

По нажатии кнопки «Создать» окно отправителя задачи и получателя примет вид представленный на рисунке 33.

Рисунок 33 - Пример созданной задачи.

2.6.6 Работа с модулем «Заявки»

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

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

После формирования заявки, последняя попадает в общий список мероприятий пользователя, который указан исполнителем (рисунок 34).

Исполнитель через контекстное меню вправе принять заявку или отказаться от её выполнения выбором пункта «Отклонить заявку» и указав причину отказа в дочернем окне.

Заявитель может просматривать все сформированные им заявки и статус их выполнения в программе на вкладке «Заявки» (Рисунок 35).

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

Рисунок 34 - Пример заявки

Рисунок 35 - Просмотр заявок

2.6.7 Работа с модулем «Регламенты»

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

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

Рисунок 36 - Создание регламентного мероприятия

В зависимости от выбранного типа повторения блок опций регламента меняется для выбора дня недели или месяца действия регламента.

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