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

Моделирование предметной области «Учет продаж» с помощью UML (Основные понятия объектно-ориентированного подхода)

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Цель исследования: разработать автоматизированную информационную систему (АИС) предприятия для автоматизации отдела продаж.

Для достижения цели данного исследования поставлены следующие задачи:

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

Объектом исследования настоящей курсовой работы является объектно–ориентированная методология проектирования.

Предметом исследования настоящего исследования являются объектная модель предметной области «Учет продаж» и её основные свойства.

На этапе анализа предметной области и проектирования структуры приложения необходимо построить UML диаграмму классов.

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

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

1. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ ПОЛОЖЕНИЯ ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ МЕТОДОЛОГИИ

Основные понятия объектно-ориентированного подхода

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

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

Важными понятиями программирования являются процедурно-ориентированное программирование и объектно-ориентированное программирование.

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

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

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

Между ООП и процедурно-ориентированным программированием существуют два важных различия:

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

Абстракция – это выделение существенных характеристик объекта, которые отличают его от всех других объектов, четко определяя его концептуальные границы.

Класс – это совокупность объектов, имеющих общие свойства и поведение.

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

В основе объектно-ориентированной технологии программирования лежат «три кита»: инкапсуляция, наследование и полиморфизм.

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

Наследование (inheritance) – это процесс, посредством которого один процесс может приобретать свойства другого.

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

Модульность – система состоит из независимых компонент – модулей, для которых определены программные интерфейсы, их взаимодействие.

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

Параллелизм – свойство нескольких абстракций одновременно находиться в активном состоянии, т.е. выполнять некоторые операции.

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

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

1. Понятие объект

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

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

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

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

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

Средства реализации объектно-ориентированной технологии программирования

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

Любое программирование осуществляется по одному из четырех принципов:

принцип модульности
принцип «от общего к частному»
принцип пошаговости
принцип структурирования

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

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

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

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

простой последовательности действий;
конструкции выбора или оператора if;
конструкции повторения или цикла.

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

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

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

Структурное программирование. Структурное программирование - модульное нисходящее пошаговое проектирование алгоритма и структур данных.

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

объектно-ориентированный анализ (ООА),
объектно-ориентированное проектирование (ООД),
объектно-ориентированное программирование (ООП).

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

Объектно-ориентированный анализ и проектирование - это метод, логически приводящий к объектно-ориентированной декомпозиции. Применяя объектно-ориентированное проектирование, создаются гибкие программы, написанные экономными средствами.

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

2. ПОСТРОЕНИЕ ОБЪЕКТНОЙ МОДЕЛИ ПРЕДМЕТНОЙ ОБЛАСТИ «УЧЕТ ПРОДАЖ» С ПРИМЕНЕНИЕМ ЯЗЫКА МОДЕЛИРОВАНИЯ UML

2.1. Описание функционирования предметной области «Учет продаж»

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

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

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

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

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

2.2. Построение диаграммы модели информационной системы оптовой базы

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

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

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

Покупатель – клиент оптовой базы, выбирает товар для покупки, если в наличии не будет выбранного товара, подает заявку.

Теперь необходимо создать в ModelMaker главную диаграмму модели и диаграммы действующих лиц (рис. 1).

Рисунок 1 – Перечень действующих лиц в главной диаграмме модели

Следующий этап – составление списка вариантов использования.

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

Исходя из потребностей действующих лиц и описания предметной области, были созданы следующие варианты использования:

– Заполнить форму заявки на покупку. Действующее лицо «Покупатель» заполняет форму заявки на покупку товара в оптовой базе, указывая наименование и количество товаров.

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

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

– Принять заказа покупателя. Администратор утверждает принятие заказа поставщика, система рассылает прайсы покупателям.

– Установить расписание. Система предоставляет администратору форму, в которой он указывает время доставки и адрес в потовую базу.

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

– Сформировать отчет за определенные периоды времени о работе.

– Сформировать отчет по списку оптовых покупателей.

– Сформировать отчет по заявкам на товары.

– Сформировать отчет по анализам продаж.

Все варианты использования нужно добавить в главную диаграмму модели. Результат представлен на рисунке 2.

Рисунок 2 – Список вариантов использования информационной системы оптовой базы

2.3. Диаграмма вариантов использования информационной системы оптовой базы

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

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

Рисунок 3 – Диаграмма вариантов использования информационной системы оптовой базы

Далее следует детальное описание вариантов использования, которые в большей степени раскрывают работу данной информационной системы оптовой базы:

– Заполнить форму заявки на покупку.

– Внести данные о продавце и товара.

– Сформировать отчет по заявкам на товары.

Вариант использования «Заполнить форму заявки на товар»

Краткое описание. Данный вариант использования описывает заполнение покупателем формы заявки на покупку товаров.

Основной поток событий

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

Предусловия

Перед заполнением формы покупатель должен войти в систему.

Постусловия

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

2.4. Архитектурный анализ информационной системы оптовой базы

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

Как правило, в потоках событий каждого варианта использования выявляются классы трех типов (Category):

Граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой.

Классы-сущности (Entity) – представляют собой ключевые абстракции (понятия) создаваемой системы.

Управляющие классы (Control) – обеспечивают координацию объектов в системе.

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

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

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

Граничный класс RequestForm – электронная форма заявки на продукт.
Граничный класс Request – заявка на продукт.
Управляющий класс ControllerRecordRequest – контролер записей персональных данных о покупателе в электронную базу.

Ниже приведены перечни классов для данных вариантов использования.

Перечень классов для варианта использования «Сформировать отчет по заявкам на товары»:

Граничный класс EAReportForm – электронная форма для формирования отчета: внесение данных о продуктах.
Управляющий класс ControllerEAReport – контролер событий.
Класс-сущность InternalExamResults – таблица с результатами заявок.

Далее нужно создать список классов в ModelMaker. Он представлен на рисунке 5.

Рисунок 5 – Перечень классов модели информационной системы оптовой базы

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

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

Диаграмма последовательности «Заполнить форму заявки на товар»

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

TRequestForm – электронная форма заявки на товар, граничный класс (Boundary).

TRequest – заявка на товар, граничный класс (Boundary).

TControllerRecordRequest – контролер записей персональных данных о покупателе в электронную базу, управляющий класс (Control).

Действующее лицо – Покупатель.

Проанализировав описание варианта использования, можно добавить для данной диаграммы последовательности, следующие сообщения:

От действующего лица «Покупатель» к граничному классу «TRequestForm» передается сообщение: 1. Запрос формы «Заявка».

От граничного класса «TRequestForm» к действующему лицу «Покупатель» передается сообщение: 2. Предоставление формы «Заявка».

От действующего лица «Покупатель» посылается сообщение самоделегирования: 3. Ввод персональных данных.

От действующего лица «Покупатель» к управляющему классу «TControllerRecordRequest» передается сообщение: 4. Сохранить изменения.

От управляющего класса «TControllerRecordRequest» посылается сообщение самоделегирования: 5. Сформировать заявку.

От управляющего класса «TControllerRecordRequest» к граничному классу TRequest посылается сообщение: 6.Отправить заявку.

От действующего лица «Покупатель» к граничному классу «TRequestForm» передается сообщение: 7.Закрытие формы «Заявка»

Созданная диаграмма последовательности для данного варианта использования представлена далее на рисунке 6.

Рисунок 6 – Диаграмма последовательности для варианта использования «Заполнить форму заявки на товар»

Диаграмма последовательности «Внести данные о назначенном поставщике»

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

TDataLearnerForm– электронная форма для ввода данных о покупателе, граничный класс (Boundary).

TListCarInstructor – таблица с записями о товарах, класс-сущность (Entity).

TLearner – соответствует действующему лицу «Покупатель», класс-сущность.

TInstructor – соответствует действующему лицу «Поставщик», класс-сущность.

Действующее лицо – Администратор.

От действующего лица «Администратор» к граничному классу «TDataLearnerForm» передается сообщение: 1. Запрос формы «Данные о покупателе».

От действующего лица «Администратор» к управляющему классу «TControllerRecordLearner» передается сообщение: 2. Запрос данных.

От управляющего класса «TControllerRecordLearner» к классу-сущности «TListCarInstructor» передается сообщение: 3. Запрос информации о товарах.

От управляющего класса «TControllerRecordLearner» посылается сообщение самоделегирования: 4. Формирование запроса.

От действующего лица «Администратор» посылается сообщение самоделегирования: 5. Определить товар.

От действующего лица «Администратор» к граничному классу «TDataLearnerForm» передается сообщение: 6. Ввод данных.

От действующего лица «Администратор» к управляющему классу «TControllerRecordLearner» передается сообщение: 7. Сохранить изменения в системе.

От управляющего класса «TControllerRecordLearner» к классу-сущности «TLearner» передается сообщение: 8. Отправить сведения покупателю.

От управляющего класса «TControllerRecordLearner» к классу-сущности «TInstructor» передается сообщение: 9. Оповестить поставщика.

Созданная диаграмма последовательности для данного варианта использования представлена далее на рисунке 7.

Рисунок 7 – Диаграмма последовательности для варианта использования «Внести данные о назначенном товаре»

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

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

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

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

На основе диаграммы последовательности «Внести данные о назначенном товаре» можно добавить в класс «TListCarInstructor» следующие свойства:

– «FullName».

– «Car».

– «QuantityLearner».

Далее нужно указать видимость свойства (Visibility).

Public (общий). Это значение предполагает, что атрибут будет виден всеми остальными классами. Любой класс может просмотреть или изменить значение атрибута.

Private (закрытый). Соответствующий атрибут не виден никаким другим классам.

Protected (защищенный). Такой атрибут доступен только самому классу и его потомкам.

В данном случае, все атрибуты общие (public).

Далее нужно определить операции. Для атрибута «FullName» в группе чтения значения атрибута указывается Method. Система ModelMaker автоматически генерирует название: GetFullName. В группе Write Access так же необходимо выбрать Method. Система создаст название метода SetFullName. В качестве параметра указывается любое имя. В данном случае value. Аналогичным образом создаются методы доступа для других атрибутов данного класса.

Следует подготовить программную реализацию методов (GetFullName, SetFullName). Для этого на странице Implementation нужно прописать следующий программный код по строкам:

Для метода GetFullName: Result:=FFullName.

Для метода SetFullName: FFullName:=value.

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

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

Для включения в класс операции реализации следует воспользоваться функцией Add Metods. Так, для данного класса можно выделить следующие операции реализации:

AddRecord – добавляет новую запись в класс.

DeleteRecord – удаляет запись из класса.

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

Аналогично задаются атрибуты и методы другим классам.

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

Класс «InternalExamResults»:

– «NameLearner».

– «PracticeResult».

– «TheoryResult».

Класс «TInstructor»:

– «FullName».

– «DOB».

– «PassportData».

– «Address».

– «Education».

– «DrivingExperience».

Для электронных форм можно выделить две операции:

– «OpenForm» (открыть форму).

– «CloseForm» (закрыть форму).

Операции класса ExamAdmissionReport:

– «CreateReport» (Создать отчет).

– «DestroyReport» (Удалить отчет).

– «PrintReport» (Отправить отчет на печать).

Созданная диаграмма классов представлена на рисунке 9.

Рисунок 9 – Диаграмма классов информационной системы оптовой базы

ЗАКЛЮЧЕНИЕ

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

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

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

Для достижения цели данного исследования были выполнены следующие задачи:

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

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

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

СПИСОК ЛИТЕРАТУРЫ

Алгоритмические языки и программирование. Система программирования DELPHI / разраб. Т.А. Лабзина. – М.: Совр. Гум. Ун-т, 2002.
Ахангельский А.Я. Программирование в Delphi 7. – М.: ООО «Бином-Пресс», 2003 г. – 1152 с.
Голицына О.Л. и др. Языки программирования. – М.: Форум; Инфра-М, 2008.
Дарахвелидзе П.Г., Марков Е.П. Программирование в Delphi 7. –СПб.: БХВ-Петербург, 2003. – 784 с.
Семакин И.Г., Шестаков А.П. М. Основы программирования. –М.: Академия, 2003. – 438 с.
Сорокин А.В. Delphi. Разработка баз данных. – СПб.: Питер, 2005. – 477с.
Фаронов В.В. Система программирования Delphi. – СПб.: БХВ-Петербург, 2004. – 912 с.
Дубаков А.А. Проектирование информационных систем: Учебное пособие. Томск.: Изд. ТПУ, 2001.
Информатика/Курносов А.П., Кулев С.А., Улезько А.В. и др.; Под ред. А.П. Курносова.-М.: КолосС, 2005.-272 с
Макарова Н.В. Информатика /под ред. Проф. Н.В. Макаровой. — М.: Финансы и статистика, 1997. — 768 с.: ил.
Малышев Р.А. Локальные вычислительные сети: Учебное пособие/ РГАТА. – Рыбинск, 2005. – 83 с.
Островский В.А. Информатика: учеб. для вузов. М.: Высшая школа, 2000. —511 с.: ил.
Семакин И.А., Информатика: Базовый курс /Семакин И.А., Залогова Л., Русаков С., Шестакова Л. – Москва: БИНОМ.,2005. – 105с.
Симонович С.В. Информатика. Базовый курс/Симонович С.В. и др. — СПб.: издательство "Питер", 2000. — 640 с.: ил.
Аксак В.А. Полезные программы для ПК. Просто как дважды два. М.: Эксмо, 2006. – 288 с.: ил.
Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения на практике. – 2-е изд. – СПб.: Питер, 2006. – 575 с.: ил.
Ройс У. Управление проектами по созданию программного обеспечения. Унифицированный подход. – М.: «Лори», 2002. – 424 с.