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

Содержание:

Введение

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

С 1980-х годов слово «объект» появилось по отношению к языкам программирования, причем почти все языки, разработанные с 1990 года, обладают объектно-ориентированными функциями. Некоторые языки даже имеют объектно-ориентированные функции, встроенные в ретро. Широко признано, что объектно-ориентированное программирование является наиболее важным и мощным способом создания программного обеспечения.

Подход объектно-ориентированного программирования поощряет:

1. Модуляризацию, где приложение может быть разложено на модули.

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

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

1. Классы.

2. Объекты.

2. Инкапсуляция.

3. Полиморфизм.

4. Наследование.

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

Целью данной курсовой работы является изучение понятий объектно-ориентированного программирования.

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

1. Изучить теорию ООП.

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

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

1.1. Объектно-ориентированный класс

Если мы подумаем об объекте реального мира, таком как телевизор (как на рисунке 1), он будет иметь несколько функций и свойств:

1. Нам не нужно вскрывать телевизор для его использования.

2. У нас есть некоторые элементы управления, чтобы использовать его (кнопки на телевизоре или пульт дистанционного управления).

3. Мы все еще можем понять концепцию телевизора, даже если он подключен к DVD-плееру.

4. Когда мы приобретаем телевизор, то он хорошо укомплектован и имеется соответствующая документация.

5. Телевизор не сломается!

Во многих отношениях это очень хорошо сравнивается с понятием класса.

Рисунок - Понятие класса – телевизор в качестве примера

Класс должен:

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

2. Представлять четкую концепцию – например, концепцию телевидения.

3. Быть укомплектованным и хорошо задокументированным – у телевизора должна быть вилка и руководство, которое документирует все функции.

4. Код должен быть надежным - он не должен падать, как телевизор.

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

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

Свойства – это значения, которые имеет объект.

Методы – это способы, которыми объект может взаимодействовать со своими данными, действиями.

Обозначение, используемое на рисунке 2 справа, представляет собой представление Телевизора диаграммы UML для класса объектно-ориентированного моделирования и программирования.

Экземпляр класса называется объектом.

Рисунок – Пример класса

1.2. Объект

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

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

Рисунок – Пример класса и объектов

1.3. Инкапсуляция

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

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

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

Полная реализация класса - это сумма открытого интерфейса плюс частная реализация.

Рисунок – Пример интерфейса

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

Для пользователя (который может быть другим программистом):

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

Для программиста:

• Программист может изменить реализацию, но не должен уведомлять пользователя.

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

Мы можем определить уровень «прячась» конкретных методов или состояний в пределах одного класса, используя public, private и protected ключевые слова:

1. public методы - описывают интерфейс.

2. private методы - описывают реализацию.

На рисунке 5 показана инкапсуляция в отношении Television класса. Согласно нотации UML, частные методы обозначаются знаком минус, а открытые методы обозначаются знаком плюс. Приватные методы – это написанные методы, которые являются частью внутренней работы телевидения, но не должны быть понятны пользователю. Например, пользователь должен будет вызвать powerOn() метод, но частный displayPicture() метод также будет вызван, но внутри, как требуется, а не напрямую пользователем. Поэтому этот метод не добавляется в интерфейс, а скрывается внутри реализации с использованием private ключевого слова.

Рисунок – Пример класса, показывающего инкапсуляцию

1.4 Наследование

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

Люди используют эту концепцию в категоризации объектов и описаний. Например, вы, возможно, ответили на вопрос - «Что такое утка?», С «птицей, которая плавает», или, еще точнее, «птицей, которая плавает, с перепончатыми ногами и счетом вместо клюва». Таким образом, мы можем сказать, что утка - это птица, которая плавает, поэтому мы могли бы описать это как на рисунке 6. Этот рисунок иллюстрирует отношения наследования между a Duck и a Bird. По сути, мы можем сказать, что Duck это особый тип Bird.

Рисунок – Класс, демонстрирующий наследование

Например: если нужно было дать неструктурированную группу описаний, таких как «Автомобиль», «Салон», «Универсал», «Фургон», «Автомобиль», «Мотоцикл» и «Скутер», и попросить упорядочить эти описания по их различиям. Вы можете сказать, что автомобиль Saloon - это Автомобиль, но имеет длинный багажник, тогда как автомобиль-универсал - это автомобиль с очень большим багажником. На рисунке 7 показан пример того, как мы можем организовать эти описания, используя наследование.

Рисунок – Сгруппированный набор классов

Таким образом, мы можем описать это отношение как отношение ребенок / родитель, где рисунок 8 иллюстрирует отношение между базовым классом и производным классом. Производный класс наследует от базового класса, поэтому на рисунке 7 Car класс является дочерним по отношению к Vehicle классу, поэтому Car наследуется от Vehicle.

Рисунок - Базовый класс и Производный класс

Один из способов определить, правильно ли вы организовали свои классы, - это проверить их с помощью проверок отношений «IS-A» и «IS-A-PART-OF». Легко спутать объекты внутри класса и потомков классов, когда вы впервые начинаете программирование с методологией ООП. Итак, чтобы проверить предыдущие отношения между Car и Vehicle, мы можем увидеть это на рисунке 9.

Рисунок 9 - Отношения IS-A / IS-A-PART-OF и Vehicle класс

1.5 Полиморфизм

Когда класс наследует от другого класса, он наследует как состояния, так и методы этого класса, поэтому в случае, когда Car класс наследует от Vehicle класса, Car класс наследует методы Vehicle класса, такие как engineStart(), gearChange() и lightsOn() и т.д. Car класс также наследует состояния Vehicle класса, такие как isEngineOn, isLightsOnи numberWheels и т. д.

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

1.5.1 Переопределение методов

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

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

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

Рассмотрим предыдущий пример Vehicle диаграммы классов на рисунке 7. В этом случае Car наследуется от Vehicle и от этого класса, Car существуют дополнительные производные классы SaloonCar и EstateCar. Если draw()метод добавлен к Car классу, это необходимо для рисования общего автомобиля. Этот метод не сможет адекватно нарисовать универсал или другие детские классы. Over-Riding позволяет нам написать специализированный draw() метод для EstateCar класса. Нет необходимости писать новый draw() метод для SaloonCar класса, поскольку Car класс предоставляет достаточно подходящий draw() метод. Все, что нам нужно сделать, это написать новый draw() метод в EstateCar классе с точно таким же именем метода. Итак, Over-Riding позволяет:

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

2. Лучший уровень абстракции, в котором механизмы реализации остаются скрытыми.

1.5.2 Перегрузка методов

Перегрузка - вторая форма полиморфизма. Можно использовать одно и то же имя метода, но количество параметров или типы параметров могут отличаться, что позволяет компилятору выбрать правильный метод. Например, add (int x, int y) и add (String x, String y) это два разных метода, которые имеют одинаковое имя и одинаковое количество параметров. Однако, когда мы передаем два String объекта вместо двух переменных типа int, мы ожидаем, что их функциональность будет другой. Когда мы добавляем два значения типа int, мы ожидаем результат типа int - например, 6 + 7 = 13. Однако, если мы передадим два String объекта, мы ожидаем результат "6" + "7" = "67". Другими словами, строки должны быть объединены.

Количество аргументов также может определять, какой метод должен быть запущен. Например, channel() и channel(int x) обеспечивают различные функциональные возможности, где первый метод может просто отображать текущий номер канала, но второй метод установит номер канала на переданный номер.

1.6. Абстрактные классы

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

Не может быть создан.

Таким образом, может использоваться только через наследование.

Например: в Vehicle примере с классом ранее draw() метод может быть определен как абстрактный, так как на самом деле невозможно нарисовать общий носитель. Делая это, мы заставляем все производные классы написать draw() метод, если они должны быть созданы.

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

Рисунок 11 иллюстрирует этот пример. Он draw() был написан во всех классах и имеет некоторую функциональность. Объект draw() in Vehicle был помечен как абстрактный, и поэтому этот класс не может быть создан, т.е. мы не можем создать объект этого Vehicle класса, поскольку он неполный. На рисунке 11 метод SaloonCar не имеет draw() метода, но он наследует draw() метод от родительского Car класса. Следовательно, можно создавать объекты SaloonCar.

Рисунок – Абстрактный draw() метод в Vehicle классе

Если бы мы потребовали, мы могли бы также пометить draw() метод как абстрактный в производном классе, например, мы могли бы также пометить draw() как абстрактный в Car классе. Это будет означать, что вы не сможете создать объект Car класса и передадите ответственность за реализацию draw() метода его дочерним элементам - см. Рисунок 12.

Рисунок – Абстрактный draw() метод в Vehicle и Car классах

1.7 Выводы

Таким образом в данной главе мы описали теорию объектно-ориентированного подхода на практике, а именно:

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

2. При описании очередного понятия, были приведены примеры и графические иллюстрации.

2. Объектно-ориентированный анализ и дизайн

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

Зачем использовать объектно-ориентированный подход? Рассмотрим общий цикл, который проходит программист, чтобы решить задачу программирования:

1. Сформулируйте проблему – программист должен полностью понять проблему.

2. Проанализируйте проблему – программист должен найти важные концепции проблемы.

3. Дизайн – программист должен разработать решение на основе анализа.

4. Код – наконец, программист пишет код для реализации проекта.

1.7.1 Модель водопада

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

Рисунок – Модель водопада

Семь этапов процесса, как показано на рисунке 13:

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

2. Анализ: требования должны быть проанализированы, чтобы сформировать исходную модель системы программного обеспечения.

3. Проектирование: этап проектирования включает в себя подробное определение входных, выходных данных и обработки, необходимых для компонентов модели программного комплекса.

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

5. Системные тесты: После завершения фазы кодирования выполняются системные тесты, чтобы найти как можно больше ошибок программного обеспечения. Это выполняется разработчиком до того, как программное обеспечение передается клиенту. Клиент может проводить дополнительные тесты или проводить совместные тесты с разработчиком.

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

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

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

1.7.2 Спиральная модель

Спиральная модель была предложена Сет (1988) в качестве методологии для контроля за крупные проекты разработки программного обеспечения масштаба, которые показывают высокие перспективы для отказа. Это итерационная модель, которая строит анализ риска и формальное участие клиента в разработке прототипа. Эта модель может быть проиллюстрирована как на рисунке 14.

Рисунок – Спиральная модель

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

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

1.7.3 Объектно-ориентированная модель проектирования

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

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

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

Рисунок – Объектно-ориентированная модель проектировая

2. Разработка интернет магазина с помощью объектно-ориентированного подхода

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

2.1 Выбранное средство для моделирования

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

IBM Rational Rose - популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Инструментальное средство IBM Rational Rose расширяет возможности моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

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

2.2 Преимущества Rational Rose

Популярное средство визуального моделирования объектно-ориентированных информационных систем компании Rational Software Corp. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language).

Благодаря уникальному языку моделирования Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования.

Только Rose позволяет разрабатывать как высокоуровневые, так и низкоуровневые модели, осуществляя тем самым либо абстрактное проектирование, либо логическое.

Только Rational Rose имеет весь необходимый набор визуальных средств проектирования. Только Rose поможет решить проблемы с кодогенерацией на определенном языке программирования.

Только Rational Rose осуществляет такие подходы, как прямое и обратное проектирование, а так-же Round Trip Engineering. Такой арсенал позволит не только проектировать новую систему, но и доработать старую, произведя процесс обратного проектирования.

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

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

Для специалистов по БД и аналитиков данных - Rational Rose является единым инструментом, языком и нотацией для всей команды. Rational Rose Data Modeler обеспечивает поддержку БД, включая объектно-ориентированное отображение (mapping), генерацию схем и итерационную разработку.

Для разработчиков на Visual Studio и WinDNA - Rational Rose плотно интегрируется с MS Visual Studio и обеспечивает поддержку семантики и схемы WinDNA, визуализацию и итерационную разработку кода COM/ATL, MTS и ADO, настройку и открытую разработку шаблонов для генерации многоуровневых приложений WinDNA.

Для интернет-разработчиков и XML-разработчиков - Rational Rose является единственным решения, которое обеспечивает понятную визуализацию интернет-архитектуры, включая Web Application Extension для UML, обратное проектирование семантики из JSP- и ASP-файлов, автоматизацию Web Application Extension для UML, визуализацию самых сложных по структуре интернет-сайтов и улучшенную поддержку XML.

Для Java- и EJB-разработчиков - использование Rational Rose обеспечивает качественную поддержку всех аспектов разработки: разработку архитектур "тонкого" клиента, полную поддержку моделирования Enterprise Java Beans, полную интеграцию с такими распространенными Java IDE, как JBuilder, Visual Age, Forte и Visual Cafe, а также совместим со всеми поддерживаемыми версиями J2SE и J2EE.

Ускорение разработки архитектуры ПО

Только хорошо спроектированные приложения могут отвечать требованиям заказчика и быстро адаптироваться к изменившимся условиям ведения бизнеса. Для решений на WinDNA, Enterprise Java, Web и XML или для встроенных приложений Rational Rose ускоряет разработку, используя проверенные архитектурные модели для каждого из решений.

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

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

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

2.3. Анализ предметной области

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

Интернет – магазин также может быть назван электронной веб-магазин, интернет-магазин, е-магазин, интернет - магазин, интернет-магазин, интернет-магазин, интернет - магазин, интернет - магазина и виртуальный магазин.

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

2.4. Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

2.4.1. Диаграмма вариантов использования

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

Варианты использования – это набор действий, сервисов и функций, которые должна выполнять система. В этом контексте «система» – это то, что разрабатывается или эксплуатируется, например, веб-сайт.

«Действующие лица» – это люди или организации, действующие под определенными ролями в системе.

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

Рисунок – Диаграмма вариантов использования

2.4.2 Диаграмма последовательности по решаемой задаче

Диаграмма последовательности (Sequence Diagram) – диаграмма, на которой показаны взаимодействия объектов, упорядоченные по времени их проявления.

Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники), вертикальные линии (англ. lifeline), отображающие течение времени при деятельности объекта, и стрелки, показывающие выполнение действий объектами. На данной диаграмме объекты располагаются слева направо. Ее недостатком является то, что она занимает много места.

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

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

На рисунке 17 приведена диаграмма деятельности, на которой рассмотрен процесс покупки товара в интернет магазине.

Рисунок – Диаграмма последовательности, заказ сырья и материалов

2.4.3 Диаграмма деятельности по решаемой задаче

Диаграмма деятельности является ещё одной важной диаграммой в UML, описывающей динамические аспекты системы.

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

На рисунке 18 представлена диаграмма деятельности демонстрирующая последовательность действий при покупке клиентом товаров и услуг в определённом интернет магазине.

Рисунок – Диаграмма деятельности, определение потребности и работа с поставщиком

2.4.4 Диаграмма состояний по решаемой задаче

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

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

Рисунок – Диаграмма состояний подразделения «Отдел закупок»

2.4.5 Диаграмма классов

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

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

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

Рисунок – Диаграмма классов, структура отдела закупок

2.5 Тестирование программного средства

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

Рисунок – Главное окно программы

Внизу формы отображается описание интернет магазина, товара и услуги.

После выбора, укажем данные покупателя и нажмём на кнопку «Купить».

В результате вся информация отобразится в поле richtextbox.

Рисунок – Покупка товара

2.6 Выводы

Таким образом в данной главе мы продемонстрировали объектно-ориентированный подход на практике, а именно:

1. Определили предметную область.

2. Выбрали средство для моделирования и описали его преимущества.

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

4. По спроектированным диаграммам реализовали приложение.

Заключение

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

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

Список использованных источников

1. Зегжда, Д.П. Основы безопасности информационных систем / Д.П. Зегжда, А.М. Ивашко. - М.: Горячая линия - Телеком, 2017. - 452 c.

2. Буч, Грейди Язык UML. Руководство пользователя / Грейди Буч, Джеймс Рамбо , Айвар Джекобсон. - М.: ДМК, 2015. - 432 c.

3. Язык программирования C# / А. Хейлсберг и др. - М.: Питер, 2016. - 784 c.

4. Перлова, О.Н. Проектирование и разработка информационных систем: Учебник / О.Н. Перлова, О.П. Ляпина, А.В. Гусева. - М.: Academia, 2017. - 416 c.

5. Управление поставщиками/Ш.Вагнер – М.,2013

6. Объектно-ориентированное конструирование программных систем / Бертран М.– М.,2013

7. Программирование. Объектно-ориентированный подход. Учебник и практикум / Зыков С. В.– М.,2013

Приложение А

using System;

using System.Collections.Generic;

using System.Windows.Forms;

namespace WindowsFormsApp2

{

public partial class BuyProtuct : Form

{

List<Service> SelectServisesClient = new List<Service>();

List<Online_Store> Online_Stores = new List<Online_Store>();

List<Product> Products = new List<Product>();

List<Client> Visitors = new List<Client>();

List<Service> Services = new List<Service>();

List<BuyProduct> CheckInHotels = new List<BuyProduct>();

public BuyProtuct()

{

InitializeComponent();

Online_Stores.Add(new Online_Store { Name = "Интернет магазин 'DNS'", Adress = "Ростов-на-Дону, улица Ленина 21", Description = "Магазин бытовой техники и электроники" });

Online_Stores.Add(new Online_Store { Name = "Интернет магазин 'Моя мебель'", Adress = "Ростов-на-Дону, улица Красноармейская 142", Description = "Салон мебели" });

Products.Add(new Product { NameProduct = "Игровой компьютер", Description = "Компьютер, разработанный для видеоигр", Price = 1000 });

Products.Add(new Product { NameProduct = "Телевизор", Description = "Качественный телевизор", Price = 5000 });

Products.Add(new Product { NameProduct = "Диван", Description = "Кожаный дивай", Price = 9000 });

Products.Add(new Product { NameProduct = "Кровать", Description = "Спальная двухместная кровать", Price = 1500 });

Services.Add(new Service { Name = "Установка", Description = "Полезный сервис", Price = 500 });

Services.Add(new Service { Name = "Настройка", Description = "Полезный сервис", Price = 1000 });

Services.Add(new Service { Name = "Доставка", Description = "Полезный сервис", Price = 1500 });

//Привязываем товара к магазину

Online_Stores[0].Numbers.Add(Products[0]);

Online_Stores[0].Numbers.Add(Products[1]);

Online_Stores[1].Numbers.Add(Products[2]);

Online_Stores[1].Numbers.Add(Products[3]);

//Привязываем услуги к номерам

Products[0].Services.Add(Services[0]);

Products[0].Services.Add(Services[1]);

Products[1].Services.Add(Services[2]);

Products[2].Services.Add(Services[0]);

Products[2].Services.Add(Services[1]);

Products[2].Services.Add(Services[2]);

Products[3].Services.Add(Services[1]);

Products[3].Services.Add(Services[2]);

comboBoxOnlineStore.DataSource = Online_Stores;

comboBoxOnlineStore.DisplayMember = "Name";

comboBoxProduct.DataSource = Online_Stores[comboBoxOnlineStore.SelectedIndex].Numbers;

comboBoxProduct.DisplayMember = "NameProduct";

comboBoxServices.DataSource = Products[comboBoxProduct.SelectedIndex].Services;

comboBoxServices.DisplayMember = "Name";

}

private void comboBoxOnlineStore_SelectedIndexChanged(object sender, EventArgs e)

{

labelInfoHotel.Text = Online_Stores[comboBoxOnlineStore.SelectedIndex].Description;

}

private void comboBoxProduct_SelectedIndexChanged(object sender, EventArgs e)

{

labelInfoNumber.Text = Products[comboBoxProduct.SelectedIndex].Description;

}

private void comboBoxServices_SelectedIndexChanged(object sender, EventArgs e)

{

labelInfoServices.Text = Services[comboBoxServices.SelectedIndex].Description;

}

private void buttonServices_Click(object sender, EventArgs e)

{

listServices.Items.Add(comboBoxServices.Text);

SelectServisesClient.Add(Services[comboBoxServices.SelectedIndex]);

}

private void buttonDeleteServices_Click(object sender, EventArgs e)

{

SelectServisesClient.RemoveAt(listServices.SelectedIndex);

listServices.Items.RemoveAt(listServices.SelectedIndex);

}

private void buttonAddBuyProduct_Click(object sender, EventArgs e)

{

string resultString;

Client client = new Client

{

Name = textBoxName.Text,

Surname = textBoxSurname.Text,

Price = textBoxPrice.Text

};

BuyProduct checkInHotel = new BuyProduct

{

SelectedOnlineStore = Online_Stores[comboBoxOnlineStore.SelectedIndex],

SelectedProduct = Products[comboBoxProduct.SelectedIndex],

SelectServices = SelectServisesClient,

SelectedClient = client

};

resultString = $"Клиент {client.Surname} {client.Name} покупает в магазине '{Online_Stores[comboBoxOnlineStore.SelectedIndex].Name}' товар '{Products[comboBoxProduct.SelectedIndex].NameProduct}' и пользуется следующими услугами:";

for (int i = 0; i < SelectServisesClient.Count; i++)

{

if (i==SelectServisesClient.Count-1)

resultString += SelectServisesClient[i].Name;

else

resultString += SelectServisesClient[i].Name + ", ";

}

richTextBox.AppendText(resultString);

}

}

public class Online_Store

{

public string Name { get; set; }

public string Adress { get; set; }

public string Description { get; set; }

public int Rating { get; set; }

public List<Product> Numbers { get; set; } = new List<Product>();

}

public class Product

{

public string NameProduct { get; set; }

public string Description { get; set; }

public int Price { get; set; }

public List<Service> Services { get; set; } = new List<Service>();

}

public class Client

{

public string Name { get; set; }

public string Surname { get; set; }

public string Price {get;set;}

}

public class Service

{

public string Name { get; set; }

public string Description { get; set; }

public int Price { get; set; }

}

public class BuyProduct

{

public Online_Store SelectedOnlineStore { get; set; }

public Product SelectedProduct { get; set; }

public Client SelectedClient { get; set; }

public List<Service> SelectServices { get; set; } = new List<Service>();

}