Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Последовательная группировка.
Бывает так, что некоторые задачи приложения необходимо выполнять строго последовательно. Первая в цепи таких задач активизируется асинхронным или периодическим событием, а все остальные исполняются после нее одна за другой. Такие задачи можно объединить, применив критерий последовательной группировки.
Группировка по управлению. Управляющий объект, который исполняет последовательную диаграмму состояний, отображается на управляющую задачу. В некоторых случаях эту задачу можно объединить с другими объектами, которые выполняют действия, срабатывающие при переходе или начинающиеся в момент перехода деятельности. Такой вид группировки называется группировкой по управлению. В аналитической модели зависящий от состояния управляющий объект определяется с помощью последовательной диаграммы состояния. Такому объекту следует сопоставить отдельную управляющую задачу, поскольку выполнение диаграммы состояния по определению строго последовательно. Но эта задача может выполнять в своем потоке управления другие зависящие от состояния действия или деятельности. Рассмотрим подобные случаи: – зависящие от состояния действия, запускаемые управляющим объектом в момент перехода состояний. – зависящие от состояния деятельности, которые начинаются или заканчиваются управляющим объектом в результате перехода состояний. – зависящие от состояния деятельности, которые запускаются управляющим объектом в результате перехода состояний и исполняются, пока объект находится в данном состоянии. Группировка по взаимному исключению. Группировка по взаимному исключению имеет место, когда есть группа задач, из которых по условиям приложения в любой момент времени может исполняться только одна. Пересмотр проекта путем инверсии задач Идея инверсии задач впервые была сформулирована в методе структурного программирования Джексона и в системе разработки Джексона. Такая инверсия способствует уменьшению числа задач в системе. В предельном случае параллельное решение можно вообще свести к последовательному. Критерии инверсии задач применяются для объединения задач с целью сокращения накладных расходов на организацию многозадачности. На начальной стадии их используют тогда, когда вероятность высоких накладных расходов очевидна. Если же такая опасность осознана позже, то к этому вопросу допустимо вернуться на стадии пересмотра проекта, в частности если анализ производительности проекта показал, что затраты на многозадачность чрезмерно высоки. Существует три вида инверсии задач: инверсия нескольких экземпляров задачи, инверсия последовательных задач и темпоральная инверсия. С помощью инверсии нескольких экземпляров задачи все однотипные задачи заменяются одной, выполняющей те же функции. Инверсия последовательных задач применяется главным образом тогда, когда между двумя или более задачами осуществляется сильно связанный обмен сообщениями. При темпоральной инверсии, которая напоминает слабые формы темпоральной группировки, две или более периодические задач – внутренние, ввода/вывода или входящие в темпоральную группу – объединяются. Разработка архитектуры задач Критерии разбиения на задачи можно применять к аналитической модели следующим образом. В каждом случае нужно сначала решить, будет ли объект из аналитической модели отображаться на активный или пассивный объект проектной модели: – задачи интерфейса с устройством. Начните с объектов интерфейса устройств, взаимодействующих с внешним миром. – управляющие задачи. Рассмотрите все зависящие от состояния управляющие объекты. Отобразите их на управляющие задачи. – периодические задачи. Проанализируйте внутренние периодические деятельности, которые оформляются как периодические задачи. Выясните, есть ли среди них такие, которые запускаются одним и тем же событием. В этом случае их можно связать в одну задачу, применив критерий темпоральной группировки. Возможно, удастся также задействовать критерий последовательной группировки для объединения ряда других задач; – другие внутренние задачи. Для каждой внутренней задачи, активизируемой внутренним событием, проверьте, нет ли среди соседних с ней задач на диаграмме параллельной кооперации таких, которые можно объединить на основе различных критериев группировки: последовательной, темпоральной или по взаимному исключению. Начальная диаграмма параллельной кооперации. После разбиения системы на параллельные задачи рисуется начальная диаграмма параллельной кооперации, на которой представлены все задачи. Интерфейсы задач на ней все еще показываются в виде простых сообщений, как на диаграммах кооперации из аналитической модели. Коммуникации между задачами и синхронизация Следующий шаг после разбиения системы на параллельные задачи – определение интерфейсов задач. Теперь необходимо представить интерфейсы в форме обмена сообщениями, синхронизации по событиям или доступа к скрывающим информацию объектам.. В случае слабо связанного обмена сообщениями, называемого также асинхронным обменом, производитель посылает сообщение потребителю и продолжает работать, не дожидаясь ответа. Поскольку производитель и потребитель функционируют с разной скоростью, то между ними может существовать FIFO-очередь. Если в момент, когда потребитель запрашивает сообщение, его не оказывается, потребитель приостанавливается. В ситуации сильно связанного (синхронного) обмена сообщениями с ответом производитель посылает потребителю сообщение и ждет ответа. При поступлении сообщения потребитель принимает его, обрабатывает, генерирует ответ и отправляет его назад. После этого производитель и потребитель продолжают функционировать. Если сообщений нет, потребитель приостанавливается. В случае сильно связанного обмена сообщениями без ответа производитель посылает потребителю сообщение и ждет, пока оно дойдет до адресата. Потребитель принимает поступившее сообщение, освобождая тем самым производителя. После этого производитель и потребитель продолжают работать. Если сообщений нет, потребитель приостанавливается. Синхронизация по событию. Возможны три вида такой синхронизации: по внешнему событию, по событию таймера и по внутреннему событию. Внешнее событие поступает из внешнего источника, как правило, в виде прерывания от устройства ввода/вывода. Внутреннее событие обеспечивает внутреннюю синхронизацию между двумя задачами. Событие таймера предназначено для периодической активизации задачи. События изображаются в UML с помощью нотации асинхронных сообщений. Задачи могут обмениваться данными также с помощью пассивного скрывающего информацию объекта. После определения интерфейсов задач начальная диаграмма кооперации пересматривается с целью изображения различных видов интерфейсов. Спецификация поведения задачи Спецификация поведения задачи (СПЗ) описывает ее интерфейс, структуру, временные характеристики, относительный приоритет, логику упорядочения событий и обнаруживаемые ошибки. Интерфейс задачи – это способ ее взаимодействия с другими задачами. Структура говорит о том, как данная задача появилась (посредством какого критерия разбиения). Временные характеристики – это частота активизации и ожидаемое время выполнения. Полученная информация используется для планирования в реальном времени. СПЗ прилагается к описанию архитектуры задач. В процессе разбиения на задачи в СПЗ заносится информация о входных и выходных данных задачи. Часть СПЗ составляется позже, на этапе детального проектирования программы. Речь идет о логике упорядочения событий – описании того, каким образом задача отвечает на входные события. Проектирование классов На этом этапе проектируются скрывающие информацию классы, из которых создаются экземпляры пассивных объектов. Первоначально классы определяются на этапе построения аналитической модели в ходе разбиения системы на объекты и классы. Класс применяет сокрытие информации для решения различных вопросов, связанных со статической структурой, например сокрытия информации об устройстве или абстрагирования данных. Операции класса можно вывести как из статической, так и из динамической модели. Хотя статическая модель предназначена для отражения операций классов, их проще выявить посредством анализа динамической модели – прежде всего, диаграммы кооперации или последовательности. Ниже мы покажем, как операции класса выводятся из модели кооперации, из описания конечного автомата и из статической модели, но основное внимание уделим модели кооперации. Популярное:
|
Последнее изменение этой страницы: 2016-03-17; Просмотров: 810; Нарушение авторского права страницы