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

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

Содержание:

Введение

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

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

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

объектно-ориентированное программирование (ООП);
унифицированный язык моделирования (UML);
специализированные средства разработки программного обеспечения.

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

Глава1 История развития ООП

Фундаментальными понятиями в программировании являются: технология программирования, методология, метод. Технология программирования (programming technology, sofware engineering) - это совокупность методов, способов и приемов разработки, сопровождения и применения программ, а также описание методов программирования. Метод - это совокупность приемов и операций практического и теоретического освоения действительности, в том числе программирования. Любая технология программирования базируется на некоторой методологии разработки программ. Методология - это система принципов и способов организации и построения теоретической и практической деятельности, а также учение об этой системе. Целью методологии программирования является изучение и внедрение таких методов проектирования и реализации программ, которые облегчают задачу сопровождения программы. Легкость сопровождения - это одно из тех качеств программы, которые нельзя добавить к программе после ее разработки. В настоящее время широкую известность приобрели методы: структурного программирования, модульного программирования, объектно-ориентированного программирования (ООП), формализованных технических заданий и др.

1974 г. Марвин Мински, основоположник теории искусственного интеллекта, предложил идею фрейма, отделившего описание класса (структуры) объекта от его конкретного представления (экземпляра) и быстро завоевавшего популярность в языках искусственного интеллекта. Фрейм стал прямым предшественником современного понятия объектов в Си++.

1976 г. Кринстен Нюгорн создал новый язык BETA, в котором ввел концепцию шаблонов - более высокого уровня абстракций, нежели объекты. Его коллега Оле Джохан Дал еще долгое время работал профессором информатики в Университете Осло. А Нюгорн на некоторое время занялся политикой и активно выступал против вступления Норвегии в Евросоюз.

1980 г. Бьерн Страуструп, продолживший дело своих коллег из лаборатории Bell, дополнил язык Си концепцией классов, основанной на фреймах и объектных механизмах Симулы.

1982 г. В Мехико прошла 8-я Международная конференция по сверхбольшим БД (VLDB), где была предложена концепция объектно-ориентированных БД и рассматривались вопросы расширения существовавших языков запросов к БД новыми, объектными типами данных.

1983 г. Страуструп дал своему творению окончательное название Си++. 4

Объектно-ориентированный подход основан на представлении предметной области задачи в виде множества моделей для независимой от языка разработки программной системы на основе ее прагматики.

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

Объектно-ориентированный подход обладает такими преимуществами, как:

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

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

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

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

Инкапсуляция – объединение данных и правил их обработки в один объект. Другими словами, класс представляет единство трех сущностей – полей, методов и свойств. Объединение этих сущностей в единое целое и называется инкапсуляцией. При этом класс получает определенную функциональность. Например, класс TForm содержит (инкапсулирует в себе) всё необходимое для создания Windows-окна. Инкапсуляция представляет собой мощное средство обмена готовыми к работе программными заготовками.

Наследование – определение класса и затем его использование для создания иерархии производных объектов. Порожденный класс автоматически наследует поля, методы и свойства своего родителя и может добавлять их новыми. Принцип наследования обеспечивает поэтапное создание сложных классов и разработку собственных библиотек классов. Все классы Object Pascal порождены от единственного родителя – класса TОbject. Этот класс не имеет полей и свойств, но включает в себя методы самого общего назначения, обеспечивающие весь жизненный цикл любых объектов от их создания до уничтожения.

Полиморфизм – это свойство классов решать схожие по смыслу задачи разными способами. В рамках Object Pascal поведенческие свойства класса определяются набором входящих в него методов. Изменяя алгоритм того или иного метода в потомках класса можно придавать этим потомках специфические свойства, отсутствующие у родителя. В результате в объекте-родителе и в объекте-потомке будут действовать два одноименных метода, имеющие разную алгоритмическую основу, и, следовательно, придающие объектам разные свойства. Это и называется полиморфизмом объектов.

Объектный тип данных в языке Object Pascal.

В Object Pascal объектный тип данных определяется с помощью зарезервированного слова class. По сути, класс – специальный термин для обозначения объектов. Составляющие элементы объектного типа данных (объектов /классов):

1)Поля – инкапсулированные в классе данные. Поля м.б. любого типа, в т.ч. классами. Каждый объект получает уникальный набор полей, но общий для всех объектов данного класса набор методов и свойств.

2)Методы – инкапсулированные в классе процедуры и функции, которые работают с полями.

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

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

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

Полиморфизм – это свойство классов решать схожие по смыслу задачи разными способами.

Объектный тип данных в Object Pascal должен определяться только глобально. Любой вновь создаваемый класс может содержать секции (разделы), определяемые зарезервированными словами: published (декларированные), private (личные), protected (защищенные) и public (доступные). Внутри каждой секции вначале определяются поля, а затем – методы и свойства.

1.2 Методология объектно-ориентированного программирования

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

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

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

Глава 2 Сфера применения ООП

2.1 Постановка задачи

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

Также необходимо создать редакторы свойств и редактор компонента.

Математическое описание метода

Рисунок 1 – График вычисляемой функции

Пусть для определенности функция f(x) на отрезке [a;b] имеет корень и f(a)<0,а f(b)>0. Метод хорд состоит в следующем.

Построим хорду графика, соединив точки M и N, имеющие соответствующие координаты: [a;f(a)] и [b;f(b)]. Из точки пересечения хорды и оси абсцисс – С1 опустим перпендикуляр к графику функции, получим точку M1. Затем построим новую хорду, соединив точку N с уже другой, полученной точкой M1. И т. д. необходимо строить хорды до тех пор, пока тока Сn не совпадет с точкой пересечения графика функции и оси абсцисс, т. е. с корнем – x.

Для нахождения точки С напишем уравнение хорды MN:

А затем, положив, что Y=0, найдем соответствующее значение X=C:

Описание компонента

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

Рисунок 2 - Form1

Функцию нужно вводить в код программы, в procedure TForm1.HordComponent1Function.

Точность вычисления и границы отрезка вводятся в редактор компонента, вызываемый двойным щелчком по компоненту (выделен на рисунке 3).

Рисунок 3 – Ввод данных

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

Рисунок 4 – Редактор компонента

После того, как заполнены все необходимые поля, следует нажать кнопку «вычислить». Точность и границы отрезка можно задавать также и на вкладке Properties- Epsilon (точность)

LeftBoard (левая граница)

RightBoard (правая граница)

Они автоматически будут изменяться в редакторе компонента и в свойстве компонента.

Рисунок 5 – Изменяемые данные в редакторе компонента

Так же компонент имеет редактор свойств, через который также можно задать границы отрезка. Для этого необходимо выбрать вкладку Properties, а на ней LeftBoard (левая граница) или RightBoard (правая граница). Затем нажать на соответствующую кнопочку с тремя точечками (выделена кружочком) и в появившемся окне заполнить поле.

Рисунок 6 – Редактор свойств

И затем нажать на кнопку “Ok”.

После того, как все исходные данные успешно введены необходимо запустить программу на выполнение и на первоначальной форме нажать на кнопку “искать корни”.

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

При нажатие на кнопку OK, появляется график функции, где можно увидеть этот корень:

Рисунок 7 - График вычисляемой функции

2.1.1 Тестовый пример

Например, возьмем функцию у = - 2х²+31х+12.

Будем искать корень с точностью E=0,001, на отрезке [10; 20].

Сначала вводим функцию у = - 2х²+31х+12 в код программы, в procedure TForm1.HordComponent1Function. Далее с помощью редактора компонента задаем границы отрезка и точность вычисления:

Рисунок 8 – Данные в редакторе компонентов

Далее нажимаем на кнопку «вычислить» и запускаем программу на выполнение. В появившемся окне нажимаем на кнопку «искать корни» и в качестве результата выводится диалоговые окна с корнем и графиком:

Рисунок 9 – результат вычислений

2.2 Проектирование составляющих архитектуры

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

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

Для реализации системы была выбрана интегрированная среда разработки Delphi 2006 от Borland, которое содержит богатую библиотеку готовых классов для реализации графического интерфейса приложения, а так же коммуникаций с выбранной СУБД. Хорошее приложение должно разделять дизайн экранных форм и программную логику, поэтому необходимо разработать набор классов, которые позволят реализовать все запланированные функциональные возможности информационной системы, но при этом оно не зависело от экранных интерфейсов. Основа RAD-технологии (Rapid Application Development), заключается в том, что бы, на основе экранного прототипа строилась и логика приложения, это позволяет быстро разработать приложение, данные возможности поддерживает и интегрированная среда Delphi, которая активно использует обработчики событий, начинающие программисты, прописывают код непосредственно в процедуры обработки, тем самым вплетая логику приложения в структуру экранных форм, что по сути, не является хорошим показателем, так как всегда существует возможность, что заказчик захочет кардинально изменить интерфейс, или этого потребуют сложившиеся обстоятельства, например изменение законодательной базы, что может привести к сложнейшим реструкторизационным работам. Поэтому профессиональные программисты ни когда не вплетают логику информационной системы в структуру экранных форм. К тому же хорошо спроектированная объектная модель позволит легко обновлять систему, производить улучшения интерфейса пользователя, тем самым не изменяя основной код.

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

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

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

Рисунок 10 - Класс CLibManager

Кроме работы с библиотеками, системе необходим доступ к базе данных, для организации связи с сервером FireBird, был разработан специальный класс, который базируется на трех компонентах IDE Delphi, которые осуществляют связь с СУБД Interbase, но так как FireBird – это клон InterBase, то эти компоненты как раз подойдут для этих целей. Реализация собственного класса необходима, так как использование разрозненных компонентов в сложной системе достаточно осложняет задачу реализации. Гораздо удобнее сделать один класс, который самостоятельно сможет сделать подключение к СУБД, а так же производить забор и выдачу информации в любой части приложения, проблемы с активацией компонентов, их объединении и настройке ложится на класс. К тому же если класс создается в начале инициализации приложения, а ссылка на этот класс представляет собой глобальную переменную, то задача обработки запросов, будет сведена всего к нескольким вызовам процедур класса.

Диаграмма класса для работы с СУБД FireBird дана на рисунке 11.

Рисунок 11 - Диаграмма класса CFireBird

На диаграмме так же показан класс CConfig, это класс конфигуратора системы, который загружает данные из указанного файла конфигурации и передает их классу CFireBird, для подключения к базе данных, поэтому на диаграмме стрелкой показана зависимость CFireBird от CConfig. Кроме загрузки данных для базы данных класс ССonfig так же активно используется другими объектами системы для загрузки параметров, в частности Менеджер библиотек CLibManager, использует его для получения пути к папке с библиотеками, а так же получает значения, какие библиотеки помечены на загрузку, а какие нет.

Проектируемая система, будет работать с документами: печать, экспорт, загрузка и др. Поэтому для реализации печати и экспорта документов, понадобится генератор форм документов, для этих целей практичней всего использовать формат Microsoft Word, так как он установлен на большинстве машин пользователей, и является достаточно популярным. Следовательно для экспорта документов и подготовки к печати, необходим прототип класса который будет выполнять поставленные задачи. Данным классом является класс CWordManager, его можно увидеть на диаграмме (рис.12).

Рисунок 12 - Диаграмме класса CWordManager

Данный класс позволяет манипулировать текстовым процессором Microsoft Word, данная возможность достигается за счет использования компонентной модели (COM), фабрики классов и системы интерфейсов. За счет использования сервисов COM, операционная система может загрузить любое приложение поддерживающее технологию COM.

В данном случае создается компонент “Word.Application” и используются интерфейсы, предоставляемые этим объектом. В данном случае класс имеет возможность запустить приложение MS Word, произвести определение значений переменных полей документа, вставить строки в таблицу, послать документ на печать, манипулировать окном приложения и некоторые другие. Безусловно объект “Word.Application” поддерживает намного больше функциональных возможностей, однако, для создания простого генератора форм документов, достаточно функционала представленного на диаграмме.

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

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

Группы товаров;
Типы товаров;
Модели товаров;
Серийные номера;
Единицы измерения;
Производители;
Страны производители;
Примечания;
Партнеры;
Представители;
Виды затраты;
Должности;
Работники;
Пользователи;
Реквизиты фирмы торговца.

Диаграмма данных классов представлена на рисунке 13(а). На диаграмме отображен класс “CDBObject”, который является общим предком для всех классов справочников, документов и других объектов, которые производят манипуляции с таблицами базы данных. Данный класс использует в своей работе указатель на объект класса “CFirebird”, который должен создаваться при старте системы, и существовать до тех пока не произойдет завершение работы приложения. Особенностью класса “CDBObject” является то, что он представляет ряд виртуальных методов, которые могут переопределены дочерними классами, это позволяет дочерним классам добавлять свои поля в объект для сохранения их в базе данных. Класс обладает тремя основными методами, которые позволяют автоматически сохранить в базу данных любой объект дочернего класса от “CDBObject”. То есть, если создается новый прототип класса от “CDBObject”, то разработчику нет необходимости реализовывать методы для вставки, удаления и модификации. Достаточно определить поля для объекта, а класс предок самостоятельно позаботится об сохранении этих полей. На этом принципе и была построена иерархия классов, указанная на диаграммах классов. Для простых справочников был создан универсальный класс “CSimpleReferer”, который позволяет задать имя таблицы базы данных, а затем выполнять стандартные операции над записями. От данного класса наследуют свои возможности все простые справочники, в конструкторе задается имя таблицы, и после этого справочник становится полностью функциональным.

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

Рисунок 13 - Диаграмма классов справочников

Кроме простых справочников, на диаграмме так же представлены более сложные справочники, которые для своей работы используют данные из других справочников, к таким справочникам можно отнести прототипы классов: “CPersonal”, “CFirm”, “CProduct”, “CManuf”.

Так же необходимо упомянуть о прототипе класс “CField”, данный прототип предназначен для хранения информации о одном поле таблицы базы данных. Данный класс является дочерним от системного класса библиотеки “VCL”, “TField”. Класс “TField” является абстрактным классом, и не содержит в себе поля для хранения информации, а так же методы для обработки данного поля, так же являются абстрактными. Поэтому было принято создать прототип от данного класса, который содержит в себе поле типа “Variant”, для хранения информации, а так же будут реализованы два методы для обработки данного поля.

Прототип класса “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”, в нем временно находится файл базы данных, но при конфигурации системы для работы в сети, файл с базой данных скорее всего будет находится на серверной машине, поэтому данный каталог будет пуст.

Заключение

В данном курсовом проекте рассмотрена история развития и методологии объектно-ориентированного программирования, приведен пример использования данной методологии при разработке любой информационной системы, для любого типа организации. Для реализации информационной системы использовался комплекс Borland Developer Studio 2006, инструмент Borland Delphi.

Список использованной литературы

Delphi 2005. Для профессионалов СПб: BHV, 2015
Delphi. Советы программистов (2-е издание): В.Озеров. – СПб: Символ-Плюс, 2010. – 234 стр.
Borland Delphi 2006. Руководство разработчика: С.Тейксейра, К.Пачеко. – М: Вильямс, 2012. – 458 стр.
C# и платформа .NET 3.0, специальное издание: Троелсен Э., 1-е издание, 2008 год, -360 стр.
Firebird: руководство разработчика баз данных. (2 изд.) The Firebird Book. A Reference for Database Developers, Хелен Бори , Издательство: БХВ-Петербург, 2007 г., 566 стр.
Windows via C/C++. Программирование на языке Visual C++: Дж. Рихтер, К. Назар, 1-е издание, 2009 год, - 841 стр.
Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Скотт Ф. Уилсон, Брюс Мэйплс, Тим Лэндгрейв. – М: Русская редакция, 2012. – 736 стр.
Приемы объектно-ориентированного проектирования: Э.Гамма, Р.Хелм, 1-е издание, 2009 год, -305 стр.
Проектирование экономических информационных систем: Учебник/Г.Н.Смирнова, А.А.Сорокин, Ю.Ф.Тельнов. – М: Финансы и статистика, 2014. – 512стр.
Теория и практика построения баз данных: Д. Крёнке. – Питер, 2013. – 642стр.
Самоучитель UML. Эффективный инструмент моделирования информационных систем: А. Леоненков. – СПб: BHV, 2011. – 153 стр.
Унифицированный процесс разработки программного обеспечения: А. Якобсон, Г. Буч, Дж. Рембо. – СПб.: Питер, 2006. – 496стр.
Borland AML Portal. WWW: http://www.almportal.ru
Компания Borland. WWW: http://www.borland.com
Портал распространения условно-бесплатных приложений WWW: http://www.shareIT.com/