Вход/Регистрация
Технологии программирования
вернуться

Костерин В В

Шрифт:

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

8.9.5. Совместное рассмотрение трех моделей

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

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

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

8.10. ПРИМЕР РЕТРОСПЕКТИВНОЙ РАЗРАБОТКИ ИЕРАРХИИ КЛАССОВ БИБЛИОТЕКИ ВИЗУАЛЬНЫХ КОМПОНЕНТ DELPHI И C++ BUILDER

Delphi и C++ Builder представляет собой визуальное средство разработки корпоративных информационных систем. В C++ Builder используется язык объектно-ориентированного программирования C++, а в Delphi — Object Pascal. Несмотря на это, обе среды используют одни и те же модули библиотеки визуальных компонент, написанных на Object Pascal.

Каждый тип органов управления системы описывается классом, а помещаемые на формы конкретные органы управления являются объектами соответствующих классов. Так, например, Button1, Button2…, ButtonN являются объектами класса TButton; Edit1, Edit2…, EditM — объектами класса TEdit и т. п. Когда пользователь создает форму в визуальной интегрированной среде, он, по сути (в отличие от других органов управления), создает новый класс, объектом которого будет форма, появляющаяся при выполнении приложения (например, класс — TForm1, объект класса — Form1).

С целью уяснения процессов разработки иерархии классов предпримем попытку ретроспективного анализа иерархии классов системы Delphi/C++ Builder.

В процессе анализа была расписана иерархия классов, избранных для примера органов управления, выделены некоторые обязанности, которые мог бы наложить на них разработчик, а затем на основе сравнения списков выделенных обязанностей предпринята попытка обосновать иерархию классов, принятую в средах Delphi/C++ Builder.

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

Рассмотрим органы управления, которые могут быть получены транспортировкой их при помощи мыши с палитры компонент Delphi/C++ Builder.

— TButton — обыкновенная кнопка;

— TRadioButton — радиокнопка (группа кнопок с зависимой фиксацией, обеспечивающей возможность выбора лишь одной кнопки из группы);

— TListBox — обычный список;

— TDBListBox — список для работы с таблицами данных;

— TDataSource — источник данных (является посредником между элементами DataAccess: Table, Query, — и органами управления базами данных DataControls: DBGrid, DBEdit и т. п.).

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

Обязанности объектов класса TDataSource:

— контролировать доступ пользователя к элементам TDataSet;

— обеспечивать возможность определения, подключен ли TDataSource к некоторому элементу TDataSet;

— обеспечивать возможность работы с дочерними компонентами;

— обеспечивать возможность копирования данных в другой объект того же класса;

— обеспечивать возможность уничтожения объекта с высвобождением памяти;

— обеспечивать возможность посылать сообщения;

— определять имя класса, объектом которого является данный элемент.

Обязанности объектов класса TButton:

— обрабатывать сообщения WMLBUTTONDOWN и WMLBUTTONDBLCLK (нажатие и двойное нажатие левой кнопки мыши);

— программно эмулировать нажатие кнопки;

— обрабатывать сообщения от клавиатуры;

— получать фокус ввода;

— определять, имеется ли фокус ввода;

— определять, может ли объект иметь фокус ввода (например, если элемент невидим, ему нельзя передать фокус ввода);

— обрабатывать сообщение BMCLICK (происходит после нажатия кнопки мыши);

— становиться видимым и невидимым;

— перерисовываться;

— обеспечивать возможность перевода точки из системы координат окна в систему координат экрана;

— хранить идентификатор родителя (с возможностью изменить родителя);

  • Читать дальше
  • 1
  • ...
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • ...

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

Полезные ссылки

  • Моя полка

Контакты

  • chitat.ebooker@gmail.com

Подпишитесь на рассылку: