Опыт реализации унифицированной информационной системы учета оказанных услуг Текст научной статьи по специальности «Компьютерные и информационные науки»

затем описывает обмен данными между узлами; а проектирует целостную программу, которая потом будет выполняться на всей распределенной ВС [2]);

• ОА-система реализуется как программно, так и аппаратно;

• при программной реализации обладает легкой переносимостью с одной аппаратной платформы на другую (для того, чтобы ОА-программа заработала на новой аппаратной платформе, необходимо лишь закодировать для новой машины подпрограммы реализации логики работы ФУ);

• обладает хорошей масштабируемостью как на программном, так и на аппаратном уровнях;

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

Литература

1. Салибекян С.М. Принципы милликомандной архитектуры как основа построения высокопроизводительных адаптивных вычислительных систем // Автоматизация и современные технологии. 2002. № 5.

2. Салибекян С.М., Панфилов П.Б. ОА-архитектура построения и моделирования распределенных систем автоматизации // Автоматизация в промышленности. 2010 №11

3. Минский М. Фреймы для представления знаний: Пер. с англ.- М.: Энергия, 1979.

УДК 004.4

ОПЫТ РЕАЛИЗАЦИИ УНИФИЦИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

УЧЕТА ОКАЗАННЫХ УСЛУГ1

Герасимова Ольга Игоревна, Шахтинский институт (филиал) Южно-Российского государственного технического университета (Новочеркасского политехнического института),

Россия, Шахты, [email protected]

Введение

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

Проектирование структуры базы данных (БД) - одна из наиболее ответственных фаз реализации программного обеспечения, успех которой во многом зависит от выбранной методологии. В данной работе использована методология сущность-связь, подробно описанная в [1-2]. Этап проектирования БД начинается с установления границ будущей разрабатываемой системы и определения функционала, который необходимо реализовать в приложении. Концептуальное проектирование БД позволяет описать высокоуровневую модель и начинается с создания концептуальной модели данных предприятия, полностью независимой от любых деталей реализации. К последним относятся выбранный тип СУБД, состав программ приложения, используемый язык программирования, конкретная аппаратная платформа, вопросы производительности и любые другие физические особенности реализации.

Следующим этапом является логическое проектирование БД, под которым понимается конструирование информационной модели предприятия на основе существующих конкретных моделей данных, но без учёта специфики используемой СУБД и прочих условий реализации [1].

1 Лауреат номинации "Лучший доклад по UML-моделированию". Автор доклада награждается книгой Иванова Д. Ю. и Новикова Ф.А. "Моделирование на UML. Теория, практика, видеокурс" (www.umlmanual.ru) с автографами авторов

80

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

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

Физическое проектирование БД предусматривает принятие разработчиком окончательного решения о способах реализации создаваемой базы. Поэтому физическое проектирование обязательно производится с учетом всех особенностей используемой СУБД. Т.к. объектно-ориентированный подход является одним из часто используемых, применяемых при разработке программного обеспечения, было принято решение использовать именно объектно-ориентированную систему управления базами, допускающую создание новых типов данных на основе существующих, поддерживающую продолжительные транзакции и наследование, что способствует ускорению разработки и упрощению сопровождения БД. В нашем случае использована ООСУБД db4objects версии 7.2. Между этапами физического и логического проектирования всегда имеется определенная обратная связь, поскольку решения, принятые на этапе физического проектирования с целью повышения производительности разрабатываемой системы, могут потребовать определенной корректировки логической модели данных.

1. Концептуальное проектирование структуры базы данных

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

• информацию о сотрудниках предприятия;

• информацию об отделах, в которых работают сотрудники;

• информацию о должностях, занимаемых сотрудниками;

• информацию о клиентах, с которыми работает организация;

• информацию об организациях, в которых могут работать клиенты;

• информацию о заявках на оказание услуг, подаваемых клиентами;

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

• информацию об оказываемой услуге;

• информацию о типе оказываемой услуги.

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

Список типов сущностей предметной области:

• Service - услуга, оказываемая клиентам;

• ServiceType - тип услуги, оказываемой клиентам;

• Status - статус обработки заявки;

• Client - лицо, подающее заявку на оказание услуг;

• Organization - организация, в которой работает клиент;

• Employee - сотрудник предприятия, оказывающий услуги;

• Position - должность, занимаемая сотрудником на рабочем месте;

• Department - отдел, в котором работает сотрудник;

• Contract - договор об оказании услуг клиенту.

81

Установим все существующие между выделенными сущностями связи и определим их кратность:

• Связь WorksIn является бинарной и соединяет сущности Organization (0..*) и Client (0..*).

• Связь Takes является бинарной и соединяет сущности Employee (0..*) и Position (1..1).

• Связь WorksAt также является бинарной и соединяет сущности Employee (0..*) и Department (1..1).

• Связь HasType является бинарной и соединяет сущности Service (0..*) и ServiceType (1..1).

• Связь Order является n-арной и соединяет сущности Client (0..*), Service (0..*), Status (0..*), Contract (0..*) и Employee (0..*).

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

Для сущности Client необходимо сохранять атрибуты Name, Address и Phone, включающие соответственно Ф.И.О., адрес и контактный телефон клиента.

В сущности Organization предусмотрено сохранение атрибутов Name, Address и Phone, содержащих информацию соответственно о наименовании, адресе и контактном телефоне организации клиента.

Для сущности Employee необходимо сохранять атрибуты Name, Address и Phone, включающие соответственно Ф.И.О., адрес и контактный телефон сотрудника, принимающего заявку на оказание услуги.

В сущности Position сохраняется атрибут Name, содержащий название должности сотрудника.

Cущность Department включает атрибут Name, содержащий название отдела, в котором работает сотрудник.

В сущности Service необходимо сохранять атрибуты Name, Price и NDS, включающие информацию соответственно о наименовании, цене и сумме НДС с оказываемой услуги.

Сущность Status содержит атрибут Name, описывающий текущую стадию обработки заявки.

В сущности ServiceType сохраняется атрибут Name, хранящий наименование типа оказываемой услуги.

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

Для графического представления сущностей и связей создаваемой БД (см. рис.1) разработана ER-диаграмма предметной области, для отображения которой использована нотация унифицированного языка моделирования UML [3]. После того, как построена концептуальная модель БД, необходимо проверить ее на достоверность с помощью определения соответствия транзакциям пользователя. Проверим возможность выполнения следующих основных транзакций:

Т1. Добавление нового клиента

Т2. Добавление статуса услуги

Т3. Добавление новой услуги

Т4. Добавление нового типа услуги

Т5. Добавление нового сотрудника

Т6. Добавление новой должности

Т7. Добавление информации о совершенной услуге

Т8. Добавление новой организации

T9. Добавление нового договора об оказании услуги

Т10. Добавление нового отдела предприятия

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

82

Для каждой транзакции в круглых скобках указаны операции, выполняемые транзакцией над данной сущностью: I (Insert) - вставка нового экземпляра сущности, U (Update) - обновление значений атрибутов, R (Read) - чтение значений атрибутов, D (Delete) - удаление сущности из БД.

Из рис.1 следует, что все описанные ранее транзакции выполнимы, следовательно, концептуальное проектирование структуры БД выполнено верно и можно приступать к логическому проектированию.

2. Логическое проектирование структуры базы данных

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

1. Выполнить обобщение/специализацию;

2. Преобразовать связи с атрибутами в отдельные классы;

3. Преобразовать сложные связи в отдельные классы.

Проанализировав рис. 1, можно утверждать, что все выделенные классы (Client, Organization, Status, Employee, Position, Department, Service, ServiceType и Contract) сходны, так как характеризуются общими атрибутами (в нашем случае названием, атрибутом Name). Поэтому имеет смысл выделить общий базовый абстрактный класс (выполнить процедуру обобщения), содержащий название (например, класс NamedObject), а классы Client, Organization, Status, Employee, Position, Department, Service, ServiceType и Contract сделать производными от NamedObject.

Классы Client и Employee также имеют одинаковые атрибуты (Address и Phone), следовательно, выделим для них базовый класс OrderedContragent.

Выделим также базовый класс OrderedObject для объектов, содержащих заказы, а производными от него станут классы OrderedContragent, Service, Status и Contract.

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

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

83

(Client), статус обработки заявки клиента (Status), оказываемую клиенту услугу (Service), итоговый контракт с клиентом, свидетельствующий об исполнении услуги (Contract), а также сотрудника, оказывающего услугу (Employee). Результат проделанных операций представлен на рис. 2.

Рис. 2 - Логическая модель

3. Физическое проектирование структуры базы данных

Для разработки структуры БД использована бесплатная ООСУБД db4objects версии 7.2, а сама реализация представляет собой процесс написания классов и организации ассоциаций. Для реализации структуры спроектированной БД в среде целевой СУБД используем интегрированную среду разработки Microsoft Visual Studio 2010. Реализуем БД при помощи языка программирования С#, используя его функциональные особенности (рис.З).

Рис. 3 - Физическая модель структуры базы данных

84

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

Выберите пункт и нажмите Enter:

1 - Заполнение БД тестевой информацией

2 - Список отделов (с указанием работников)

3 - Штатное расписание (Список работников с указание должности и отдела)

4 - Организации, с которыми сотрудничает РИД (с указанием клиентов)

5 - Прайс-лист услуг

6 - Список всех заявок (сортировка по дате)

7 - Список всех контрактов (с указанием заявок)

В - Список выполненных заявок

9 - Выход из программы

7

Список всех контрактов, с указанием заявок Контракт: 001 от 02.02.2010 0:00:00

Заявка от: 23.01.2010 0:00:00 По цене: 870 Клиент: Перепелица Анна Васильевна Адрес: Текстильная 3, кв.78 Телефон: 89058781198 Услуга: Реклама 5x8см в газете К вашим услугам Тип услуги: Новость в газете Цена: 500 НДС: Юх

Работник: Дроздов Андрей Евгеньевич Адрес:Чернокозова д.15, кв. 12 Телефон:89Ш56781234 Должность:Доставщик Отдел:0тдел доставки Статус заявки: Заявка выполнена Контракт: 001 от 02.02.2010 0:00:00

Заявка от: 23.01.2010 0:00:00 По цене: 640 Клиент: Перепелица Анна Васильевна Адрес: Текстильная 3, кв.78 Телефон: 89056781198 Услуга: Распечатать и распространить 100 Флайеров 10x15 Тип услуги: Флайер Цена: 700 НДС: Юх

Работник: Хабенков Станислав Георгиевич Адрес:Ленина д.147 Телефон:89085923121 Должность Начальник доставки 0тдел:0тдел доставки Статус заявки: Заявка выполнена Контракт: 001 от 02.02.2010 0:00:00 Контракт: 002 от 03.03.2010 0:00:00

Заявка от: 01.03.2010 0:00:00 По цене: 900 Клиент: Симонов Игорь Михайлович Адрес: Садовая 17, кв.5 Телефон: 89287612345 Услуга: Реклама 10x8см в газете К вашим услугам Тип услуги: Новость в газете Цена: 900 НДС: 10х

Работник: Дроздов Андрей Евгеньевич Адрес:Чернокозова д.15, кв. 12 Телефон:89056781234 Должность:Доставщик Отдел:0тдел доставки Статуе заявки: Заявка включена в контракт (но не выполнена)

Контракт: 002 от 03.03.2010 0:00:00

Заявка от: 01.03.2010 0:00:00 По цене: 800 Клиент: Симонов Игорь Михайлович Адрес: Садовая 17, кв.5 Телефон: 89287612345 Услуга: Распечатать и распространить 100 Флайеров 10x20 Тип услуги: Флайер Цена: 800 НДС: 10Х Работник: Селина Анна Павловна Адрес:Разина 12 Телефон:89089814912 Должность:Доставщик Отдел:0тдел доставки Статус заявки: Заявка включена в контракт (но не выполнена)

Контракт: 002 от 03.03.2010 0:00:00

Рис. 4 - Диалоговое окно тестового приложения

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

Выводы

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

Литература

1. Коннолли, Томас, Бегг, Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. - М. : Издательский дом "Вильямс", 2003. - 1440 с. : ил. - Парал. тит. англ.

2. Дейт К. Дж., Введение в системы баз данных, 7-е издание. : Пер. с англ. - М. : Издательский дом «Вильямс», 2001. - 1072 с. : ил. - Парал. тит. англ.

3. Мюллер Р. Дж., Базы данных и UML проектирование: Пер. с англ. - М. : Лори, 2002. - 420с.: ил. - Парал. тит. англ.

85