Системы обработки транзакций

⇐ ПредыдущаяСтр 12 из 12

Приложения для обработки транзакций (или просто транзакционные приложения) относятся к классу критических для бизнеса или иной деятельности [2]. Сюда входят системы ввода заказов, резервирования авиабилетов и кассовые терминалы. Транзакционное приложение занимается обновлением информации в базе данных. Нагрузка на такое приложение обычно предсказуема, значительную долю в ней занимают запросы на обновление. Известны также требования в периоды пиковой нагрузки, поэтому можно оценить структуру множества запросов к базе. Некоторые транзакционные приложения должны работать постоянно, в других допустимы короткие перерывы.

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

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

У транзакций выделяются следующие свойства:

– атомарность. Транзакция – это неделимая единица работы. Она либо выполняется полностью (фиксируется), либо не выполняется вовсе (откатывается);

– непротиворечивость. После завершения транзакции система должна оказаться в непротиворечивом состоянии;

– изолированность. На поведение транзакции не должны оказывать влияния другие транзакции;

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

3.11.2. Мониторы обработки транзакций. Монитор обработки транзакций (ТР-монитор) координирует поток информации между различными клиентами, инициирующими запросы, и приложением обработки транзакций, которое отвечает на эти запросы. ТР-мониторы уже много лет существуют на больших ЭВМ. Наиболее широко известна программа CICS компании IBM, функционирующая с операционными системами и СУБД, которые поставляет IBM.

В гетерогенной клиент-серверной среде ТР-мониторы выполняют следующие действия:

– посылают и принимают сообщения от клиентов и серверов;

– управляют потоком транзакций и распределяют нагрузку между серверами;

4. РАЗБИЕНИЕ НА ЗАДАЧИ

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

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

Тип задачи – это активный класс, а сама задача - активный объект. У задачи есть собственный поток управления. Пассивный объект – это экземпляр пассивного класса. При обсуждении проектной модели мы будем использовать термин «объект» для обозначения пассивного объекта, а термин «задача» – для обозначения активного объекта.

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

4.1. Вопросы разбиения на параллельные задачи

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

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

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

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

4.2. Категории критериев разбиения на задачи

Критерии разбиения на задачи можно отнести к нескольким категориям по признаку участия в процессе структурирования:

– критерии выделения задач ввода/вывода. Касаются отображения объектов интерфейса устройств на задачи ввода/вывода и вопроса о моменте активизации таких задач;

– критерии выделения внутренних задач. Связаны с тем, как внутренние объекты отображаются на внутренние задачи и как эти задачи активизируются;

– критерии назначения приоритетов задачам. Позволяют определить относительную важность каждой задачи;

– критерии группировки задач. Позволяют решить, какие объекты следует группировать в параллельные задачи и как именно;

– критерии инверсии задач. Применяются для решения вопроса о том, какие задачи стоит объединить для уменьшения накладных расходов. Это можно делать при исходном разбиении или при пересмотре первоначального проекта.

Задачи активизируются периодически или апериодически (по требованию). При определении задачи может использоваться сразу несколько критериев.

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

Для изображения различных видов задач задействуются стереотипы. Стереотипами будут также обозначаться разные виды устройств, с которыми общаются задачи. Если в процессе разбиения на задачи некоторый объект определяется как активный, то для него уточняются характеристики соответствующей задачи. Например, активный объект «интерфейс устройства ввода/вывода» считается задачей и характеризуется следующим образом: «асинхронный интерфейс устройства ввода/вывода», «синхронный интерфейс устройства ввода/вывода», «периодический интерфейс устройства ввода/ вывода», «пассивный интерфейс устройства ввода/вывода» или «монитор ресурсов». Точно так же «внешнее устройство ввода» в зависимости от характеристик классифицируется как «асинхронное устройство ввода» или «пассивное устройство ввода».

4.3. Критерии выделения задач ввода/вывода

Ниже описываются различные критерии выделения задач ввода/вывода. Для этого в первую очередь необходимо определить характеристики устройства, интерфейс с которым должна реализовывать задача.

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

– характеристики устройств ввода/вывода. Важно понять, является устройство асинхронным (активным) или пассивным. Вот три основных класса устройств ввода/вывода:

• асинхронные устройства ввода/вывода (иногда их называют также активными), работающие по прерываниям. Когда асинхронное устройство ввода получает данные для обработки, оно генерирует прерывание. Асинхронное же устройство вывода генерирует прерывание, когда заканчивает операцию вывода и готово к приему новых данных;

• пассивные устройства ввода/вывода. Пассивное устройство не генерирует прерываний при завершении операции. Чтобы узнать, есть ли информация у пассивного устройства ввода, его надо периодически опрашивать. Соответственно перед отправкой данных пассивному устройству вывода надо убедиться, что оно готово принять их;

• канал связи. Некоторые управляемые микропроцессорами устройства ввода/вывода и внешние системы подключаются с помощью канала связи. Порядок обмена данными между системами определяется коммуникационным протоколом (например, TCP/IP). На прикладном уровне задачи, принадлежащие разным системам, обмениваются сообщениями.

– характеристики данных. Важно выяснить, работает устройство ввода/вывода с дискретными или непрерывными данными. Дискретные данные могут быть булевскими или принимают значения из конечного множества. Аналоговые данные по своей природе непрерывны и теоретически способны принимать значения из бесконечного множества. Аналоговое устройство ввода/вывода требуется опрашивать. Если бы оно генерировало прерывание при каждом изменении значения, система просто не смогла бы их все обработать;

– пассивное устройство ввода/вывода. Для пассивного устройства необходимо выяснить следующее:

• достаточно ли запрашивать данные у устройства по мере необходимости, например только тогда, когда они нужны потребителю;

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

– частота опроса. Если пассивное устройство ввода/вывода приходится периодически опрашивать, необходимо определить частоту опроса. Она зависит от того, насколько критичны входные данные и как интенсивно они могут изменяться.

В случае устройства вывода период опроса зависит от того, как часто данные должны посылаться ему, чтобы не было потерь.

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

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

Асинхронная задача интерфейса с устройством ввода/вывода – это задача драйвера устройства. Как правило, она активизируется низкоуровневым обработчиком прерывания, а иногда непосредственно устройством.

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

В качестве примера асинхронной задачи интерфейса с устройством рассмотрим объект Интерфейс Ручки Круиз-Контроля, показанный на диаграмме кооперации, которая входит в состав аналитической модели (рис. 4.l, a). Этот объект получает входные данные от ручки круиз-контроля, которая представлена в виде внешнего устройства ввода. Затем он преобразует данные во внутренний формат и посылает запрос объекту Круиз-Контроль. С точки зрения разбиения на задачи ручка круиз-контроля - это асинхронное устройство ввода, изображаемое на диаграмме параллельной кооперации в составе проектной модели (рис.4.1, б) с помощью стереотипа «асинхронное устройство ввода». Оно генерирует прерывание при изменении положения ручки. Объекту Интерфейс Ручки Круиз-Контроля соответствует одно-именная асинхронная задача интерфейса с устройством ввода, которая передается на диаграмме параллельной кооперации со стереотипом «асинхронный интерфейс устройства ввода». Когда задача активизируется в результате прихода прерывания Круиз-Контроля, она читает данные Круиз-Контроля, преобразует их во внутренний формат и посылает сообщение запрос Круиз-Контроля задаче Круиз-Контроль.

Рис. 4.1. Пример асинхронной задачи интерфейса с устройством ввода/вывода: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации)

4.3.3. Периодические задачи интерфейса с устройством ввода/вывода. Если асинхронная задача интерфейса с устройством ввода/вывода работает с асинхронным устройством, то периодическая задача имеет дело с пассивным устройством, которое необходимо время от времени опрашивать. В этой ситуации задача активизируется периодически, но ее функции связаны с вводом/выводом.

Такая задача запускается событием таймера, выполняет операцию ввода/вывода, после чего ждет следующего события таймера. Период задачи – это промежуток времени между последовательными запусками.

Периодические задачи ввода/вывода часто применяются для простых устройств, которые, в отличие от асинхронных, не генерируют прерываний. Так, они обслуживают пассивные датчики, которые нужно время от времени опрашивать.

Периодические задачи интерфейса с датчиками

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

Рассмотрим пассивное цифровое устройство ввода, к примеру датчик двигателя. С ним ассоциирована периодическая задача интерфейса с устройством ввода. Она активизируется событием таймера и считывает состояние устройства. Если показания датчика изменились с момента последнего опроса, то задача выводит на экран индикатора новые показания.

Рис. 4.2. Пример периодической задачи интерфейса с устройством ввода: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации)

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

О выборе временных интервалов для периодических задач ввода/ вывода

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

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

Чем выше частота опроса для данной задачи, тем больше накладные расходы. Если речь идет о цифровом устройстве ввода, то периодическая задача, скорее всего, будет потреблять больше ресурсов, чем эквивалентная асинхронная: в большинстве случаев периодическая задача активизируется зря, поскольку значение наблюдаемой ею величины не изменилось. Если частота опроса слишком велика, накладные расходы оказываются чрезмерными. Снова подчеркнем, что значение частоты опроса зависит от параметров устройства ввода и характеристик внешней по отношению к приложению среды.

4.3.4. Пассивные задачи интерфейса с устройствами ввода/вывода. Такие задачи используются для работы с пассивными устройствами ввода/ вывода, которые не надо опрашивать. В частности, они применяются в случае, когда желательно совместить вычисления с вводом/выводом. Обратите внимание, что слово «пассивное» относится к устройству, а не к объекту. Объект остается активным, поскольку представляет собой задачу. Рассмотрим следующие случаи:

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

Отделение пассивной задачи ввода от вычислительной задачи полезно только в тех случаях, когда последняя должна произвести некоторые вычисления за время, пока задача ввода читает данные. Если же вычислительная задача должна дожидаться входных данных, то ввод допустимо выполнять в том же потоке управления;

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

Пассивные задачи интерфейса с устройствами обычно применяются для работы с устройствами вывода, а не ввода, поскольку совмещение вывода с вычислениями требуется чаще (см. следующий пример). Как правило, для совмещения ввода с вычислениями используются периодические задачи ввода.

Рассмотрим пассивную задачу вывода, которая получает сообщение от задачи-производителя. Совмещение вычислений с выводом достигается так: задача-потребитель выводит данные, содержащиеся в сообщении, на пассивное устройство вывода (дисплей), а производитель в то же время готовит новое сообщение (рис. 4.3). Интерфейс Дисплея Статистики Датчика – это пассивная задача интерфейса с устройством вывода. Она принимает сообщение, которое нужно вывести, от задачи Алгоритм Статистики Датчика и показывает содержащиеся в нем данные, пока Алгоритм вычисляет следующее значение. Таким образом, вычисления оказываются совмещенными с выводом. Задача Интерфейс Дисплея Статистики Датчика показана на диаграмме параллельной кооперации со стереотипом «пассивный интерфейс устройства вывода».

Рис. 4.3. Пример пассивной задачи интерфейса с устройством вывода и вычислительной задачи без жестких временных ограничений: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации)

4.3.5. Задачи-мониторы ресурсов. Задача-монитор ресурса – это частный случай пассивной задачи ввода/вывода, рассмотренной выше. С устройством ввода/вывода, которое получает запросы из разных источников, должна быть ассоциирована задача-монитор для координации запросов, даже если устройство является пассивным. Ее цель – упорядочить запросы, чтобы гарантировать целостность данных и избежать их искажения или потери.

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

Пример монитора ресурсов приведен на рис. 4.4. Интерфейс Лампочки Этажа – это объект интерфейса устройства вывода, который получает запросы от нескольких экземпляров объекта Управление Лифтом с указанием погасить лампочку на данном этаже (рис. 4.4, а). Лампочка – это пассивное устройство вывода. Поскольку оно получает запросы из разных источников, то объект Интерфейс Лампочки Этажа устроен как задача-монитор ресурса, которая координирует все поступающие запросы (рис. 4.4, б). Описанная задача изображена на диаграмме параллельной кооперации со стереотипом «монитор ресурса».

Рис. 4.4. Пример задачи-монитора ресурса: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации)

4.4. Критерии выделения внутренних задач

Если критерии выделения задач ввода/вывода применяются для определения задач ввода/вывода, то критерии выделения внутренних задач помогут выявить внутренние задачи, не связанные с вводом/выводом.

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

Рис. 4.5. Пример периодической задачи: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации)

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

В качестве примера рассмотрим объект Таймер Пути, показанный на рис. 4.5, а. Он активизируется событием таймера и просит объект Путь вычислить пройденное машиной расстояние. Объект Путь сначала считывает показания счетчика оборотов вала и значения калибровочной константы, а затем вычисляет полный пройденный путь. Объект Таймер Пути отображается на периодическую задачу (рис. 4.5, б), которая при каждой активизации запрашивает у объекта Путь пройденное машиной расстояние. Задача Таймер Пути изображена на диаграмме параллельной кооперации со стереотипом «периодическая». Объекты Путь, Счетчик Оборотов Вала и Калибровочная Константа являются пассивными.

4.4.2. Асинхронные задачи. Во многих параллельных системах и системах реального времени встречаются работы, выполняемые по требованию. Обычно для них применяются асинхронные задачи. Если асинхронные задачи ввода/вывода активизируются прерываниями, то асинхронные внутренние задачи (их еще называют апериодическими) активизируются по требованию, когда приходит внутреннее сообщение или событие.

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

Пример асинхронной задачи приведен на рис. 4.6. В аналитической модели объект Крейсер активизируется поступлением сообщения Команда Круиз-Контроля от объекта Круиз-Контроль, считывает значения объектов Текущая Скорость и Требуемая Скорость, вычисляет корректировку положения дроссельной заслонки и посылает сообщение Значение Дросселя объекту Интерфейс Дросселя (рис. 4.6, а). В проектной модели объект Крейсер выделяется в асинхронную задачу-алгоритм Крейсер, которая активизируется поступлением сообщения команда Круиз-Контроля. Эта задача изображена на диаграмме параллельной кооперации со стереотипом «асинхронный алгоритм» (рис. 4.6, б). Объектам Круиз-Контроль и Интерфейс Дросселя также соответствуют задачи. Текущая Скорость и Требуемая Скорость - это пассивные объекты.

Рис. 4.6. Пример асинхронной задачи: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации)

4.4.3. Управляющие задачи. В аналитической модели зависящий от состояния управляющий объект исполняет диаграмму состояний. Так как используется ограниченная форма диаграммы состояний, в которой параллелизм внутри объекта не допускается, то ее выполнение оказывается строго последовательным. Поэтому последовательно исполняемая задача может осуществлять управляющую деятельность. Задача, реализующая последовательную диаграмму состояний (обычно изображаемая в виде таблицы переходов состояний), называется управляющей.

Пример управляющей задачи приведен на рис. 4.7. Зависящий от состояния управляющий объект Круиз-Контроль (рис. 4.7, а), который исполняет диаграмму состояний Круиз-Контроль, оформлен в виде отдельной одноименной задачи (рис. 4.7, б), так как исполнение диаграммы строго последовательное. Эта задача изображена на параллельной диаграмме состояний со стереотипом «управление».

Рис. 4.7. Пример управляющей задачи: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации)

Другой пример дает задача Управление Лифтом, которая исполняет диаграмму состояний лифта. Здесь есть несколько объектов Управление Лифтом (изображенных на рис. 4.8, а с помощью нотации множественных экземпляров). Каждый экземпляр выделен в управляющую задачу. Следовательно, для каждого лифта есть одна управляющая задача Управление Лифтом. Все они изображены на рис. 4.8, б также с помощью нотации множественных экземпляров.

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

Рис. 4.8. Пример нескольких однотипных управляющих задач:

а – аналитическая модель (управляющий объект, несколько экземпляров);

б – проектная модель (однотипные управляющие задачи)

4.4.4. Задачи интерфейса пользователя. Пользователь, как правило, выполняет операции последовательно. Поскольку его взаимодействие с системой носит последовательный характер, оно реализуется в виде задачи интерфейса пользователя. Быстродействие такой задачи часто ограничено скоростью работы человека. Как и следовало ожидать, на нее отображается объект интерфейса пользователя из аналитической модели.

Задача интерфейса пользователя обычно работает с различными стандартными устройствами ввода/вывода: клавиатурой, дисплеем и мышью, которые управляются самой операционной системой, поэтому нет необходимости разрабатывать специализированные задачи драйверов таких устройств.

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

Идея одной задачи на каждую последовательную деятельность также нашла отражение в современных графических рабочих станциях с оконным интерфейсом. В каждом окне выполняется последовательная деятельность, поэтому с каждым окном связывается одна задача. В ОС Windows пользователь способен работать с редактором Word в одном окне и с программой PowerPoint – в другом. Для каждого окна имеется своя задача интерфейса пользователя, которая может, в свою очередь, запускать дополнительные задачи (например, для совмещения печати и редактирования).

Пример задачи интерфейса пользователя приведен на рис. 4.9. Объект Интерфейс Оператора принимает команды от оператора, считывает данные из сущностного объекта Хранилище Показаний Датчика и отображает их на дисплее (рис. 4.9, а). Поскольку оператор в данном случае выполняет только последовательные действия, то объект Интерфейс Оператора оформляется как задача интерфейса пользователя (рис. 4.9, б). Эта задача изображена на диаграмме параллельной кооперации со стереотипом «интерфейс пользователя».

Рис. 4.9. Пример задач интерфейса пользователя: а – аналитическая модель (диаграмма кооперации); б – проектная модель (диаграмма параллельной кооперации с одной задачей интерфейса пользователя); в – проектная модель (диаграмма параллельной кооперации с двумя задачами интерфейса пользователя)

В многооконной графической среде дежурный оператор может одновременно наблюдать за состоянием производства (это окно поддерживается одной задачей) и подтверждать прием тревожных сигналов (за такое окно отвечает другая задача) – рис. 4.9, в. Здесь присутствуют две задачи интерфейса пользователя: Окно Состояния Производства и Окно Тревожных Сигналов. Задача Окно Состояния Производства взаимодействует с пассивным объектом Хранилище Состояний Производства, а задача Окно Тревожных Сигналов - с пассивным объектом Хранилище Тревожных Сигналов.

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

Если число однотипных объектов в приложении слишком велико, чтобы для каждого определять свою задачу, применяется инверсия задач.

Пример нескольких однотипных управляющих задач можно найти в системе управления лифтами (см. рис. 4.8). Аспекты работы лифта, связанные с управлением, моделируются с помощью управляющего объекта Управление Лифтом и изображаются на последовательной диаграмме состояний. На этапе разбиения на задачи объект Управление Лифтом отображается на задачу Контроллер Лифта. В системе с несколькими лифтами имеется по одной такой задаче для каждого объекта Управление Лифтом. Эти задачи идентичны, и каждая исполняет экземпляр одной и той же диаграммы состояний. Однако, скорее всего, все лифты будут в любой момент времени находиться в разных состояниях.

4.5. Критерии назначения приоритетов задачам

Эти критерии помогают выявить высоко- и низкоприоритетные задачи. Часто приоритетности задач уделяется внимание только на поздних стадиях цикла разработки. Главная причина, по которой мы относим эти вопросы к этапу разбиения на задачи, состоит в желании выявить критические по времени и некритические, но связанные с большим объемом вычислений объекты, которые следует рассматривать как отдельные задачи. Приоритеты для большинства задач определяются методом планирования в реальном времени.

4.5.1. Критические по времени задачи. Критической по времени называется задача, которая обязана завершиться к точно установленному сроку. Такая задача должна выполняться с высоким приоритетом. Высокоприоритетные критические по времени задачи необходимы в большинстве приложений реального времени.

Рассмотрим ситуацию, когда после исполнения критического по времени объекта задействуется объект, некритический по времени. Можно было бы объединить эти объекты в соответствии с критерием последовательной группировки. Но, чтобы гарантировать быстрое обслуживание критического по времени объекта, предпочтительнее выделить его в самостоятельную высокоприоритетную задачу. Такая ситуация типична для асинхронных задач ввода/вывода, управляемого прерываниями, когда обработка прерывания критична по времени.

В качестве примера рассмотрим объект Контроль Температуры в Печи. Если температура превышает 100°С, то печь следует выключить. Этот объект отображается на высокоприоритетную задачу, которая должна успеть завершиться в течение жестко определенного времени, в противном случае изделие, находящееся в печи, сгорит.

Другие разновидности критических по времени задач – управляющие задачи и асинхронные задачи интерфейса с устро

⇐ Предыдущая 3 4 5 6 7 8 9 10 1112