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

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

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

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

Добавлен: 22.04.2023

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

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

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

Введение

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

В начале 70-х годов в Соединённых штатах Америки был отмечен кризис программирования. Кризис был связан с тем, что большинство проектов стали выполнятся с отставанием от заложенного графика, а также с превышением расходов на них. Проекты не обладали необходимыми функциональными возможностями и качество программного обеспечения не устраивало потребителей. Главной причиной неудач становились недостаточно полной формулировкой требований к программному обеспечению, а также недостаточное вовлечение пользователей в работу при проектировании. В решении сложных задач и более четкой связи с пользователями приходит объектно – ориентированный подход к проектированию программного обеспечения.

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

Цель работы: Рассмотреть основные понятия объектно-ориентированного подхода при проектировании ПО

Задачи:

  1. Рассмотреть ориентированного подхода при проектировании ПО;
  2. Познакомится с унифицированным языком моделирования UML
  3. Смоделировать информационную систему посредством использования программного обеспечения IBM Rational Rose

Структура данной работы: введение, глава 1 теоретическая часть, глава 2 практическая часть, заключение, список литературы.

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

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


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

Объект определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины «экземпляр класса» и «объект» являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот с точки зрения изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность - это свойства объекта, отличающие его от всех других объектов.

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

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

Основными механизмами объектной модели являются:

  • абстрагирование (abstraction);
  • инкапсуляция (encapsulation);
  • наследование (inheritance);
  • полиморфизм (polymorphism);
  • модульность (modularity);
  • иерархия (hierarchy).

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

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


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

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

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

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

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

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

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


Кроме того, он отмечает также ряд следующих преимуществ объектно-ориентированного подхода:

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

1.2 UML - унифицированный язык объектно-ориентированного моделирования ИС

В 90-е годы появилось большое количество различных нотаций, поддерживающих объектно-ориентированную методологию проектирования. Самые популярные - ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсону). Каждая из них имела свои преимущества. Мето­дика ОМТ отличалась хорошими средствами анализа и слабыми сторонами в проектировании, а методика Booch 1991, наоборот, более подходила для проек­тирования, чем для анализа. В методике OOSE основное внимание уделено раз­витым средствам поведенческого анализа, а в других областях отмечено много недостатков.

Спустя некоторое время Буч опубликовал второе издание, в котором собрал лучшие идеи и решения в области анализа, предлагавшиеся в том числе Рамбо и Джекобсоном. В свою очередь, Рамбо написал серию статей, известных как методика ОМТ-2, куда вошли предложения Буча в области проектирования. Перечисленные методики были достаточно похожи, но отличались разными нотациями - один и тот же символ имел в них различные значения. Например, закрашен­ный круг был индикатором множественности в методике ОМТ и символом агрегата в нотации Буча. Вы, наверное, слышали фразу «война методов», употреблявшуюся в период, когда класс обозначался либо в виде облака, либо в виде прямоугольника? Трудно понять, что же лучше.


Конец войне методов положила нотация, принятая в языке UML. Язык UML служит для определения, отображения и описания элементов объектно-ориенти­рованных систем в процессе их создания. Он объединяет объектную модель, но­тации Буча и ОМТ, а также лучшие идеи, предложенные авторами других мето­дик. Таким образом, язык UML является стандартом де-факто в области объектно-ориентированного анализа и проектирования.

Универсальный язык UML - это попытка стандартизировать инструменты анализа и проектирования семантических моделей, синтаксических нотаций и диаграмм. Первая общедоступная версия (0.8) появилась в октябре 1995 года. Джекобсон и другие разработчики предложили несколько вариантов, которые были реализованы в последующих двух версиях (0.9 - в июле и 0.91 - в октябре 1996 года). Версия 1.0 была представлена для стандартизации в ассоциацию Object Management Group (OMG) в июле 1997 года. Дополнительные улучше­ния сделаны в версии 1.1, которая вышла в сентябре того же года, а в ноябре UML был утвержден ассоциацией OMG в качестве стандартного языка модели­рования

рис. №16 Составные части языка UML

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

  • диаграммы вариантов использования (use case diagrams) - для моделирования бизнес-процессов организации (требований к системе);
  • диаграммы классов (class diagrams) - для моделирования статической структуры классов системы и связей между ними;
  • диаграммы поведения системы (behavior diagrams):
  • диаграммы взаимодействия (interaction diagrams):
  • диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;
  • диаграммы состояний (statechart diagrams) - для моделирования поведения объектов системы при переходе из одного состояния в другое;
  • диаграммы деятельностей (activity diagrams) - для моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;
  • диаграммы реализации (implementation diagrams):
  • диаграммы компонентов (component diagrams) - для моделирования иерархии компонентов (подсистем) системы;
  • диаграммы размещения (deployment diagrams) - для моделирования физической архитектуры системы.