Часть 2. ПРОЕКТИРОВАНИЕ СРВ

5. UML проектирование систем реального времени

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

ипотребительских продуктов снабжаются микропроцессорами и це- ликом либо в значительной части управляются программами. Такие системы встречаются в микроволновых печах и видеомагнитофонах, в телефонах и телевизорах, в автомобилях и самолетах, в подводных лодках и космических кораблях, в автоматах по продаже газирован- ных напитков и банкоматах, в системах диагностики пациентов и системах управления производством, в контроллерах роботов и сис- темах управления лифтами, в системах управления городским и воз- душным транспортом, в электронной почте и коммерции, в «интел- лектуальных» транспортных и информационных магистралях… Спи- сок можно продолжать до бесконечности. Все это параллельные сис- темы, а многие из них являются к тому же распределенными или сис- темами реального времени.

Объектно-ориентированные концепции особенно важны для анализа и проектирования программного обеспечения, поскольку они касаются фундаментальных вопросов адаптируемости и развития. Сравнительно недавно появившийся унифицированный язык модели- рования (UML) предлагает стандартизованную нотацию для описания объектно-ориентированных моделей [16, 18, 19, 21]. Объе-динение концепций объектно-ориентированного проектирования с концеп- циями параллельного выполнения необходимо для успешного созда- ния распределенных приложений, работающих в реальном масштабе времени. Поскольку UML содержит стандартную нотацию для описа- ния объектно-ориентированных моделей, будем использовать именно этот язык. Особое внимание уделим моделированию динамики сис- темы, представляющему интерес для приложений реального времени

ираспределенных приложений.

www.pdffactory.com

5.1. Объектно-ориентированные методы и UML

Объектно-ориентированные методы основаны на концепциях сокрытия информации, классов и наследования [27]. Сокрытие ин- формации [23] позволяет получить замкнутые, а оттого в большей степени поддающиеся модификации и сопровождению системы. На- следование [27] – это систематический способ адаптации классов.

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

Вметоде COMET сочетаются прецеденты использования, стати- ческое моделирование, диаграммы состояний и диаграммы последо- вательности событий, которые встречаются в нескольких методах. Применяемая нотация основана на UML [16, 18]. В ходе моделирова- ния прецедентов использования определяются функциональные тре- бования к системе в терминах актеров и прецедентов. Статическая

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

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

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

асинхронно посылаемое сообщение и какая вызывается операция у объекта-получателя, откладывается до стадии проектирования.

На этапе проектирования среди объектов выявляются активные (их называют задачами) и пассивные (их называют объектами). Для

www.pdffactory.com

определения задач применяются критерии разбиения на задачи. Раз- рабатываются также интерфейсы задач и описываются операции ка- ждого пассивного класса.

5.2. Метод и нотация

Метод проектирования и нотация проектирования – это разные вещи. Нотация проектирования ПО предназначена для описания са- мого проекта. Хотя она и предполагает наличие определенного под- хода к проектированию, сам подход остается за ее рамками. Метод

проектирования ПО представляет собой систематическое описание этапов создания проекта.

Нотация проектирования ПО описывает.проект программы в графическом или текстовом виде. В частности, диаграммы классов – это графическая нотация, а псевдокод – текстовая.

Концепция проектирования ПО – это фундаментальная идея, применимая к проектированию всей системы, например сокрытие информации.

Стратегия проектирования ПО – общий план и методика выпол- нения проекта. Одной из стратегий является объектно- ориентированная декомпозиция.

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

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

В методе COMET для описания проекта применяется нотация UML. Метод основан на следующих концепциях: сокрытие информа- ции, наследование и параллельные задачи. Стратегия проектирования

параллельно работающих объектов состоит в разбиении системы на

www.pdffactory.com

активные и пассивные объекты и определении интерфейсов между ними. Метод COMET также содержит критерии разбиения, по- могающие выделить объекты в системе на этапе анализа, а затем на

этапе проектирования выявить отдельные подсистемы и параллельно выполняемые задачи.

5.3. Системы и приложения реального времени

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

ного времени рассматриваются в более широком контексте систем реального времени.

Рис. 5.1. Система реального времени

Системы реального времени часто очень сложны, так как их ра-

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

www.pdffactory.com

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

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

Программные системы реального времени имеют дополнитель- ные характеристики, отличающие их от прочих систем:

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

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

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

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

www.pdffactory.com

новению самолетов в воздухе. Необходимое время реакции зависит от приложения: иногда оно измеряется миллисекундами, иногда – се- кундами, а иногда – даже минутами.

4.Управление в реальном масштабе времени. Часто системе ре-

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

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

5.Реактивные системы [20] управляются событиями и должны реагировать на внешние стимулы. Обычно реакция системы зависит от ее текущего состояния, то есть не только от самого внешнего сти- мула, но и от того, что происходило в системе раньше.

www.pdffactory.com