СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
93 |
Часть 2. ПРОЕКТИРОВАНИЕ СРВ
5. UML проектирование систем реального времени
Значительное понижение цен на микропроцессоры и полупро- водниковые микросхемы и столь же существенное увеличение произ- водительности микропроцессоров, наблюдаемые на протяжении не- скольких лет, сделали рентабельными распределенные системы и системы реального времени на базе микрокомпьютеров. Сегодня большинство коммерческих, промышленных, военных, медицинских
ипотребительских продуктов снабжаются микропроцессорами и це- ликом либо в значительной части управляются программами. Такие системы встречаются в микроволновых печах и видеомагнитофонах, в телефонах и телевизорах, в автомобилях и самолетах, в подводных лодках и космических кораблях, в автоматах по продаже газирован- ных напитков и банкоматах, в системах диагностики пациентов и системах управления производством, в контроллерах роботов и сис- темах управления лифтами, в системах управления городским и воз- душным транспортом, в электронной почте и коммерции, в «интел- лектуальных» транспортных и информационных магистралях… Спи- сок можно продолжать до бесконечности. Все это параллельные сис- темы, а многие из них являются к тому же распределенными или сис- темами реального времени.
Объектно-ориентированные концепции особенно важны для анализа и проектирования программного обеспечения, поскольку они касаются фундаментальных вопросов адаптируемости и развития. Сравнительно недавно появившийся унифицированный язык модели- рования (UML) предлагает стандартизованную нотацию для описания объектно-ориентированных моделей [16, 18, 19, 21]. Объе-динение концепций объектно-ориентированного проектирования с концеп- циями параллельного выполнения необходимо для успешного созда- ния распределенных приложений, работающих в реальном масштабе времени. Поскольку UML содержит стандартную нотацию для описа- ния объектно-ориентированных моделей, будем использовать именно этот язык. Особое внимание уделим моделированию динамики сис- темы, представляющему интерес для приложений реального времени
ираспределенных приложений.
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
94 |
5.1. Объектно-ориентированные методы и UML
Объектно-ориентированные методы основаны на концепциях сокрытия информации, классов и наследования [27]. Сокрытие ин- формации [23] позволяет получить замкнутые, а оттого в большей степени поддающиеся модификации и сопровождению системы. На- следование [27] – это систематический способ адаптации классов.
Язык UML, пришедший на смену многочисленным системам но- тации и методикам проектирования предложил нотацию для описа- ния объектно-ориентированных моделей, которая стала промышлен- ным стандартом. Однако для эффективного применения нотации UML необходимо сочетать ее с каким-либо методом объектно- ориентированного анализа и проектирования.
Вметоде COMET сочетаются прецеденты использования, стати- ческое моделирование, диаграммы состояний и диаграммы последо- вательности событий, которые встречаются в нескольких методах. Применяемая нотация основана на UML [16, 18]. В ходе моделирова- ния прецедентов использования определяются функциональные тре- бования к системе в терминах актеров и прецедентов. Статическая
модель предлагает статический взгляд на информационные аспекты системы. Класс определяется в терминах своих атрибутов и взаимо- отношений с другими классами. Результатом динамического модели- рования является динамический взгляд на систему. Уточняются сфор-
мулированные ранее прецеденты с целью показать взаимодействие объектов, участвующих в каждом из них. Разрабатываются диаграм- мы кооперации и последовательности, отражающие кооперацию объ- ектов в каждом прецеденте. Зависящие от состояния аспекты системы описываются с помощью диаграмм состояний, причем для каждого объекта составляется своя диаграмма.
Ваналитической модели основное внимание уделяется понима- нию проблемы: выявлению объектов предметной области и переда- ваемой между ними информации. Объекты и классы предметной об- ласти группируются на основе критериев выделения объектов. Рас- смотрение вопросов, активен объект или пассивен, синхронно или
асинхронно посылаемое сообщение и какая вызывается операция у объекта-получателя, откладывается до стадии проектирования.
На этапе проектирования среди объектов выявляются активные (их называют задачами) и пассивные (их называют объектами). Для
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
95 |
определения задач применяются критерии разбиения на задачи. Раз- рабатываются также интерфейсы задач и описываются операции ка- ждого пассивного класса.
5.2. Метод и нотация
Метод проектирования и нотация проектирования – это разные вещи. Нотация проектирования ПО предназначена для описания са- мого проекта. Хотя она и предполагает наличие определенного под- хода к проектированию, сам подход остается за ее рамками. Метод
проектирования ПО представляет собой систематическое описание этапов создания проекта.
Нотация проектирования ПО описывает.проект программы в графическом или текстовом виде. В частности, диаграммы классов – это графическая нотация, а псевдокод – текстовая.
Концепция проектирования ПО – это фундаментальная идея, применимая к проектированию всей системы, например сокрытие информации.
Стратегия проектирования ПО – общий план и методика выпол- нения проекта. Одной из стратегий является объектно- ориентированная декомпозиция.
Критерии структурирования ПО – это эвристические или фор- мальные правила, помогающие проектировщику разбить систему на отдельные компоненты. Так, критерии разбиения на объекты - это правила декомпозиции системы на объекты.
Метод проектирования ПО описывает последовательность ша- гов, выполняемых при работе над проектом при условии, что требо- вания к системе уже сформулированы. Он помогает выявить, какие решения предстоит принять, в каком порядке это следует делать и на основе каких критериев. Метод проектирования базируется на наборе соответствующих концепций, использует одну или несколько страте- гий, а также ту или иную нотацию для документирования результа- тов. При выполнении определенных шагов метод может подсказать разработчику, какие критерии наиболее удобны для декомпозиции системы.
В методе COMET для описания проекта применяется нотация UML. Метод основан на следующих концепциях: сокрытие информа- ции, наследование и параллельные задачи. Стратегия проектирования
параллельно работающих объектов состоит в разбиении системы на
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
96 |
активные и пассивные объекты и определении интерфейсов между ними. Метод COMET также содержит критерии разбиения, по- могающие выделить объекты в системе на этапе анализа, а затем на
этапе проектирования выявить отдельные подсистемы и параллельно выполняемые задачи.
5.3. Системы и приложения реального времени
Системы реального времени (рис. 5.1) – это параллельные сис- темы с временными ограничениями. Они широко распространены в промышленных, коммерческих и военных приложениях. Термин «система реального времени» обычно относится к системе в целом, включающей приложение реального времени, операционную систему реального времени и подсистему ввода/вывода реального времени. В состав такой системы входят также драйверы специальных устройств, управляющие работой различных датчиков и приводов. Поскольку здесь речь идет в основном о проектировании приложений, мы будем пользоваться термином «приложение реального времени», а не «сис- тема реального времени». Однако в этом разделе приложения реаль-
ного времени рассматриваются в более широком контексте систем реального времени.
Рис. 5.1. Система реального времени
Системы реального времени часто очень сложны, так как их ра-
бота связана с многочисленными независимыми потоками входных
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
97 |
событий и продуцированием различной выходной информации. Час- тота поступления событий обычно непредсказуема, однако реагиро- вать необходимо достаточно быстро, чтобы соблюсти временные ог- раничения, сформулированные в требованиях к программе. Нередко нельзя предугадать и порядок поступления событий. Кроме того, входная нагрузка может с течением времени значительно и неожи- данно изменяться.
Системы реального времени часто дополнительно подразделя- ются на системы с жесткими и слабыми временными ограничениями. Система с жесткими ограничениями обязана отреагировать на собы- тие в пределах установленного временного интервала, в противном случае возможен аварийный отказ. Для систем со слабыми ограниче- ниями выход за пределы допустимого интервала считается нежела- тельным, но все же не катастрофическим явлением.
Программные системы реального времени имеют дополнитель- ные характеристики, отличающие их от прочих систем:
1.Встраиваемые системы. Система реального времени часто яв- ляется частью более крупной программно-аппаратной системы. При- мером может служить контроллер робота, входящий в состав робото- технического комплекса, имеющего одну или несколько механиче- ских рук.
Обычно программная система реального времени состоит из приложения реального времени, операционной системы реального времени и, возможно, дополнительного системного ПО: коммуника- ционных программ, программ промежуточного слоя или драйверов специальных устройств.
2.Взаимодействие с внешней средой. Как правило, система ре- ального времени осуществляет такое взаимодействие без участия че- ловека. Например, она может управлять механизмами или процессом производства, следить за протеканием химических реакций или под- нимать тревогу. Для получения информации о внешней среде обычно требуются датчики, а для управления средой – приводы (см. рис. 5.1).
3.Временные ограничения. Системы реального времени обяза- ны тратить на обработку события время, не превышающее заранее заданное. Если в интерактивной системе недостаточно быстрая реак- ция способна лишь вызвать недовольство, то в системе реального времени последствия бывают катастрофическими. Например, в сис- теме управления воздушным движением это может привести к столк-
www.pdffactory.com
СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ |
98 |
новению самолетов в воздухе. Необходимое время реакции зависит от приложения: иногда оно измеряется миллисекундами, иногда – се- кундами, а иногда – даже минутами.
4.Управление в реальном масштабе времени. Часто системе ре-
ального времени приходится принимать управляющие решения на основе входных данных, без участия человека. Так, автомобильная система круиз-контроля, призванная поддерживать постоянную ско- рость машины, должна управлять дросселем в зависимости от теку- щей скорости.
Однако могут быть и некритичные по времени компоненты. На- пример, система сбора данных в реальном времени должна прини- мать информацию сразу, иначе она будет потеряна, но анализ полу- ченных сведений допустим и позже.
5.Реактивные системы [20] управляются событиями и должны реагировать на внешние стимулы. Обычно реакция системы зависит от ее текущего состояния, то есть не только от самого внешнего сти- мула, но и от того, что происходило в системе раньше.
www.pdffactory.com