Этап проектирования архитектуры структурные аспекты Архитектура системы

Этап проектирования архитектуры: структурные аспекты

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

• • Определения архитектуры системы Архитектура-это проект, поднятый на высокий уровень, Архитектура-это общая структура системы, Архитектура-это структура компонентов системы, их взаимосвязи а также принципы и нормы их проектирования и развития во времени, Архитектура-это компоненты и соединители.

Место архитектурного проектирования в общем процессе проектирования • Собственно проектирование может быть разбито на три части: проектирование архитектуры. проектирование механизмов, детальное проектирование. • Первый шаг процесса проектирования - проектировании архитектуры. Он идентифицирует ключевые стратегии, позволяющие определить крупноблочную организацию проектируемой системы.

Проектирование архитектуры включает: • Отображение программных пакетов на процессоры; • Выбор шины и протоколов обмена; • Определение модели параллелизма и потоков задач.

Этапы проектирования системы • • Проектирование архитектуры; Проектирование механизмов; Детальное проектирование. Применительно к объектно-ориентированным системам проектирование архитектуры детализирует крупноблочные программные структуры такие как подсистемы, пакеты и задачи. • Средний уровень проектирования называется проектированием механизмов, . Он включает механизмы композиции классов, работающих вместе для достижения общих целей. • Детальное проектирование определяет внутренние примитивные структуры данных и алгоритмы внутри отдельных классов.

• Архитектурное проектирование : • Число и типы процессоров; • Пакеты объектов, функционирующих на каждом процессоре; • Межпроцессорная среда коммуникаций и протоколы; • Модели параллелизма и стратегии межпотокового взаимодействия; • Уровни программного обеспечения и вертикальные срезы; • Глобальная политика обработки ошибок.

• Проектирование механизмов: • Экземпляры шаблонов проектирования для множества объектов, взаимодействующих совместно; • Контейнеры, классы и объекты уровня проектирования; • Политики среднего уровня для обработки ошибок.

Детальное проектирование • Алгоритмические детали внутри объекта; • Детали структур данных в объектах (типы, диапазоны и другие); • Детали функциональных членов (аргументы, внутренняя структура).

Физическая архитектура • Любое проектное решение в электронике, которое частично релевантно программной архитектуре, представляет собой типы и количество устройств в системе (особенно процессоры) и физическую коммуникационную среду, связывающую их вместе. Разработчик программного обеспечения должен в своих решениях учитывать эти особенности • Программными аспектами для каждого процессора являются: • Прозрачное назначение и границы выполнения программ на процессоре; • Вычислительная мощность процессора; • Возможность проектирования средств, таких как компиляторы для выбранных языков, программы отладки, эмуляторы; • Возможность использования готовых компонент, включая операционную систему, контейнерные библиотеки, коммуникационные протоколы и пользовательский интерфейс; • Предыдущий опыт и внутренние знания процессора.

Типичные вопросы при проектировании физической фрхитектуры • Как процессоры связываются вместе? • Должна ли коммуникационная среда быть построена на базе шинной или звездообразной топологии? • Должна ли она быть управляющей шиной (busmastered) или быть типа "главный-подчиненный" (master-slave)? • Должен ли арбитраж выполняться на базе приоритета или на других основах? • Реализуется ли принцип точка – точка или мультиточка? • Какова должна быть скорость передачи?

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

Архитектурные вопросы при проектировании программного обеспечения: Пакеты • • При разработке архитектуры важно определить набор программных компонент, находящихся на одном физическом процессоре. Обычно эти компоненты являются пакетами, которые в свою очередь содержат другие пакеты и классы. Создание программой архитектуры тогда становится процессом разработки подсистем, пакетов, задач и их взаимодействия. Пакет рассматривается как способ организации элементов модели в более крупные блоки, которыми впоследствии позволяется манипулировать как единым целым. Хорошо спроектированный пакет группирует семантически близкие элементы, которые имеют тенденцию изменяться совместно. Пакеты могут содержать подпакеты, но их первичными компонентами являются объекты и классы. Пакеты могут употребляться для моделирования единственной проблемной области. Они собственно содержат объекты и классы, которые представляют важные концепты в данной предметной области. Иерархии классового обобщения всегда находятся в пакете единственной предметной области.

Архитектурные вопросы при проектировании программного обеспечения: Подсистемы • Подсистема является типом пакета, который организует элементы времени исполнения (объекты и компоненты), используя общее поведение, как организующий принцип. • Иконы, используемые для представления этих особенностей, показаны на рис. Cл. и используются здесь далее. • Подсистемы часто организуются как набор пакетов распределенных по уровням (слоям).

Архитектурные вопросы при проектировании программного обеспечения: Слои(уровни) • Многие сложные системы имеют несколько упорядоченных иерархически уровней, начиная от наиболее абстрактного (ближайшего к проблемной области системы), до более конкретного (ближайшего к оборудованию). Например, • Приложения; • Пользовательский интерфейс; • Коммуникации; • Операционная система; • Абстракция оборудования. • Разделенные на секции пакеты и подсистемы являются примером архитектурного шаблона микроядра. И поскольку подсистемы и пакеты логически разделены на уровни, в терминах абстракции не подразумевается, что система должна быть реализована в виде слоев. Фактически справедливо обратное. Наиболее эффективно проектировать секционированную архитектуру и в действительности реализовывать систему как набор вертикальных срезов функциональности, которая пронизывает все уровни.

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

• Более поздние прототипы строятся на базе сервисов, реализованных в их предшественниках. Это является сущностью философии итеративной разработки прототипирования – постепенного добавления возможностей, пока система не будет закончена. Естественно, итеративное прототипирование применяется не только для проектирования коммуникационных протоколов.

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

Представление физической архитектуры в UML • Диаграмма развертывания включает графические изображения процессоров, устройств, процессов и связей между ними. • Несколько важных элементов этой диаграммы показаны на рис. Слайда 23. • Иконкой первичной важности в диаграммах развертывания является узел. • Кроме изображений узлов на диаграмме развертывания указываются отношения между ними (зависимости и ассоциации). В качестве отношений выступают физические соединения между узлами. • В большинстве случаев это электрические соединения, однако, не исключены оптические и телеметрические соединения. • На диаграммах развертывания могут быть представлены компоненты, каждая из которых размещена на каком-то узле. Кроме того, пакеты или подсистемы – и те, и другие используются для группирования элементов модели в отдельные блоки.

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

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

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

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

• Рис. на сл. 28 показывает простой пример системы управления позиционированием телескопа. Пользовательский интерфейс состоит из LCD дисплея и двух поворотных манипуляторов, которые связаны с одним и тем же процессором. • Подсистема позиционирования состоит из двух независимых подсистем, каждая из которых имеет шаговый двигатель и независимый датчик. • Процессоры связанны вместе через сеть Ethernet и используют сетевые платы для доступа к сети. • На этом рисунке показаны два метода спецификации программного обеспечения, выполняемого на процессорах. • Первый метод демонстрируется на узле UI процессора. Он содержит подсистемы, компоненты и “активные” объекты. • Программные компоненты показаны, как вложенные пакеты. • Другой нотацией является перечисление пакетов в текстовой форме, так как это сделано в контроллерах позиционирования.

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

Примеры шаблонов • Master – Slave (Главный – подчиненный) координирует активность нескольких процессоров. • Microkernel (Микроядро) -декомпозирует комплексные компоненты в наборы иерархических абстрактных слоев для облегчения портабельности и повторного использования. • Proxy (Модуль доступа) -обрабатывает распространение данных из центрального сервера к множеству удаленных клиентов. • Broker (Брокер) -обрабатывает распространение данных из центрального сервера к множеству удаленных клиентов, когда расположение серверов и клиентов не известно во время компиляции.

Шаблон Master – Slave • Шаблон Master – Slave реализует стратегию управления, в которой ведущее устройство Controller выдает команды и получает на них реакции от подчиненных устройств. Подчиненные устройства обычно не инициализируют коммуникации, но могут быть активно инициированы ведущим устройством

• Это особенно полезно в мультипроцессорных системах, когда ведущее устройство должно динамически балансировать процессорную нагрузку среди множества процессоров (симметричное процессирование). • Преимуществом симметричного процессирования в операционных системах реального времени (RTOS) является то, что добавление процессора в существующую систему может привести к увеличению ее пропускной способности без всякой модификации программного обеспечения, потому что симметричные алгоритмы управления задачами загружают задачи на недогруженные процессоры. • Асимметричное мультипроцессирование означает, что процессоры назначаются во время компиляции для специфичных задач. • Этот подход менее предпочтителен и гибок для систем реального времени, но более эффективен для известных конфигураций. • Большинство систем реального времени асимметрично, потому что каждый процессор имеет различные интерфейсы к различной аппаратуре.

• Третий подход, называемый квазисимметричным мультипроцессированием (SSM), полезен для больших жестких систем реального времени. • В этом сложном подходе привязка задачи к процессору не определена во время компилирования, но она определена во времени загрузки системы. • Брокер задач создает очередь доступных процессоров и располагает задачи, которые не связаны с аппаратурой, на этих процессорах. • Преимуществом SSM является то, что он остается достаточно гибким и оказывает минимальное влияние на время исполнения. • Преимуществом шаблона Master – Slave является его простота. Он может быть использован для реализации распределенного одновременного процессирования алгоритмов, управления арбитражем разделяемых ресурсов. Управление Master – Slave обычно выполняется в циклической манере, где циклы ведущего устройства, включают действия, которые инициируют сервисы подчиненных устройств в предопределенной последовательности. • Когда последовательность действий известна во времени, проектируемый шаблон Master – Slave является очевидным выбором.

• Циклическое планирование действий делает систему особо детерминистичной. Здесь всегда возможно остановить процессорные часы в любой известной точке времени, и выяснить, какая инструкция процессора выполняется. • Апериодические события обрабатываются с помощью последовательного опроса, но поскольку планирование является детерминистическим, достаточно просто вычислить необходимое время для обработки событий. • Простота шаблона является его главным преимуществом. Однако имеются и недостатки. Имеется множество систем, которые должны реагировать на эпизодические непредвиденные события. При увеличении сложности алгоритма управления вычислительной мощностью, доступной управляющему устройству, становится трудно удовлетворить всем временным ограничениям, используя организацию Master – Slave. • Циклические планировщики простые, но они имеют тенденцию становиться неэффективными при использовании ресурсов процессора. • Имеется возможность удовлетворить все временные ограничения, используя политику предварительного планирования, что невозможно при циклическом планировщике

Шаблон Microkernel • Шаблон Microkernel известен как многоуровневый шаблон. Основным концептом этого шаблона является разбиение структуры подсистем на различимые наборы классов, которые могут быть упорядочены в виде набора иерархических клиент – серверных ассоциаций (см. рис. Сл. 37). • В общем случае нижний уровень в иерархии прямо соединен с интерфейсом с лежащей ниже аппаратурой или операционной системой, в то время как верхний уровень содержит объекты предметной области высокоуровневого приложения. • Интерфейсы уровней прозрачны сверху, но не прозрачны снизу. Классы, определенные в интерфейсе пакета, являются видимыми только классам пакета или верхнему пакету в иерархии. Закрытая многоуровневая архитектура является такой, при которой каждый уровень знает только об уровне, который находится ниже в этой иерархии. В открытой многоуровневой архитектуре уровень может запросить сервисы от любого уровня, стоящего ниже в иерархии. Закрытая многоуровневая архитектура имеет тенденцию приносить в жертву производительность для увеличения инкапсуляции и повторного использования.

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

Портабельность • Портабельность - (портируемость, переносимость, англ. portability) термин, обозначающий переносимость программного обеспечения.

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

• • На рис. Сл. 41 показан Proxy шаблон и пример его использования. В этом примере сервер хранит информацию о частоте сокращения сердца, замеряемой с помощью зажимов электрокардиограммы. Клиент локализован на отдельном дисплейном процессоре и отображает на экране временной график сокращения сердца. Поскольку объекты клиента и сервера находятся на различных процессорах, клиент, локализованный на процессоре дисплея, использует объект модуля доступа для поддержания локальной копии частоты сердца. Этот модуль доступа может обслуживать множество клиентов, таких как менеджер тревоги (проверяет на аритмию), несколько дисплей - клиентов. Модуль доступа поддерживает свою собственную связь с сервером частоты сокращения сердца через коммуникационную шину. Для этого модуль доступа подписывается на сервер (который может иметь несколько клиентов модуля доступа, распределенных по системе), в результате чего сервер достаточно часто шлет подписчику корректировку по данным измерения. Модуль доступа изолирует клиента от необходимости знания информации относительно нахождения сервера и от знания деталей протокола обмена, обеспечивающего передачу данных по шине.

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

Шаблон Broker • Шаблон Broker является переработанным шаблоном Proxy и представляет собой следующий шаг в направлении отделения клиентов от серверов. • Брокер представляет собой объект, который знает расположение других объектов. Эти знания брокер может иметь априори (во время компиляции), или может собирать информацию динамически, когда объекты регистрируют себя, или в комбинации. • Основным преимуществом шаблона Broker является то, что он дает возможность сконструировать шаблон Proxy, когда в период компиляции расположение сервера неизвестно. Это делает его особенно полезным для систем, использующих симметричное или квазисимметричное мультипроцессирование. • Архитектурными компонентами шаблона Broker являются брокер - объект, клиент и серверная компоненты.

• Достаточно редко используются случаи применения брокера с изолированным клиентом или сервером, и когда это случается, Broker - шаблоны являются типично ключевыми стратегическими решениями проектировании. • Хотя множество систем реального времени способны использовать коммерческие брокер – объекты, не принято реализовывать специальный брокер для оптимизации использования системных ресурсов. • В помехоустойчивых системах и системах, критичных для безопасности объектный брокер может играть ключевую роль в поддержке системной целостности. • Когда подсистема становится нестабильной или закрывается, объектный брокер для технологических систем может инициировать, например, такие действия по безопасности, как обесточивание лазеров, введение управляющих стержней в ядро ядерного реактора и т. д. Брокер также может быть вовлечен в стартовые или закрывающие последовательности операций для распределенных систем реального времени.

• Сценарий на рис. Сл. 46 с двумя уровнями. Первый уровень представлен модулем доступа, изолирующим клиентов и серверы друг от друга. Второй уровень представлен объектным брокером, который изолирует модуль доступа от серверов. • Заметим, что серверный объект сначала регистрируется брокером, так что он может поддерживать входящие запросы для сервера. Когда клиент подписывается на свой локальный модуль доступа, последний в свою очередь подписывается на серверный модуль доступа. • Объектный брокер поддерживает этот запрос, поскольку только он знает расположение сервера.

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

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

Диаграммы и системные задачи • Классовые и объектные модели в основе своей параллельны. По определению объекты параллельны и естественно, что каждый объект может выполняться в своем собственном потоке. Для эффективности во время архитектурного дизайна объекты должны быть отображены в меньший набор параллельных потоков. Благодаря этому отображение системы в потоки является всегда решением уровня проектирования. • В UML потоки образуются в единственном активном классе. Активный класс представляет собой композит, который агрегирует объекты, участвующие в потоке. Он отвечает за координацию внутреннего исполнения путем диспетчеризации сообщений к его частям и предоставление информации низлежащей операционной системе, так что последняя может спланировать поток. Показывая только классы со стереотипом «active» на единственной диаграмме можно создать диаграмму системных задач.

• Для производительности системы очень важным является пакетирование объектов в узлы и потоки. • Отношения среди потоков являются фундаментальными архитектурными решениями, которые оказывают большое влияние на производительность и на требования к аппаратному обеспечению системы. В дополнение к идентификации потоков и их отношению к другим потокам должны быть определены характеристики сообщений. Этими характеристиками являются: • Шаблоны частоты и прибытия сообщений; • Временные ограничения на реакции на события; • Прототипы синхронизации для межзадачной коммуникации; • Жесткость временных ограничений.

• Рис. Сл. 53 показывает диаграмму задач для набора классов, суммируемых в показанных “активных” объектах лифтовой системы. Диаграмма имеет большое количество полезных деталей. • Во-первых, все процессоры идентифицированы. • Elevator Gnome является отдельно стоящим процессором, потому что он действует как диспетчер управления события. • Central Station тоже единственный. Для каждого этажа имеются процессоры Elevator и Floor. • Заметим, что множественность экземпляров показана в верхнем левом углу в каждой процессорной иконе. • Внутри каждого процессора взаимодействуют объекты. Однако на диаграмме системных задач показаны только потоки. • Заметим, что каждый поток начинается в единственном активном композитном объекте, который получает события для этого потока и перенаправляет их к соответствующему объекту внутри потока. • Ассоциации среди потоков показаны с использованием соответствующей для ассоциации нотации. • Эти ассоциации отражают то, что потоки должны контактировать некоторым образом для того, чтобы посылать сообщения.

Состояния активной объектной компоненты потока • Неактивное (Inactive)-Поток еще не создан. • Ожидания (Waiting)-Поток не готов к выполнению, но ждет некоторого события для того, чтобы перейти в состояние готовности к работе (Ready). • Готовности к работе (Ready)-Поток готов исполняться, и является ждущим выполнения. Это обычно отражено в приоритетной FIFO очереди. • Прогона (Running)-Поток исполняется, потребляя CPU циклы. Это состояние содержит две ортогональные параллельные компоненты: • - Прерывистое (Interruptible)-Поток выполняется и может быть захвачен другими. Это подсостояние состояния Running. • - Атомарное (Atomic) - Поток является исполняемым, но не может быть захвачен другими. В частности переключение задач исключено. Это подсостояние Interruptibility Component состояния Running.

• Блокированное (Blocked)-Поток ожидает требуемого ресурса, чтобы стать доступным так, что бы иметь возможность продолжать обработку. • Ожидание события (Waiting for event)-Поток ждет событие для обработки его. Это подсостояние Event. Handling State Component состояния Running. • Диспетчеризации (Dispatching Event) - Объект обрабатывает приходящее событие и решает, какой агрегат должен процессировать его. Это подсостояние Event-Handling State Component состояния Running. • Обработки события (Processing Event) - Назначенный агрегат активного объектного компонента реагирует на событие. Это подсостояние Event-Handling State Component состояния Running.

• Неактивное (Inactive)-Поток еще не создан. • Ожидания (Waiting)-Поток не готов к выполнению, но ждет некоторого события для того, чтобы перейти в состояние готовности к работе (Ready). • Готовности к работе (Ready)-Поток готов исполняться, и является ждущим выполнения. Это обычно отражено в приоритетной FIFO очереди. • Прогона (Running)-Поток исполняется, потребляя CPU циклы. Это состояние содержит две ортогональные параллельные компоненты: • - Прерывистое (Interruptible)-Поток выполняется и может быть захвачен другими. Это подсостояние состояния Running. • - Атомарное (Atomic) - Поток является исполняемым, но не может быть захвачен другими. В частности переключение задач исключено. Это подсостояние Interruptibility Component состояния Running.

Детали выделения потоков • Во время анализа были определены и охарактеризованы классы, объекты и определены их ассоциации. В многозадачной системе объекты должны быть помещены в потоки для действительного исполнения. Этот процесс задачно – потокового определения имеет две стороны: • Идентификацию потоков; • Распространение потоков в классах и объектах во время анализа и процесса проектирования. • Существует несколько стратегий, которые могут помочь определить потоки, базируясь на внешних событиях и системном контексте. Они попадают в общий подход группирования событий в системе, так что поток поддерживает одно или более событий и каждое событие поддерживается единственным потоком.

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

Идентификация потока • Внутренние и внешние события могут быть сгруппированы вместе многими способами: • Группы единственного события В простой системе, возможно, сделать отдельный поток для каждого внешнего и внутреннего события. Но это не принято в сложных системах с десятками и даже сотнями возможных событий или когда время переключения потоков значительно по сравнению со временем реакции на события. • Последовательная обработка данных Когда ясно, что последовательности шагов должны выполняться в последовательной модели, они могут быть сгруппированы в последовательный поток. • Источник события Эта стратегия группирует вместе события из общих источников. Например, группирование всех событий, относящихся к цифровой электрокардиограмме: все данные NIBP (noninvasive blood pressure - неинвазивное кровяное давление) могут быть сгруппированы в один поток, в другой - данные дыхания, в следующий поток – данные агента анестезии, в следующий - данные газовой смеси и т. д. Источниками событий в автомобиле могут быть система зажигания, тормозная система и система управления двигателем. В системах с ясно определенными подсистемами, производящими события, которые могут иметь тот же период, этот подход может быть наиболее продуктивным.

• Интерфейсное устройство (известное так же как порт) Эта стратегия группирования инкапсулирует управление специфичным интерфейсом в единственном потоке. Например, (периодические) SDLC данные могут быть обработаны в одном потоке, (эпизодические) RS 232 данные к внешним моделям и (эпизодическим) пользовательским кнопкам в другом потоке. Эта стратегия является специализацией стратегии группирования по источнику событий. • Связанная информация Рассмотрим группирование, при котором все периодические формы будут поддерживаться одним потоком, а все измеряемые цифровые параметры другим потоком. Например, вся информация, касающаяся воздушной управляющей поверхности в каждом крыле или хвостовой секции самолета, может управляться отдельными потоками. Это группирование может быть соответствующим в том случае, когда относящиеся к нему данные используются вместе в пользовательской предметной области.

• Шаблон прибытия • Если данные прибывают с заданной скоростью, единственный периодический поток может получить все релевантные данные и если необходимо, перенаправлять их к различным объектам. • Апериодические события могут поддерживаться единственным обработчиком прерывания и аналогичным образом передавать управление соответствующим объектам. • Обычно это группирование может быть соотнесено с внешними событиями, такими как, прерывания по таймеру или когда периоды событий естественно группируются вокруг небольшого набора периодов. • Заметим что эта первичная стратегия, употребляемая для идентификации потоков, которые имеют предельный срок использования других политик с ограниченной во времени реакцией на событие, может привести к инверсии приоритетов, если разработчики особенно осторожны

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

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

При проектировании параллелизма нужно добавлять события в группы, в которых они соответственно появляются, так чтобы каждое событие представлялось, по крайней мере, в одной группе. Любые события, остающиеся после начального группирования, могут рассматриваться независимо. Как упоминалось ранее, рекомендуется, чтобы действия потоков, которые имеют жесткие временные ограничения, использовали стратегию "шаблон прибытия" для страхования планируемого набора потоков. При проектировании можно использовать как отдельные стратегии, так и наборы стратегий группирования событий. Когда группирование кажется законченным и стабильным, это означает, окончание идентификации начального набора потоков, который обрабатывает все события в вашей системе. По мере того как продвигается разработка программного продукта, в группу могут быть добавлены новые события, или события могут быть удалены из групп. Это должно привести разработчика к достойным рассмотрения альтернативным решениям.