Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 70
Текст из файла (страница 70)
14.9. Выбор стратегии управления программным обеспечением 301 Вы можете выполнить логическое разбиение ресурса, распределив его части по разным охраняющим объектам, благодаря чему будет реализован параллельный доступ к частям ресурса. Например, в параллельной распределенной среде одной из стратегий выделения идентификаторов объектов является предварительное распределение диапазонов возможных идентификаторов между процессорами, входящими в состав сети. Каждый процессор выделяет идентификаторы из предоставленного ему диапазона, благодаря чему исчезает потребность в глобальной синхронизации. В приложениях, предъявляющих жесткие требования к временным ограничениям, стоимость доступа к ресурсу через охраняющий объект иногда оказывается слишком высока.
Клиенты в таких системах должны работать с ресурсом напрямую. В этом случае блокировка может быть установлена на отдельные части ресурса. Блокировка — это логический объект, связанный с некоторым подмножеством ресурса, который дает владельцу блокировки право на непосредственный доступ к ресурсу. Охраняющий объект в этом случае тоже должен существовать, он занимается выдачей и снятием блокировки, однако после одной операции взаимодействия с охраняющим объектом для получения блокировки клиент может работать с ресурсом напрямую.
Такой подход опаснее, потому что каждый пользователь ресурса сам отвечает за свое поведение при работе с этим ресурсом. Не используйте прямой доступ к общим ресурсам, если есть другие варианты. Пример с банкоматом. В нашем случае глобальными ресурсами являются банковские коды и номера счетов. Код банка должен быть уникален в контексте консорциума. Номер счета должен быть уникален в контексте банка. И.9. Выбор стратегии управления программным обеспечением В аналитической модели взаимодействия представляются как события, передаваемые между объектами.
Аппаратное обеспечение в этом отношении близко аналитической модели, а вот в программном обеспечении управление может быть реализовано несколькими способами. Не обязательно, чтобы все подсистемы использовали одну и ту же реализацию, но лучше всего выбирать для всей системы единый стиль управления.
Существует два основных варианта управления программной системой: внешнее управление и внутреннее управление. Внешнее управление (ехгегпа! сон!го!) — это поток видимых извне событий между объектами системы. Существует три варианта управления, осуществляемого через внешние события: процедурное последовательное, событийное последовательное и параллельное. Оптимальный вид управления зависит от доступных ресурсов (предоставляемых языком программирования и операционной системой), а также от видов взаимодействия внутри приложения.
Внутреннее управление ((псегпа! сопгго!) — это поток управления внутри процесса. Оно появляется только на этапе реализации, а потому нельзя сказать, что ему изначально присущи параллельность или последовательность. Проектировщик может разбить процесс на несколько задач для обеспечения логической 302 Глава 14 ° Проектирование системы ясности или для повышения производительности (в случае наличия нескольких процессоров).
В отличие от внешних событий внутренние переходы управления (например, вызовы процедур или вызовы между задачами) находятся под контролем программы и могут быть структурированы так, как удобно. Широко распространены три типа операций передачи управления: вызовы процедур, квазипараллельные вызовы между задачами и параллельные вызовы между задачами. Квазипараллельные задачи (сопрограммы или программные потоки) — это конструкции, разработанные для удобства программиста. Каждый программный поток обладает собственным стеком и адресным пространством, но только один из них может быть активен в конкретный момент времени.
И.9.1. Процедурное управление В последовательной системе с процедурным управлением ход выполнения определяется кодом программы. Процедуры запрашивают внешние данные и ждут их поступления. Когда входные данные поступают в систему, выполнение программы возобновляется с той процедуры, которая запрашивала эти данные. Значение счетчика команд, содержимое стека вызовов процедур и значения локальных переменных в этом случае определяют состояние системы. Основное преимущество процедурного управления состоит в том, что его легко реализовать в большинстве широко распространенных языков. Недостаток же в том, что этот вариант требует отображения присущей объектам параллельности на последовательный поток управления. Проектировщик должен преобразовьн вать события в операции между обьектами.
Обычно операция соответствует паре событий: событию вывода, которое выполняет вывод и запрашивает ввод, и событию ввода, которое доставляет в систему новые значения. Эта парадигма неудобна для описания асинхронного ввода, потому что программа должна явным образом запрашивать входные данные. Процедурное управление пригодно только в том случае, если модель состояний демонстрирует регулярное чередование событий ввода и вывода. Более гибкие пользовательские интерфейсы и системы управления построить на основе этой парадигмы достаточно сложно. Обратите внимание, что основные объектно-ориентированные языки, такие как С++ и ) ата, являются процедурно-ориентированными. Пусть вас не вводит в заблуждение словосочетание «передача сообщений».
Сообщение — это вызов процедуры со встроенным оператором сазе, зависящим от класса целевого объекта. Основной недостаток обычных объектно-ориентированных языков в том, что они не поддерживают присущую объектам параллельность. Существуют и параллельные объектно-ориентированные языки, но они пока распространены недостаточно широко. И.9.2. Событийное управление В последовательной системе, управляемой событиями, контроль осуществляет диспетчер или монитор, предоставляемый языком или операционной системой или выполненный в виде отдельной подсистемы.
Разработчики связывают процедуры приложения с событиями, и диспетчер вызывает эти процедуры, когда 14.9. Выбор стратегии управления программным обеспечением 303 происходят соответствующие им события. Процедуры передают диспетчеру выходные данные или разрешают ввод входных данных, но они не блокируются в ожидании их поступления. Все процедуры возвращают управление диспетчеру (а не сохраняют его до тех пор, пока не будут получены какие-либо данные).
Поэтому состояние системы ие может быть описано счетчиком программы и стеком. Процедуры должны использовать глобальные переменные для сохранения информации о состоянии, или же локальная информация о состоянии должна поддерживаться диспетчером. Событийное управление реализовать иа стандартных языках сложнее, чем процедурное, ио результат во многих случаях стоит затраченных усилий. Управляемые событиями системы получаются более гибкими, чем процедурные.
Такие системы моделируют сотрудничество процессов внутри одной многопоточной задачи. Неправильно написанная процедура может заблокировать все приложение, поэтому разработчикам приходится быть внимательными. Особенно удобными получаются событийные подсистемы пользовательского интерфейса.
Используйте управляемую событиями систему для внешнего управления вместо процедурной везде, где это возможно, потому что преобразование событий в программные конструкции в этой парадигме выполнять проще. Такие системы получаются «более модульными» и лучше обрабатывают аварийные ситуации, чем процедурные системы. 14.9.3. Параллельное управление В параллельной системе управление осуществляется несколькими независимыми объектами параллельно. Каждый из таких объектов представляет собой отдельную задачу.
В этой системе события реализуются как односторонние сообщения (ие такие, как «сообщения» в объектно-ориентированных языках) между объектами. Задача может ожидать ввода данных, но другие задачи при этом продолжают выполняться. Операционная система планирует выполнение задач и предоставляет механизм постановки событий в очередь, поэтому события ие теряются в том случае, если задача в момент их поступления занята чем-то другим. В случае наличия нескольких процессоров разные задачи выполняются действительно параллельно.