|
|
|
Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру | |
© Браин Селик (Bran Selic), ObjecTime
Limited
© Джим Румбаух (Jim Rumbaugh), Rational Software Corporation
Переведено БНТП по заказу
Interface Ltd.
Аннотация
Встраиваемые системы реального времени, встречающиеся в таких прикладных областях, как телекоммуникации, аэрокосмические и оборонные приложения, обычно имеют тенденцию быть большими и сложными. Решающим для таких систем является то, что они должны быть разработаны в соответствии с разумной архитектурой. Хорошая архитектура не только упрощает создание первоначальной системы, но и, что более важно, обеспечивает адаптивность системы к изменениям, вызываемым постоянным появлением новых требований. В этой статье мы описываем набор конструкций, облегчающих проектирование архитектур для программ из этих предметных областей. Конструкции, полученные из подтвержденных практикой концепций изначально описанные в языке моделирования ROOM (Real-Time Object-Oriented Modeling - объектно-ориентированное моделирование систем реального времени), специфицированы с использованием стандарта UML (Unified Modeling Language - универсальный язык моделирования). В частности, мы демонстрируем, как эти архитектурные конструкции могут быть получены из более общих концепций моделирования UML путем использования мощных механизмов расширения UML.
Мы используем универсальный язык моделирования UML (UML [2], [3]) для описания набора конструкций, походящих для моделирования важной категории программных систем реального времени. Они получены из набора концепций, изначально определенных в языке моделирования ROOM [1].
Одним из наиболее общих свойств всех программных систем реального времени является детерминизм, т.е. требование корректного отклика системы в рамках приемлемого временного интервала. Однако, это как будто простое свойство характеризует широкий спектр очень разных систем - от систем работающих исключительно по временному расписанию и до систем, работающих исключительно под управлением происходящих событий. С течением времени, для каждой из этих категорий систем были разработаны собственные идиомы, шаблоны проектирования и стили моделирования, которые объединили коллективный опыт многих проектов.
В этом документе мы сконцентрировали внимание на основной категории систем реального времени, которые можно охарактеризовать как сложные системы, работающие под управлением событиями и использующие (в потенциале) распределенную обработку. Такие системы наиболее часто встречаются в телекоммуникациях, аэрокосмических и оборонных приложениях и в системах автоматизированного управления. Размеры и сложность этих систем требуют значительных первоначальных затрат на проектирование, обычно с привлечением больших коллективов разработчиков, за которыми следует длительный период эволюционного роста. Со временем обнаруживаются новые требования, и система частично модифицируется для их удовлетворения.
В таких условиях особо важную роль приобретает архитектура системы. Она описывает структурные и поведенческие схемы, на которых базируются все остальные аспекты системы. Это программный эквивалент несущих конструкций в строительстве - любые изменения в этих основах делают необходимыми сложные и дорогостоящие изменения в основных частях системы. Таким образом, хорошо спроектированная архитектура не только упрощает разработку исходной системы, но и, что более важно, обеспечивает адаптивность системы к изменениям, вызываемым появлением новых требований.
Для облегчения проектирования хороших архитектур исключительно важно выделить апробированные шаблоны проектирования предметной области в виде конструкций для моделей первого рода. Вот почему ROOM, наряду с другими, включил в себя концепции, задающие предметно-ориентированный язык описания архитектур. Эти конструкции использовались свыше десяти лет и доказали свою эффективность в сотнях различных крупномасштабных индустриальных проектов. Мы обнаружили, что это предметно-ориентированное применение может быть строго реализовано с использованием языка общего назначения UML.
Как упоминалось выше, UML использовался для отображения этих конструкций. Мы обнаружили, что он отлично приспособлен для этих целей, так что новые для UML концепции моделирования не понадобились. С большим успехом были применены стандартные механизмы настройки UML, основанные на использовании стереотипов, присоединенных значений и ограничений. Например, центральная для ROM концепция "actor" (актер) отображалась с помощью стереотипа "capsule" (капсула) - специализации более общей концепции класса с UML. Этот стереотип добавил дополнительную предметно-ориентированную семантику к различным аспектам, связанным с понятием класса в UML (например, конечные автоматы, взаимодействия и т.п.). Возможность использования стереотипов обеспечила простой и короткий путь интерпретации набора правил правильного формирования конструкций, описывающих эту семантику.
В результате, конструкции моделирования, описанные в этом документе, представляют собой библиотеку типов прикладных концепций UML, предназначенную, прежде всего, для использования при моделировании архитектур сложных систем реального времени. Их использование в комбинации со всеми другими концепциями моделирования и диаграммами UML обеспечивает целостный набор средств моделирования.
В этом разделе мы рассматриваем наиболее важные конструкции моделирования, используемые для представления сложных систем реального времени, и так те описываем, как они представляются и отображаются в UML. Эти конструкции могут быть разбиты на две основные группы: конструкции для моделирования структур и конструкции для моделирования поведения.
Структура системы идентифицирует моделируемые сущности и взаимосвязи между ними (например, коммуникационные взаимосвязи, отношения вложенности и т.п.). UML предоставляет два фундаментальных взаимодополняющих типа диаграмм для описания структуры систем: диаграммы классов и диаграммы взаимодействий (collaboration). Диаграммы классов описывают универсальные отношения между классами - эти отношения существуют между экземплярами классов в любом контексте. Диаграммы взаимодействий отражают отношения, которые существуют только в конкретном контексте - шаблон использования для конкретных целей, который не наследуется собственно классом. Следовательно, в диаграммах взаимодействия различается использования разных экземпляров одного и того же класса. Это различение отражается к концепции роли. В подходе к моделированию, описанном здесь, присутствует строгий акцент на использовании диаграмм взаимодействий UML исключительно для представления взаимосвязей между архитектурными элементами. Обычно, целостная спецификация структуры сложной системы реального времени получается комбинацией диаграмм классов и диаграмм взаимодействий.
Конкретно мы выделяем три основных конструкции для моделирования структур:
Капсулы соответствуют концепции актора в ROOM. Они представляют собой сложные физические (возможно распределенные) архитектурные объекты, которые взаимодействуют со своим окружением через один или более ориентированных на обработку сигналов граничных объектов (boundary objects), называемых портами.
Порт - физическая часть реализации капсулы, которая является посредником во взаимодействии капсулы с внешним миром - это объект, реализующий специфический интерфейс. Каждый порт капсулы играет конкретную роль во взаимодействии капсулы с другими объектами. Для отображения сложной семантики этих взаимодействий порты ассоциированы с протоколом, который определяет корректный поток информации (сигналов) между соединенными портами капсул. В этом смысле протокол отражает контрактные соглашения, существующие между капсулами. Более детально протоколы обсуждаются в разделе, посвященном моделированию поведения (2.2.1). Ограничив взаимодействия между капсулами так, чтобы они выполнялись только посредством портов, становится возможным полностью отделить их (капсул) внутреннюю реализацию от любого непосредственного знания об окружении. Это обеспечивает высокое повторное использование капсул.
Коннекторы, которые соответствуют связкам (bindings) в ROOM, служат абстрактным представлением коммуникационных каналов ориентированных на передачу сигналов, которые соединяют два или более портов. Порты, связанные коннектором должны играть взаимно дополняющие, но совместимые роли в протоколе. На диаграмме взаимодействия они представляются путем ассоциирования роли, которая связана с соответствующим портом. Если мы абстрагируемся от портов в этой картине, коннекторы в действительности представляют ключевые коммуникационные отношения между капсулами. Эти отношения архитектурно значимы, так как они определяют, какие капсулы могут влиять друг на друга непосредственно. Порты включены для обеспечения инкапсуляции капсул в соответствии с принципом сокрытия информации и разделения ответственности.
Функциональность простой капсулы непосредственно реализуется конечным автоматом, ассоциированным с капсулой. Более сложные капсулы объединяют конечный автомат с внутренней сетью взаимодействующих капсул нижнего уровня (sub-capsules), соединенных коннекторами. Эти капсулы нижнего уровня являются полноправными капсулами и в свою очередь могут быть подвергнуты декомпозиции на капсулы нижнего уровня. Такая декомпозиция может продолжаться до требуемой глубины, позволяя моделировать исключительно сложные структуры на основе только этого базового набора конструкций для моделирования структур. Конечный автомат (который необязателен для составных капсул), капсулы нижнего уровня и их сеть связей представляют части реализации капсулы и скрыты от внешнего наблюдателя.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||