Лекции - Часть 5 - файл n1.doc

Лекции - Часть 5
скачать (129.3 kb.)
Доступные файлы (1):

162kb.

01.09.2004 20:56

n1.doc

Часть 2. ПРОЕКТИРОВАНИЕ СРВ
5. UML проектирование систем реального времени
Значительное понижение цен на микропроцессоры и полупроводниковые микросхемы и столь же существенное увеличение производительности микропроцессоров, наблюдаемые на протяжении нескольких лет, сделали рентабельными распределенные системы и системы реального времени на базе микрокомпьютеров. Сегодня большинство коммерческих, промышленных, военных, медицинских и потребительских продуктов снабжаются микропроцессорами и целиком либо в значительной части управляются программами. Такие системы встречаются в микроволновых печах и видеомагнитофонах, в телефонах и телевизорах, в автомобилях и самолетах, в подводных лодках и космических кораблях, в автоматах по продаже газированных напитков и банкоматах, в системах диагностики пациентов и системах управления производством, в контроллерах роботов и системах управления лифтами, в системах управления городским и воздушным транспортом, в электронной почте и коммерции, в «интеллектуальных» транспортных и информационных магистралях… Список можно продолжать до бесконечности. Все это параллельные системы, а многие из них являются к тому же распределенными или системами реального времени.

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

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

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

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

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

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

На этапе проектирования среди объектов выявляются активные (их называют задачами) и пассивные (их называют объектами). Для определения задач применяются критерии разбиения на задачи. Разрабатываются также интерфейсы задач и описываются операции каждого пассивного класса.
5.2. Метод и нотация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Временные ограничения. Системы реального времени обязаны тратить на обработку события время, не превышающее

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