Файл: Применение объектно-ориентированного подхода при проектировании информационной системы(Основы объектно-ориентированного подхода).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 24.04.2023

Просмотров: 220

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

ВВЕДЕНИЕ

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

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

Начав формироваться с 80-х годов прошлого века, технология объектно-ориентированного проектирования и программирования стала широко использоваться не только обособленно, но и в связке с другими технологиями. Сегодня практически все языки программирования являются объектно-ориентированными.

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

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

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

– рассмотрены основные положения объектно-ориентированного подхода;

– изучены особенности языка UML для поддержки объектно-ориентированного проектирования;

– рассмотрены программные продукты для объектно-ориентированного проектирования информационных систем на языке UML.

ГЛАВА 1
ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

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

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


Характерными свойствами объектно-ориентированного подхода являются [1,2]:

  • модульность (представление в виде множества модулей).
  • повторное применение существующих и новых модулей.

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

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

  • его не нужно открывать для использования;
  • он имеет некоторые элементы управления (кнопки на корпусе или пульт дистанционного управления);
  • концепция телевизора понятна, даже если он подключен к DVD-плееру;
  • он готов к использованию, когда мы его приобретаем.

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

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

Классы позволяют представлять сложные структуры и включают два компонента [1,2]:

  • состояния (или данные) – это значения, которые имеет объект;
  • методы (или поведение) – это способы, которыми объект может взаимодействовать со своими данными, действиями.

Класс Television (Телевидение) показан на рисунке 1 средствами языка унифицированного языка моделирования (UML).

Рисунок 1. Класс Television (Телевидение)

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

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

Таким образом, будет один набор планов (класс), но могут быть тысячи реальных телевизоров (объектов) [2].

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


Рисунок 2. Пример объектов «Телевизоры»

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

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

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

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

Рисунок 3. Пример интерфейса телевизора

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

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

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

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

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

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

Определение уровня «сокрытия» определенных методов или состояний класса выполняют с использованием общедоступных, закрытых и защищенных ключевых слов [1,3]:

  • публичные методы описывают интерфейс;
  • частные методы описывают реализацию.

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


Частные методы – это написанные методы, которые являются частью внутренней работы телевидения, но не должны быть понятны пользователю. Например, пользователю потребуется вызвать метод powerOn (), но также будет вызван закрытый метод displayPicture(), но внутри, а не напрямую пользователем. Поэтому этот метод не добавляется в интерфейс, а скрывается внутри реализации с использованием ключевого слова private [1-3].

Рисунок 4. Пример инкапсуляции для класса «Телевидение»

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

Этот принцип применяется людьми при категоризации объектов и описаний. Например, на вопрос: «Что такое утка?», можно ответить:

  • птица, которая плавает,

или точнее:

  • птица с перепончатыми лапами, которая плавает.

Таким образом, на рисунке 5 проиллюстрировано отношение наследования между уткой и птицей, согласно которому утка – особый тип птицы [3,4].

Рисунок 5. Пример наследования для класса «Утка»

При необходимости предоставления неструктурированного описания, например, различных транспортных средств, можно указать, что автомобиль-универсал – это автомобиль с очень большим багажником. На рисунке 6 показан пример того, как можно организовать такое описание с использованием наследования [1,4].

Рисунок 6. Пример наследования для нескольких классов

Таким образом, представление является родительско-дочерним. Дочерний класс наследует свойства родительского класса поэтому на рисунке 6 класс Car (Машина) является дочерним по отношению к классу Vehicle (Транспорт), т.е. Car (Машина) наследуется от Vehicle (Транспорт).

Рисунок 7 иллюстрирует отношение между родительским и дочерним классами [1,3].

Рисунок 7. Отношение между родительским и дочерним классом

Один из способов определить, правильно ли организованы классы, – это проверить их с помощью проверок отношений «IS-A» («ЯВЛЯЕТСЯ») и «IS-A-PART-OF» («ЯВЛЯЕТСЯ ЧАСТЬЮ»). Легко спутать объекты внутри класса и потомки класса, поэтому на рисунке 8 приведена проверка предыдущих отношений между автомобилем и транспортным средством [3,4].


Рисунок 8. Проверка отношений в классе

Отношение «IS-A» («ЯВЛЯЕТСЯ») описывает наследование, при этом можно сказать, что «Автомобиль ЯВЛЯЕТСЯ Транспортом» и «Автомобиль седан ЯВЛЯЕТСЯ Транспортом», поэтому все отношения правильные. Отношение «IS-A-PART-OF» («ЯВЛЯЕТСЯ ЧАСТЬЮ») описывает состав (или агрегацию) класса. Таким образом, на рисунке 8 можно выделить «двигатель, являющийся частью транспортного средства», или «двигатель и колеса, являющиеся частью транспортного средства». Это так, даже если Engine (Двигатель) – это тоже класс, включающий много разных описаний двигателя – бензин, дизель, количество клапанов и т. д.

Итак, использование наследования позволяет [3,4]:

  • унаследовать поведение и добавить дополнительное специализированное поведение – например, Car (Машина) IS A Vehicle (Транспорт) с добавлением объектов Колеса, Сидения и т. д.
  • унаследовать поведение и заменить его – например, класс SaloonCar (Седан) унаследует от Car (Машины) и предоставит новую реализацию.
  • сокращение объема кода, который должен быть написан и отлажен – например, в этом случае детализируются только различия, SaloonCar (Седан), по сути, идентичен Car (Машина), и только различия требуют описания.

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

Класс Car также наследует состояния класса Vehicle, такие как isEngineOn, isLightsOn, numberWheels и т. д.

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

При полиморфизме операция может выполняться по-разному для разных классов объектов. Это позволяет манипулировать объектами разных классов, зная только их общие свойства [3,4].

Полиморфизм играет важную роль, позволяя объектам, имеющим разные внутренние структуры, использовать один и тот же внешний интерфейс. Например, объекты разной формы – квадрат, треугольник, круг, показанные на рисунке 9, относятся к общему понятию – фигуры [4].

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