Файл: Проектирование реализации операций бизнес-процесса «Продажи» (Характеристика существующих бизнес – процессов).pdf

Менеджер, заключая юридические отношения должен составить договор, а каждый договор обязательно должен быть составлен менеджером. Поэтому степени участия в данной связи сущностей МЕНЕДЖЕР и ДОГОВОР являются обязательными.

1. Программист формирует ПО «1С:Предприятие»

Программист 1С может разработать или изменить несколько программных приложений, но каждое приложение может быть разработано одним программистом. Поэтому связь между сущностями ПРОГРАММИСТ и ПО «1С:Предприятие» имеет тип «один ко многим».

Программист 1С должен обязательно разработать программное приложение, а каждое программное приложение должно быть разработано программистом, поэтому степени участия в данной связи сущностей ПРОГРАММИСТ 1С и ПО «1С:Предприятие» являются обязательными.

1. Бухгалтер выдаёт Счёт

Бухгалтер может выдать несколько счетов, но каждый счет должен быть выдан одним бухгалтером. Поэтому связь между сущностями БУХГАЛТЕР и СЧЁТ имеет тип «один ко многим».

Бухгалтер должен обязательно выдать счёт, а каждый счёт должен быть выдан бухгалтером, поэтому степени участия в данной связи сущностей БУХГАЛТЕР и СЧЁТ являются обязательными.

1. Счет включает ПО «1С:Предприятие»

О продаже каждого ПО свидетельствует счет. Может быть предъявлено несколько счетов на оплату покупки нескольких ПО «1С». Между сущностями СЧЁТ и ПО «1С:Предприятие» можно установить связь «многие ко многим».

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

1. Счет подтверждает Заказ

Каждый заказ подразумевает оформление одного или нескольких счетов, а каждый счёт подтверждает только один заказ. Следовательно, между сущностями СЧЁТ и ЗАКАЗ существует связь «один ко многим».

Заказ на ПО подтверждает выписанный и оплаченный счет. Любой счет не может быть выписан без факта заказа. Поэтому степени участия сущностей СЧЁТ и ЗАКАЗ являются обязательными.

1. Клиент оплачивает Счет

Клиент может в случае приобретения нескольких прикладных решений оплатить несколько счетов, но каждый счет может быть оплачен только одним клиентом. Значит, взаимосвязь между сущностями КЛИЕНТ и СЧЕТ определяется как «один ко многим».

Каждый клиент оплачивает хотя бы один счет, а каждый счет обязательно должен быть оплачен клиентом. Поэтому степени участия в данной связи сущностей КЛИЕНТ и СЧЕТ являются обязательными.

2.4. Общие положения (дерево функций и сценарий диалога)

ER-диаграмма концептуальной модели бизнес-процесса фирмы «Максимум» приведена на рис. 3.

1 1 1

Клиент

Делает

Подписывает

М

Оплачивает

Заказ

1

Подтверждает

М

Охватывает

1

М

М М М 1 1 М

Определяет

Включает

Договор

ПО «1С»

Счёт

М М М

Составляет

Выдаёт

Формирует

1 1 1

Менеджер

Бухгалтер

Программист

– обязательная степень участия сущности в связи,

– необязательная степень участия сущности в связи.

Рис. 3. ER-диаграмма концептуальной модели бизнес-процесса фирмы «Максимум»

2.5. Характеристика базы данных

Построение и проверка логической модели данных на основе представлений о предметной области.

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

Итак, проанализируем ER-диаграмму концептуальной модели бизнес-процесса фирмы «Максимум» (рис. 3) с учетом правил проектирования БД из ER-диаграммы. В данном случае можно выделить следующие отношения:

1) Клиент Делает Заказ

Таблицы:

«Клиент» (Уникальный ключ клиента, …);

«Заказ» (Уникальный ключ заказа, Уникальный ключ клиента,…).

2) Заказ Охватывает ПО «1С:Предприятие»

Таблицы:

«Заказ» (Уникальный ключ заказа,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный ключ заказа,…).

3) Договор Определяет ПО «1С:Предприятие»

Таблицы:

«Договор» (Уникальный ключ договора,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный ключ договора,…).

4) Клиент Подписывает Договор

Таблицы:

«Клиент» (Уникальный ключ клиента, …);

«Договор»(Уникальный ключ договора, Уникальный ключ клиента,…).

5) Менеджер Составляет Договор

Таблицы:

«Менеджер» (Уникальный ключ менеджера, …);

«Договор»(Уникальный ключ договора, Уникальный ключ менеджера,…).

6) Программист Формирует ПО «1С:Предприятие»

Таблицы:

«Программист» (Уникальный ключ программиста,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный ключ программиста,…).

7) Бухгалтер Выдаёт Счёт

Таблицы:

«Бухгалтер» (Уникальный ключ бухгалтера,…);

«Счёт» (Номер записи, Уникальный ключ бухгалтера,…).

8) Счёт Включает ПО «1С:Предприятие»

Таблицы:

«Счёт» (Уникальный номер счёта,…);

«ПО 1С:Предприятие» (Уникальный ключ ПО, Уникальный номер счёта,…).

9) Счёт Подтверждает Заказ

Таблицы:

«Счёт» (Уникальный номер счёта,…);

«Заказ» (Уникальный ключ заказа, Уникальный номер счёта,…).

10) Клиент Оплачивает Счёт

Таблицы:

«Клиент» (Уникальный ключ клиента,…);

«Счёт» (Уникальный номер счёта, Уникальный ключ клиента,…).

2.6. Структурная схема пакета (дерево вызова программных модулей)

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

- выбор и обоснование среды программирования;

- разработка пользовательского интерфейса;

- подготовка отчётных данных.

В качестве среды для разработки программного интерфейса была выбрана объектно-ориентированная среда программирования Borland Delphi 7. Эта среда, предназначенная для разработки приложений в архитектуре клиент-сервер.

Преимущества Delphi по сравнению с другими программными продуктами:

1) Быстрота разработки приложения;

2) Высокая производительность разработанного приложения;

3) Низкие требования разработанного приложения к ресурсам компьютера;

4) Возможность полного доступа к функциям операционных систем Windows;

5) Hаращиваемость за счет встраивания новых компонент и инструментов в среду Delphi.

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

1. Формирование базы данных Oracle в среде Delphi;
2. Автоматизация заключения договоров и выдачи счетов;
3. Создание формы для выбора определённых записей;
4. Создание поисковой системы;
5. Создание справочной системы.

Для подключения базы данных «Максимум» в среду Delphi, которая была спроектирована в СУБД Oracle будем использовать технологию Microsoft ActiveX Data Objects (ADO), которая основана на возможностях СОМ, а именно интерфейсов OLE DB.

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

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

1) ADOConnection, обеспечивает расширенное управление соединением и позволяет обращаться к данным нескольким компонентам одновременно;

2) ADOTable, - таблица базы данных, подключается к ADOConnection;

Помимо этих стандартных компонентов, инкапсулирующих набор данных, на форме необходимо для подключения таблиц расположить также компонент DataSource со страницы Data Access, обеспечивающий связь компонента отображения-редактирования данных (например, компонента DBGrid) и источника данных, в качестве которого может выступать таблица (компонент Tаblе) или результат выполнения SQL-запроса к таблице (компонент SQL) и визуальный компонент DBGrid, отображающий подключённую таблицу БД.

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

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

Дальнейшим этапом разработки интерфейса будет являться создание кнопок для редактирования записей в таблицах БД. Это будут кнопки:

1. Подключить;
2. Добавить запись;
3. Сохранить запись;
4. Удалить запись;

Расположим эти кнопки также на каждой вкладке TabSheet компонента PageControl.

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

1) в палитре свойств компонента ADOConnection выбираем свойство ConnectionString, нажимаем на кнопку с троеточием, затем нажимаем кнопку Build, появится окно «Свойства связи с данными», в списке поставщиков данных которого выбираем: Oracle Provider for OLE DB.

Рис.4 Выбор подключаемого драйвера

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

2) соединяем компонент ADOTable с ADOConnection при помощи свойства Connection, а в свойстве TableName выбираем из списка нужную таблицу БД и выставляем значение Active в True.

3) соединяем компонент DataSource с ADOTable через свойство DataSet.

Для полного подключения и отображения таблицы БД в компоненте DBGrid необходимо установить значение свойства DataSource в DataSource, соответствующий подключаемой таблице. Однако мы сделаем это программно, поскольку у нас есть кнопка «Подключить», в обработчике события которой необходимо прописать следующий код:

DBGrid1.DataSource:=DataSource1; // для подключения таблицы 1

Аналогично и для других таблиц. А для кнопок «Добавить запись», «Сохранить запись», «Удалить запись» программный код будет соответственно:

ADOTable1.Insert; // добавление записи в таблицу 1

ADOTable1.Next; // сохранение записи в таблице 1

ADOTable1.Delete; // удаление записи из таблицы 1

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

Рис.5 Табличная форма базы данных «Максимум»

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

Для решения поставленной задачи создадим на форме панель «Регистрация», которая будет включать два переключателя: «Договора» и «Счета» (рис.6). При этом предварительно должны быть созданы новые формы – форма регистрации договоров и форма регистрации счетов.

Рис.6 Панель «Регистрация»

В обработчике события переключателя «Договора» пропишем следующий код:

Листинг 1. Процедура обработки события «Регистрация договоров»

// форма регистрации договоров

Form3.Show;

// реквизиты договора из таблицы "Договор"