ОБЪЕКТНАЯ ДЕКОМПОЗИЦИЯ

 

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

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

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

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

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

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

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

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

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

Основной процесс системы − процесс управления рисованием фигур, указанных пользователем. Все команды пользователя должны интерпретироваться, и в результате интерпретации должны формироваться команды на рисование или изменение параметров фигур. Эти процессы мож­но моделировать, используя три объекта: Монитор (блок управления, который получает и интерпретирует команды пользователя) и два объекта − фигуры (см. рис. 7), каждый со своими параметрами.

Рис. 7 − Диаграмма объектов графического редактора

 

 

Фигуры получают следующие сообщения: «Нарисовать», «Изменить цвет контура», «Изменить размер», «Изменить координаты». Все эти сообщения инициируются Монитором в соответствии с командой пользователя. Получив от пользователя команду «Завершить», Монитор прекращает выполнение программы.

Рассмотрим подход объектной декомпозиции к программе «Записная книжка». Попробуем выполнить объектную декомпозицию для программы «Записная книжка», на которой ранее демонстрировалась специфика процедурной декомпозиции (см. рис.4).

Как уже констатировалось ранее, работу с программами такого типа пользователю удобнее осуществлять через меню. Значит, при запуске программы на экране должно появиться меню, содержащее набор возможных операций. В зависимости от выбора пользователя далее будут активизироваться части программы, ответственные за открытие «книжки», добавление записей или за поиск записей (рис. 8).

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

Добавим к системе еще несколько видимых объектов – сообщений пользователю, которые будут появляться на экране при обнаружении несоответствий в процессе работы, например «Записная книжка не найдена» − активизируется Открытием книжки или «Нет информации об абоненте» − активизируется Поиском записей (рис. 9).

 

Рис.8 −Диаграмма состояний интерфейса пользователя

(первый вариант)

Рис. 9 − Полная диаграмма состояний интерфейса пользователя

 

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

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

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

Все операции с файлом будет выполнять объект Файл.

Окончательный вариант объектной декомпозиции проектируемой системы представлен на рис. 10 (сравните с результатами процедурной декомпозиции для той же программы, приведенными на рис. 4).

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

1) Для сложных систем объектная декомпозиция должна выполняться поэтапно: на первом этапе – объектная декомпозиция всей системы, на последующих – декомпозиция объектов как подсистем.

2) При декомпозиции системы в целом в качестве объектов могут выделяться элементы двух типов:

- элементы интерфейса пользователя (окна меню, окна сообщений, окна форм ввода-вывода и т.д.);

- средства хранения, организации и преобразования данных (базы данных, файлы, протоколы, структуры данных и т.д.).

Рис. 10 − Диаграмма объектов системы «Записная книжка»

 

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

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