Системы

Эта лекция акцентирует внимание на классах - элементах конструкции ОО-ПО. Для получения исполняемого кода классы необходимо скомпоновать в систему.

Определение системы вытекает из предшествующего обсуждения. Для построения системы необходимы три вещи:

[x]. Создать совокупность классов CS , называемую множеством классов (class set) системы .

[x]. Указать класс из CS , являющийся корневым (root class) .

[x]. Указать в корневом классе процедуру, играющую роль корневой процедуры создания (root creation procedure) .

Для получения системы эти элементы должны удовлетворять критерию целостности. Каждый класс, прямо или косвенно необходимый корневому, должен быть частью множества CS . Это условие замыкания системы (system closure) .

Понятие необходимости следует уточнить, как это обычно делается при построении замыкания:

[x]. Класс D непосредственно необходим классу C , если текст C ссылается на D . Здесь можно выделить два варианта: C может быть либо клиентом D , либо потомком D .

[x]. Класс E необходим классу C , либо, когда C совпадает с E , либо существует класс D непосредственно необходимый классу С , и классу D необходим (возможно, рекурсивно) класс E . Другими словами, существует цепочка классов, связанных отношением непосредственной необходимости, и началом этой цепочки является класс C , а концом - класс E .

Теперь можно дать определение замкнутой системы.

Определение: замкнутая система

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

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

Этот процесс называется компоновкой или сборкой (assembly) системы и является завершающим этапом разработки.

Программа main отсутствует

Неоднократно подчеркивалось, что системы, разработанные с помощью ОО-подхода, не используют понятия основной программы. Не впускаем ли мы основную программу с черного хода, вводя определение корневого класса и корневой процедуры?

Не совсем. В традиционном понятии основной программы объединены две не связанные концепции:

[x]. Место, с которого начинается выполнение.

[x]. Вершина или фундаментальный компонент архитектуры системы.

Первое условие, безусловно, необходимо. Выполнение любой системы должно начинаться с вполне определенной позиции. В ОО-системах эта позиция определяется корневым классом и корневой процедурой. В случае параллельных, а не последовательных вычислений можно определить несколько начальных точек - по одной для каждой независимой нити или потока (Thread) вычислений.

Концепция вершины уже достаточно обсуждалась ранее и не требует дополнительных комментариев.

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

Ранее уже указывалось, что необходимо отказаться на раннем этапе разработки системы от вопроса, - "где основная программа?". Если строить архитектуру системы на основе ответа на этот вопрос, то нельзя обеспечить расширяемость и повторное использование кода. Другой подход - готовые к повторному использованию классы, реализации АТД. Программные системы в этом случае представляют собой перестраиваемые ансамбли таких компонент.(О критике функциональной декомпозиции см. "Функциональная декомпозиция", лекция 5)

Не всегда конечной целью разработки является создание систем. Важным приложением метода является разработка библиотек классов для повторного использования. Библиотека это не система и она не имеет корневого класса. В процессе разработки библиотеки часто создают несколько систем, но такие системы используются только для отладки и не являются частью завершенной версии библиотеки. Окончательный продукт является набором классов, который другие разработчики будут использовать для разработки своих систем или своих библиотек.