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

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

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

Рассмотрим в соответствии с [13, 78 – 87] основные понятия объектно-ориентированной методологии создания программного обеспечения (ПО), а также средства стандартного унифицированного языка объектного моделирования (UML – Unified Modelling Language).

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

Объектно-ориентированное моделирование и разработка ПО осуществляются путем последовательного выполнения [13, 78]:

- Объектно-ориентированного анализа (object-oriented analysis – OOA), при котором моделируемая и разрабатываемая системы анализируются с точки зрения классов и объектов, выявленных в предметной области.

- Объектно-ориентированного проектирования (object-oriented design – OOD), при котором путем объектной декомпозиции создается объектная модель разрабатываемой системы.

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

В соответствии с требованиями OOA и OOD для построения объектной модели сложной системы её необходимо представить в канонической форме. Эта форма представления системы включает в себя две ортогональных иерархии: иерархию классов и иерархию объектов [13, 78]. Предполагается, что такая объектно-ориентированная декомпозиция системы, позволяет вскрыть ее полную архитектуру, т.е. структуру классовиструктуру объектов.

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

При этом свойства (состояние и поведение) объектов, как экземпляров классов, в объектной модели, определяет соответствующий класс в иерархии классов, описывающей моделируемую предметную область. Главной же задачей OOA и OOD считается «выбор правильного набора абстракций для описания заданной предметной области» [13, с. 56], что подчеркивает важность концептуального классификационного моделирования в процессе объектно-ориентированной разработки.

Концептуальная база методологии объектно-ориентированного моделирования включает в себя четыре главных взаимосвязанных понятия [13, 78 – 82]: абстрагирование, иерархия, инкапсуляция и модульность.

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

Иерархия – способ упорядочения абстракций (классов) по уровням.

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

Модульность – способ разложения системы на связанные, но относительно самостоятельные части (модули).

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

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

Между классами могут существовать следующие отношения:

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

- Ассоциация – отношение семантической зависимости, показывающее какие роли классы играют друг для друга. Ассоциации различаются по мощности: «один-к-одному», «один-ко-многим», «многое-ко-многим».

- Агрегация – отношение, соответствующее отношению «часть-целое» между объектами данных классов.

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

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

- Модификатор – операция изменения состояния объекта.

- Селектор – операция считывания состояния объекта (без изменения состояния).

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

- Конструктор – операция создания и/или инициализации объекта.

- Деструктор – операция, освобождающая состояние объекта и/или разрушающая сам объект.

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

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

При выявлении структуры объектов моделируемой системы между объектами устанавливаются различные связи (посредством передачи сообщений), представляющие собой «физическое или концептуальное соединение между объектами». Связи обозначают равноправные или «клиент-серверные» отношения между объектами. «Наиболее желательной является функциональная связность, при которой все элементы…тесно взаимодействуют в достижении определенной цели» [13, с. 139]. Участвуя в связях, объект может выполнять одну из трех ролей:

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

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

- агента – при которой объект может быть и активным, и пассивным.

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

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

При проведении OOA и OOD необходимо осуществлять декомпозицию области приложения и разрабатываемой информационной системы. Для обеспечения такой декомпозиции в соответствии с объектно-ориентированным подходом (ООП) используются абстрагирование и иерархия [13, 78]. Однако в настоящее время задача объектно-ориентированной декомпозиции и выделения классов и объектов не имеет законченного формального решения. «Объектно-ориентированная методика позволяет значительно повысить качество и продуктивность разработки программного обеспечения. Однако извлечь из нее выгоду можно только тогда, когда правильно определено множество объектов. Подходящее множество объектов для конкретной области приложения обеспечивает повторное применение системы и возможности ее расширения, а также гарантирует качество и продуктивность потенциальных улучшений, присущих объектно-ориентированной парадигме. Без формальных методов определения объектов разработчики программного обеспечения рискуют остаться просто хакерами на объектном уровне» [32, с. 23].

При этом в литературе по объектно-ориентированному подходу отмечается, что «к сожалению, пока не разработаны строгие методы классификации и нет правила, позволяющего выделять классы и объекты. … Как и во многих технических дисциплинах, выбор классов является компромиссным решением» [13, с. 147]. Существующие методики OOA на сегодняшний день предлагают эвристические правила идентификации классов и объектов, основанные на опыте классификации в других науках. При этом разные авторы предлагают различные наборы базовых классов для объектного моделирования и проектирования. Например, в работе [88] предлагается набор: Осязаемые предметы, Роли, События, Взаимодействие. В работе [89] предлагается следующий набор: Люди, Места, Предметы, Организации, Концепции, События. В работе [90] предлагается такой набор: Структуры, Другие системы, Устройства, События, Разыгрываемые роли, Места, Организационные единицы.

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

Дата добавления: 2014-12-27