Декомпозиция задачи и инкапсуляция ее решения

Проектирование объектно-ориентированного программного обеспечения — это процесс перевода требований к ПО в проект, в котором с помощью объектов моделируется каждый аспект разрабатываемой системы и выполняемой ею работы. Центральное место в этом проекте отводится структуре и иерархии коллекций объектов, а также их взаимоотношениям и взаимодействиям. Для поддержки понятия модели ПО в С++ используется ключевое слово class. Существует два базовых типа моделей. Первый тип модели — масштабированное представление некоторого процесса, концепции или идеи. Этот тип модели используется для анализа или экспериментирования. Например, класс применяется для разработки модели молекулы, т.е. с помощью концепции С++-класса можно смоделировать гипотетическую структуру некоторого химического процесса, происходящего в молекулах. Программным путем можно затем изучить поведение молекулы при внедрении новых групп атомов. Второй тип модели ПО — воспроизведение некоторой реальной задачи, процесса или идеи. Цель этой модели — заставить некоторую часть системы ПО или приложения функционировать подобно ее «прототипу». В этом случае ПО занимает место некоторого компонента или некоторого физического предмета в неавтоматизированной системе. Например, мы можем использовать концепцию класса для моделирования калькулятора. При корректном моделировании всех его характеристик и поведения можно создать экземпляр этого класса и использовать в качестве настоящего калькулятора. Программный калькулятор здесь будет играть роль реального калькулятора. Таким образом, смоделированный нами класс может служить в качестве виртуального лублера некоторого реального лица, места, предмета или идеи. Главное в программной модели — ухватить суть реального предмета.

Декомпозиция (decomposition) — это процесс разделения задачи и ее решения на ряд подзадач, коллекций объектов и принципов взаимоотношений между этими объектами. Аналогично инкапсуляция (encapsulation) — это моделирование характеристик, атрибутов и поведения некоторого лица, места, предмета или идеи с помощью С++-конструкции class. Такое моделирование (инкапсуляция) и декомпозиция являются частью этапа проектирования объектно-ориентированного ПО. Объектно-ориентированные приложения, которые содержат распределенные объекты, вносят в процесс проектирования дополнительный уровень сложности. С точки зрения «чистого» проектирования местоположение объектов в приложении не должно влиять на разработку атрибутов и характеристик этих объектов. Класс — это модель и, если местоположение не является частью этой модели, то даже самое «крайнее» расположение объектов (экземпляров этого класса) не должно иметь значение. Однако объекты существуют не в вакууме. Они взаимодействуют и обмениваются информацией с другими объектами. Если объекты (участники взаимодействия) расположены на разных компьютерах, и, возможно, даже в различных сетях, то оказывается, что фактор местоположения объектов необходимо с самого начала включать в процесс проектирования ПО. И хотя насчет того, на каком именно этапе проектирования следует рассматривать этот фактор, специалисты существенно расходятся во мнениях, тем не менее все единолушны в том, что его необходимо рассматривать. Дело в том, что обработка ошибок и исключений при взаимодействии объектов, расположенных в различных процессах или на различных компьютерах, отличается от обработки ошибок и исключений при взаимодействии объектов одного и того же процесса. Кроме того, связи и взаимодействия между объектами одного процесса реализуются совершенно не так, как при расположении объектов в различных процессах, которые могут выполняться на разных компьютерах. Это нужно иметь в виду еще на раннем этапе проектирования. В распределенном объектно-ориентированном приложении вся его работа делится между объектами и реализуется в виде функций-членов различных объектов. Объекты должны быть логически разделены согласно определенной модели декомпозиции работ (Work Breakdown Model — WBM). Они могут быть разделены согласно моделям типа «клиентс - сервер», «изготовитель-потребитель», равноправных узлов, «классной доски» или мультиагентной системы. Логическая структура каждой такой модели (с особенностями распределения объектов) показана на рис. 8.1.

Во всех моделях, показанных на рис. 8.1, предполагается, что объекты могут быть на одном и том же или на разных компьютерах (главное — они принадлежат разным процессам). Уже сам факт принадлежности рааличным процессам делает объекты распределенными ¹³. Все модели представляют рааличные подходы к распределению работы приложения между объектами.