Многозадачный режим

Архитектура, описанная в этой главе, предполагает, что каждая задача окружена "границей видимости" такой, что одна задача не может непосредственно иметь доступ к коду внутри другой задачи. Если это предположение содержится в Вашей среде разработки - например, используется C++ в Юникс или VMS, - Вы будете считать ее нетривиальным заданием проектирования, которое расширяет эту архитектуру, чтобы обеспечивать более чем подобие многозадачности, поддерживаемой здесь. Фундаментальная проблема должна иметь дело с получением доступа к данным экземпляра в другой задаче без нарушения правил времени. Последнее замечание ключевое: мы исследовали свойства некоторых архитектур, которые не сохраняют правила времени, и определили, что в таких случаях собственно проектирование может стимулировать взаимоблокировку, которая не была представлена в изначальных моделях ООА. Обратите внимание, что параллелизм и совместное использование экземпляров получили в 1990-1991 гг. существенное признание как темы исследования [2,3]. Мы думаем, что в недалеком будущем методы, применяемые для решения этих проблем, завоюют всеобщее внимание.

И наконец, если Вы работаете в среде, где граница задачи не совпадает с границей видимости (как в Аде), мы бы предложили Вам рассмотреть архитектуру, описанную Хиллом [4] как начальную точку.

9.10 Рекурсивное проектирование

Позвольте нам теперь просуммировать то, что мы сделали в этой главе, скорее, с точки зрения метода (рекурсивного проектирования - RD), чем результата (объектно-ориентированного проекта).

Структурные элементы и правила архитектуры

Сначала мы определили концептуальные сущности архитектуры: четыре специальных архитектурных класса, прикладные классы, аксессоры, тейкеры событий и т.п. Эти сущности обеспечивают структурные элементы архитектуры.

Мы также определили структурные правила: требуемые связи, между различными структурными элементами. Например:

• пассивный класс имеет общедоступные аксессоры, но не имеет тейкеров событий;

• класс определителя имеет только операционные классы - операцию Установить, операцию Загрузить КМС и тейкеры событий.

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

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

Правила преобразования: от прикладных моделей к архитектуре

Сразу после определения концептуальных сущностей архитектуры мы предписываем, как преобразовывать элементы прикладного домена (атрибуты, события, процессы и т.п.) в определяемые экземпляры архитектурных объектов (рис.9.10.2).

Эти правила преобразования описаны как процедуры для создания определенных экземпляров архитектурных объектов (класс Порция, класс Изменение Температуры и т.д.) в форме специализированных диаграмм класса и схем структуры класса - специализации прототипных диаграмм классов и схем структуры класса.

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