2.6. Объектно-ориентированное проектирование – ood

В результате OOD должны быть разработаны для заданной предметной области описанные в предыдущем параграфе диаграммы; кроме них требуется разработать интерфейс пользователя и формы ввода/вывода.

На первом этапе OOD целесообразно работать над диаграммами классов и диаграммой наследования. Состав классов, в принципе, определенна стадии ООА. На стадии OOD он может измениться. Напомним, если класс В является наследником класса А, то это означает что:

В классе В без дополнительного объявления имеются все данные класса А (во многих средах повторное объявления запрещено);

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

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

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

Уже созданные классы (как собственные, так и стандартные) могут для вновь создаваемых классов:

использоваться в качестве базовых,

быть в отношении использования,

быть дружественными или содержать дружественные методы.

Классы А и В находятся в отношении использования, если:

в разделе данных класса А объявлен объект класса В,

какой-либо метод класса А использует объект класса В в разделе своих внутренних данных или в интерфейсной части.

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

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

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

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

Допустим, что диаграммы классов и диаграмма наследования составлены. На следующем этапе целесообразно заняться разработкой интерфейса пользователя, эскизов форм ввода/вывода, схем структур классов и диаграммы зависимостей. В настоящее время программные комплексы всегда снабжены меню, поэтому на этапе OOD необходимо проектировать главное меню. Рекомендуют, чтобы выход их программы был нижним подпунктом самого левого пункта горизонтального меню, а оказание помощи, если оно предусмотрено, самым правым пунктом горизонтального меню.

Модуль 1

Класс А

Модуль 2

Класс В

Модуль 3

Класс С

Классическая структура Объектно-ориентированная

структура

Рис. 2.14. Рис. 2.15.

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

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

обработка исключительной ситуации и продолжение работы;

выдача сообщения пользователю и ожидание его ответа (в диалоговом окне), в зависимости от его ответа продолжение выполнения или останов, при этом пользователь может:

уточнить постановку задачи или исходные данные;

уточнить режимы работы программы в зависимости от возникшей ситуации;

выдача сообщения пользователю и остановка.

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

Чтобы лучше представить себе процесс функционирования событийно-управляемых программ, вспомним, как работает интегрированная среда Turbo Pascal (или С++). Текст программы является исходными данными для транслятора. После этого можно запустить транслятор из меню или с помощью “горячей клавиши”. Предварительно можно уточнить режимы работы в специальном диалоговом окне. Начнется трансляция; в случае обнаружения ошибок выдается диагностическое сообщение, и процесс трансляции прервется. В противном случае будет составляется программа в кодах ЭВМ и начинается процесс решения.

Все элементы интерфейса, к которым мы привыкли, работая в интегрированных средах Borland Pascal и C++ (как в MS/DOS, так и в Windows), могут быть задействованы и в прикладных программах. Вспомним главные из их: главное (MainMenu) и всплывающее (PopUpMenu) меню; “горячие клавиши” (ShortCut); объединенные в группы радиокнопки (RadioButton) – в любой момент времени нажатой может быть одна и только одна кнопка из каждой группы; кнопки выбора (CheckButton) – можно выбрать одновременно 0,1,2,… кнопок; кнопки нажатия (Button), которые закрывают окно и генерируют при этом событие, списки выбора (ListBox).

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

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

Классы А и В не связаны отношением наследования. Тогда возможны следующие варианты их взаимодействия:

Часть методов класса В объявлены дружественными для А. Из класса А можно вызвать дружественные функции, и они имеют неограниченное право доступа к данным и методам А наравне с его собственными методами. Объявление всего класса В дружественным для А означает объявление дружественными всех его методов.

В классе А можно объявить объект класса В (или наоборот), естественно при условии видимости. Тогда из А можно вызвать методы В по общим правилам.

Методы класса А передают сообщение в В (вызывают методы В). Этот случаи наиболее сложен и требует внимательности при реализации, чтобы не возникли операции на неопределенных данных.