Файл: Основные понятия объектно-ориентированного программирования.pdf

Перегрузка - вторая форма полиморфизма. Можно использовать одно и то же имя метода, но количество параметров или типы параметров могут отличаться, что позволяет компилятору выбрать правильный метод. Например, 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 способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования.