Файл: История и развитие методологии объектно-ориентированного программирования. Сферы применения. (Методология объектно-ориентированного программирования).pdf

Прототип класса “CField” используется классом “CDBObject” для хранения атрибутов таблицы базы данных. Именно массив из этих полей и обрабатывается классом “CDBObject” при стандартных манипуляциях.

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

• Номер,
• Дату,
• Контрагент,
• Пометки.

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

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

Таким образом от класса “CDocument”, был спланирован класс “CItemedDocument”, который является носителем постоянного набора реквизитов, а так же является контейнером для объектов класса “CDocumentItem”, который является хранителем информации об единице составной части документа.

Для каждого класса документа, была спроектирована форма, которая позволяет вводить данные документа, а так же производить их модификацию. Классы форм являются дочерними от системного класса библиотеки “VCL”, “TForm”. На диаграмме документов, классы форм начинаются с префикса “Tfrm”.

Рисунок 14 - Диаграмма классов документов

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

Класс для обработки заказа, является дочерним от “CDBObject”, это видно из диаграммы. Класс “COrder”, является контейнером для объектов типа “COrderItem”. Класс “COrderItem” является единицей заказа, и очень схож с классом “CDocumentItem”. Однако для устранения путаницы, эти классы были разделены.

Рисунок 15 - Диаграмма классов необходимых для формирования заказа

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

В заключении хочется прокомментировать прототип “TJournalForm”, данный класс представляет собой универсальную форму-журнал для отображения любого дочернего класса от “CDBObject”. Использование данного класса позволяет избавится от необходимости реализовывать для каждого отдельного объекта базы данных своего журнала для отображения записей. Форма использует указатель типа “CDbObject” для выполнения виртуальных методов объекта. Данный подход использует объектно-ориентированные принципы: полиморфизм и наследование. Ведь именно использование виртуальных методов, позволяет выполнять методы дочерних классов через указатель на базовый класс.

2.2.1 Диаграмма компонентов

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

• bin – каталог бинарных файлов, сгенерированных после сборки;
• etc – файлы разного назначения;
• src – файлы с исходными кодами, этот каталог может содержит подкаталоги;
• res – файлы с ресурсами (экранные формы, иконки)
• doc – документация к проекту;
• lib – каталог с файлами библиотек;
• tst – каталог для тестирования;
• include – каталог с заголовочными файлами (обычно наборы констант, заголовки функций и другое).

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

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

На рисунке 16 представлена диаграмма компонент, которая отображает иерархичное устройство проекта.

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

Весь проект можно представить в виде четырех каталогов, в каталоге “bin” находятся бинарные файлы (MPE.exe и файлы библиотек), файлы конфигурации, и база данных. В каталоге “etc” находятся разнородные файлы, принадлежащие проекту не напрямую, а скорее косвенно, это справки по SQL-серверу, файлы документации и другое. В каталоге “doc” находятся файлы документации на проект, в том числе и файл с данным текстом. В каталоге “src” находятся исходные коды приложения и библиотек, данный каталог так же содержит подкаталоги, поэтому заслуживает более детального рассмотрения. На рисунке 17 представлена диаграмма компонентов каталога “src”.

Рисунок 17 - Диаграмма исходных кодов

Основным файлом проекта является файл “mpe.dpr”, он содержит в себе код по инициализации библиотек, создаются объекты для работы с базой данных, производится вывод окна для авторизации, считывается данные из файла конфигурации, запускается основной класс приложения “TApplication”. Как видно в каталоге находятся еще несколько каталогов, каждый каталог содержит в себе исходные коды приложения, внутри каждого каталога, существует своя иерархия подкаталогов.

В каталоге “dcu” находятся откомпилированные исходные коды, но еще не собранные в бинарный исполнимый файл, данные файлы сходны с файлами *.obj, получаемые при компиляции компилятором С\С++ или компилятором ассемблера. В каталоге “dlg” находятся диалоговые формы, в каталоге “etc” находятся случайные шаблоны кода и файлы, которые не пригодились в проекте. Каталог “lib” содержит в себе файлы с прототипами тех классов, которые были показаны на диаграммах классов, а в каталоге “main” находятся файлы с программным кодом, который в своей работе использует объекты данных прототипов.

В папке “Plugins” находятся проекты плагинов. Каждый плагин находится в своем каталоге, а внутреннее устройство каталога сходно с тем, что показано на рисунке 18

Особой структурой обладает каталог с бинарными файлами, поэтому следует его так же рассмотреть, диаграмма представлена на рисунке18.

Рисунок 18 - Диаграмма каталога с бинарными файлами

Каталог “templ” содержит шаблоны для экспорта и печати документов, в каталоге “conf” находятся файлы конфигурации системы, папка “docs” содержит в себе документацию на систему, в каталоге “reports” находятся шаблоны для отчетов, в каталоге “plugins” размещаются плагины, которые загружаются системой при старте. Отдельно нужно сказать о каталоге “data”, в нем временно находится файл базы данных, но при конфигурации системы для работы в сети, файл с базой данных скорее всего будет находится на серверной машине, поэтому данный каталог будет пуст.