В последнем разделе мы уточним некоторые детали. Во-первых, вернемся к нашему предположению о том, что структура пакет-задача, показанная на рис. 3.2, более соответствует принципу модульного параллельного программирования, чем показанная на рис. 2.5. Во-вторых, изучим вариант более широкого применения нашего примера с портфелем.
Распределяя "специализированные" пакеты, подобные Member_Ops, Treasurer_Ops, Secretary_Ops и т. д., между задачами, представляющими активных пользователей, и двумя обслуживающими задачами Roster_Server и Portfolio_Server, мы извлечем выгоду, заключающуюся в том, что две задачи-обслуживатели будут полностью разъединены. В частности, для подтверждения прав на проведение ряда операций над портфелем Portfolio_Server больше не требуется взаимодействовать с Roster_Server. В результате этого разъединения каждая обслуживающая задача становится более маленькой и простой (имеет меньшее число входов и операторов accept и одновременно более простых). Каждая задача имеет элементы, позволяющие ей производить арбитраж возможного параллельного использования связанного с ней пакета-владельца (Club_Portfolio и Membership_Roster). Структура программы, необходимой для разделенных задач-обслуживателей, показана в приложении Ж.
Запросы на обслуживание, посылаемые к Roster_Server, гарантированно являются санкционированными из-за наличия промежуточных "фильтрующих" пакетов. Так, Roster_Server имеет только пять элементов, которые однозначно соответствуют операциям из Membership_Roster. Операторы accept в Roster_Server являются просто обращениями к Membership_Roster.
Аналогично, но с двумя важными исключениями, каждая операция, осуществляемая Portfolio_Server, соответствует не более чем вызову соответствующей операции из Club_Portfolio. Исключениями являются входы, имеющие дело с запросами на создание и удаление портфеля. Необходимая для них программа, приведенная в приложении Ж и состоящая из трех операторов accept, является небольшим усложнением фрагмента программы, приведенной на рис. 3.5.
Мы считаем, что системе управления портфелем акций капиталовложений и ее описанию на языке Ада было уделено достаточно внимания для того, чтобы отдельные читатели смогли сами проверить и закончить эту программу. Более любознательные читатели могут также рассмотреть вопрос об изучении данного случая в более общем, чем для случая отдельной организации по управлению капиталовложениями, контексте. В частности, какие изменения (если требуется) необходимо осуществить для того, чтобы структура, приведенная на рис. 3.2, могла быть использована или расширена для управления более чем одним портфелем или более чем одним набором сотрудников, которым разрешен доступ и обновление портфеля?
Предполагается, что банковское отделение, управляющее несколькими отдельными пенсионными или другими фондами, или организациями маклеров, управляющими в свою очередь бесчисленными портфелями акций, будет иметь гораздо более сложные структуры схем по контролю за правом доступа, чем в случае одной организации по управлению капиталовложениями. Например, если в момент выдачи вкладчиком запроса на операцию по закупке или продаже управляющий банковскими счетами находится в отпуске, организация маклеров должна предложить альтернативный доступ к портфелю вкладчика. В противном случае нетерпеливый вкладчик может предпринять ошибочный шаг, попытаясь продать часть акций в процессе ожидания возвращения управляющего банковскими счетами из отпуска.
Разумно ли выражать необходимые в таких ситуациях более сложные структуры по контролю за доступом без проведения существенных изменений в приводимой на рис. 3.2 базовой структуре программы? Мы считаем, что да. Также насколько легко модифицировать базовую структуру, приспосабливая ее под множество различных портфелей? Мы по-прежнему считаем, что требуемые изменения минимальны, но предоставляем читателю самому убедиться в этом.
Несмотря на то что мы не закончили полный разбор языка Ада, мы на нем остановились достаточно подробно для того, чтобы читатель оценил его как полезный язык программирования для системных и прикладных задач. Теперь нам хотелось бы рассмотреть вопрос о том, каким образом программы на языке Ада отображаются в структуру системной архитектуры i432. В следующей главе мы рассмотрим структуры данных программных единиц на этапе выполнения с тем чтобы увидеть, как они представляются в качестве объектных структур i432.
|
|
|