Лекция. Границы архитектурного проектирования по. План

Структура управления ПО

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

Элементы ПО

Во время выполнения каждый программный элемент имеет четко определенные функции и соединяется с другими элементами в граф зависимостей через соединители. Элементы архитектуры ПО, как правило, уточняются с помощью нескольких этапов преобразования на основе их атрибутов и спецификаций требований проекта.
В зависимости от назначенной функции каждого элемента ПО могут быть различные ограничения синхронизации и производительности. Например, некоторые элементы являются реентерабельными объектами или программными компонентами (это означает, что несколько потоков могут выполняться в элементе одновременно, не мешая друг другу), в то время как некоторые элементы не являются реентерабельными, и в каждый момент времени в нем может выполняться не более одного потока. В зависимости от кратности элемента, он может быть вызван ограниченным количеством других элементов во время выполнения или может быть вызван неограниченным количеством элементов, как в случае серверного элемента. В последнем случае масштабируемость, время отклика и пропускная способность становятся важными ограничениями производительности и должны учитываться при реализации элемента.
Ниже приведены основные рекомендации по отображению элементов времени выполнения в их реализации:
• Если элемент является реентерабельным, он может быть реализован потоком или процессом. Повторно вводимые элементы обычно более эффективны, поскольку они позволяют избежать многих проблем синхронизации и поддерживают общие потоки или пулы процессов. Однако бизнес-логика может не допустить повторного входа некоторых элементов.
• Если элемент не является реентерабельным, и несколько потоков или процессов должны взаимодействовать с ним, он должен быть запущен в отдельных потоках или процессах, чтобы быть потокобезопасным (это означает, что на поведение системы не влияет множественность потоков, выполняющихся одновременно) ,
• Если элемент имеет высокую кратность и его производительность важна для производительности глобальной системы, для реализации элемента должен использоваться сервер приложений (программная система, работающая с бизнес-логикой), чтобы он мог использовать преимущества пула потоков и ресурсов, кэширования данных, и динамическое управление жизненным циклом элемента для сохранения ресурсов.
• Если элементы содержат сложные вычисления для развертывания в определенном месте, кластер процессоров увеличит мощность обработки данных ЦП. Размер кластера и сопоставление элементов с компьютерами кластера должны выполняться тщательно, чтобы сбалансировать вычислительную нагрузку каждого кластера и минимизировать общий трафик связи в сети кластера.
• Если элементу назначены сложные, но четко определенные функции, аналогичные функциям некоторых коммерческих готовых компонентов ПО, и производительность этого элемента не является критической, то более экономически эффективным является использование существующего программного компонента чтобы реализовать функции элемента.
• Сложный элемент может быть расширен в подсистему со своими собственными элементами и соединителями. Четко определенный интерфейс должен использоваться для инкапсуляции деталей проектирования и реализации подсистемы из существующей архитектуры.
Сложный элемент может быть преобразован в последовательность элементов с вертикальными слоями, если каждый уровень предоставляет виртуальную машину или интерфейс к непосредственному элементу верхнего уровня, и каждый слой скрывает некоторые детали системы низкого уровня от верхних уровней.
• Сложный элемент может быть преобразован в последовательность горизонтально-уровневых элементов, если бизнес-логика может быть достигнута путем обработки данных с последовательностью отдельных этапов обработки, и эти этапы обработки могут быть реализованы с помощью многоуровневых элементов с четко определенными интерфейсами и сбалансированными рабочими нагрузками.