Камерон Хьюз - Параллельное и распределенное программирование на С++

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

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

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

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

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

• Объекты реализованы в SPMD- или МРМП-архитектуре, рассчитанной на использование параллельного программирования, причем эти объекты расположены в различных процессах и на различных компьютерах.

В объектно-ориентированном приложении выполняемая программой работа делится между несколькими объектами. Эти объекты представляют собой модели определенной реальной личности, реального места, предмета или идеи. Выполнение объектно-ориентированной программы вынуждает ее объекты взаимодействовать между собой в соответствии с правилами, заложенными в этой модели. В распределенном объектно-ориентированном приложении некоторые взаимодействующие объекты будут создаваться различными программами, которые, возможно, выполняются на различных компьютерах. В главе 3 упоминалось о том, что каждая выполняемал программа включает один или несколько процессов. Каждый процесс обладает собственными ресурсами. Например, любой процесс имеет собственную память, дескрипторы файлов, стековое пространство, идентификатор и т.п. Задачи, выполняемые в одном процессе, не имеют прямого доступа к ресурсам, принадлежащим другому процессу. Если задачам, выполняемым в одном процессе, необходима информация, хранимая в памяти другого процесса, то эти два процесса должны явно обменяться информацией с помощью файлов, каналов, общей памяти, переменных среды или сокетов. Объекты, которые принадлежат различным процессам и нуждаются во взаимодействии между собой, также должны использовать один из перечисленных выше способов явного обмена информацией. Как правило, С++-разработчик при разработке распределенного объектно-ориентированного приложения сталкивается с необходимостью решения следующих проблем.

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

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

• Синхронизация взаимодействия между локальны м и и удаленны м и объектами.

• Обработка ошибок и исключений в распределенной среде.

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