Научный труд

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

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

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

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

2. ОБЗОР НОТАЦИИ UML

В методе COMET используется нотация из унифицированного языка моделиро­вания UML, которая объединила нотации, предложенные Бучем [3], Джекобсоном [8], Рамбо [3] и Харелом [7]. Представим краткий обзор нотации UML.

Co временем нотация UML расширялась, и теперь в ней поддерживается много различных диаграмм.

2.1. Диаграммы UML

В нотации UML поддерживаются девять видов диаграмм:

– диаграммы прецедентов;

– диаграммы классов;

– диаграммы объектов, являющиеся вариантом диаграмм классов в примене­нии к экземплярам. В методе COMET вместо них работают консолидиро­ванные диаграммы кооперации;

– диаграммы кооперации;

– диаграммы последовательности;

– диаграммы состояний;

– диаграммы деятельности (в COMET не используются);

– диаграммы компонентов (в COMET не используются).

– диаграммы развертывания.

2.2. Диаграммы прецедентов

Актер (actor) инициирует прецедент. Прецедент (use case) описывает после­довательность взаимодействий между актером и системой. Актер изображается на диаграмме прецедентов в виде фигуры человечка, система – в виде прямоуголь­ника, прецедент – в виде эллипса внутри этого прямоугольника. Коммуникаци­онные ассоциации связывают актеров с теми прецедентами, в которых они участ­вуют. Между прецедентами могут быть отношения include (включает) и extend (расширяет). Пример диаграммы прецедентов представлен на рис. 2.1.

2.3. Нотация UML для классов и объектов

Классы и объекты изображаются в UML прямоугольниками, как показано на рис. 2.2.

Рис. 2.1. Диаграммы прецедентов в нотации UML

В прямоугольнике класса всегда вписано имя класса. Дополнительно могут быть указаны атрибуты и операции класса. Когда присутствуют все три эле­мента, то в верхней секции прямоугольника находится имя класса, в средней – атрибуты, а в нижней – операции.

Для того чтобы отличить класс (тип) от объекта (экземпляра типа), имя объекта под­черкивается. Объект может обозначаться как anObject, anotherObject:Class или :Class. Классы и объекты встречаются в разных диаграммах UML.

Рис. 2.2. Объекты и классы в нотации UML

2.4. Диаграммы классов

На такой диаграмме классы изображаются в виде прямоугольников, а стати­ческие (постоянные) отношения между ними – в форме дуг. Поддерживаются три основных типа отношений между классами (рис. 2.3):

– ассоциации. Ассоциация между двумя классами (бинарная ассоциация) изображается в виде линии, соединяющей прямоугольники классов. У нее есть имя и, возможно, стрелка, поясняющая, в каком направлении следует это имя читать. На каждом конце ассоциации проставляется кратность – число, свидетельствующее, сколько экземпляров одного класса связано с од­ним экземпляром другого класса. Дополнительно на каждом конце ассоци­ации может присутствовать стрелка, указывающая направление навигации вдоль данной ассоциации.

Допустимы следующие кратности ассоциации: ровно один (1), присутствие экземпляра класса необязательно (0..1), нуль или более (*), один или более (1..*) и точное задание числа экземпляров классов (m..n), где m и n - числа;

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

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

Видимость определяет, доступен ли элемент класса вне самого класса (рис. 2.4). Показывать видимость на диаграмме необязательно. Открытая видимость, изобра­жаемая символом + (плюс), означает, что элемент виден извне класса.

Закрытая видимость, отмеченная знаком – (минус), свидетельствует о том, что элемент ви­ден только внутри класса, в котором он определен, а от других классов скрыт. За­щищенная видимость, показываемая знаком #, говорит о том, что элемент ви­ден внутри класса, в котором определен, а также во всех подклассах этого класса.

Рис. 2.3. Нотация UML для связей на диаграмме классов

Рис. 2.4. Нотация UML для обозначения видимости

на диаграмме классов

2.5. Диаграммы взаимодействия

В UML есть два вида диаграмм взаимодействия: диаграммы кооперации (col­laboration diagram) и диаграммы последовательности (sequence diagram). Семан­тически они эквивалентны.

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

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

Рис. 2.5. Диаграмма кооперации в нотации UML

2.5.2. Диаграммы последовательности. Другой способ показать взаимодействие объектов – воспользоваться диаграм­мой последовательности (рис. 2.6). На ней обмен объектов сообщениями пред­ставлен во времени более точно и наглядно. Диаграмма последовательности дву­мерна: участвующие объекты изображаются вдоль горизонтальной оси, а время откладывается вдоль вертикальной. От прямоугольника каждого объекта идет вниз вертикальная пунктирная линия, называемая линией жизни. Период, в тече­ние которого объект выполняет операцию, именуется активизацией. На протяже­нии этого периода линия жизни изображается двойной сплошной линией.

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

2.6. Диаграммы состояний

В нотации UML диаграмма перехода состояний называется диаграммой со­стояний. На ней состояния представляются прямоугольниками со скругленными углами, а переходы – соединяющими их дугами (рис. 2.7). Начальное состояние обозначается дугой, исходящей из маленького закрашенного кружка. Может также присутствовать необязательное конечное состояние, изображаемое закрашенным кружком внутри незакрашенного (иногда его называют «бычий глаз»). Диаграмму состояний разрешается подвергнуть иерархической декомпозиции, так что надсостояние разлагается на подсостояния.

Рядом с дугой, представляющей переход, находится условие перехода в виде: Событие [условие]/Действие. Событие вызывает переход в новое состояние. Если задано необязательное булевское условие, то переход осуществится, когда оно истинно. В результате перехода может быть выполнено необязательное действие. Дополнительно с состоянием иногда ассоциируются:

– действие при входе в состояние;

– деятельность, выполняемая во время нахождения внутри состояния;

– действие при выходе из состояния.

Рис. 2.6. Диаграмма последовательности в нотации UML

Рис. 2.7. Диаграмма состояний в нотации UML

надсостояние с последовательными подсостояниями

На рис. 2.7 показано надсостояние А, разложенное на два последовательных подсостояния – А1 и А2. В этом случае диаграмма в каждый момент времени мо­жет находиться только в одном состоянии, т. е. сначала будет вход в подсостояние А1, а затем – в подсостояние А2. На рис. 2.8 изображено надсостояние В, разложенное на два параллельных подсостояния – ВС и BD. Здесь объект, описы­ваемый диаграммой, одновременно находится в каждом из подсостояний ВС и BD. Далее каждое параллельное подсостояние раскладывается на последова­тельные. Таким образом, вход в надсостояние В сопровождается одновременным входом в подсостояния В1 и В3.

Рис. 2.8. Нотация U ML для диаграммы состояний:

надсостояние с параллельными подсостояниями

2.7. Пакеты

В UML пакетом называется группа элементов модели, используемая, напри­мер, для представления системы или подсистемы. Такая группа изображается пиктограммой папки – большим прямоугольником, над которым находится пря­моугольник поменьше (рис. 2.9). Пакеты бывают вложенными; между ними мо­гут существовать отношения зависимости и обобщения/специализации. Пакеты способны содержать классы, объекты или прецеденты.

Рис. 2.9. Нотация UML для пакетов

2.8. Диаграммы параллельной кооперации

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

Пассивный объект исполняется только тогда, когда другой объект (активный или пассивный) вызовет одну из его операций. Будем называть активный объект задачей, а пассивный – просто объектом. Задачи отмечаются на диаграммах параллельной кооперации, которые позволяют наглядно представить параллелизм в системе [4]. На такой диаграмме задача показывается в виде прямоугольника с жирной границей, а пассивный объект – в виде прямо­угольника с тонкой границей (рис. 2.10, здесь представлена также нотация для множества объектов, возникающих при порождении нескольких объектов одного класса).

Рис. 2.10. Нотация UML для активных и пассивных объектов

2.8.1. Обмен сообщениями на диаграммах параллельной кооперации. Интерфейс для обмена сообщениями на диаграмме параллельной кооперации может быть слабо связанным (loosely coupled) или сильно связанным (tightly coupled). В последнем случае производитель посылает сообщение потребителю и ожидает немедленного подтверждения. Сильно связанный обмен бывает двух видов: сильно связанный обмен сообщениями с ответом и сильно связанный обмен сообщениями без ответа.

Нотация UML для нескольких видов обмена сообщениями представлена на рис. 2.11. На рис. 2.12 изображен вариант диаграммы кооперации с активными объектами (параллельными задачами или процессами), а также разные типы пе­редачи информации между ними.

2.9. Диаграммы развертывания

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

Узлом, как правило, является компьютер, при этом макси­мальное число экземпляров узла может быть ограничено (см. раздел 2.10). Для физического соединения имеется стереотип, задающий тип соединения, например «локальная сеть» или «глобальная сеть». На рис. 2.13 показаны узлы двух ти­пов: банкомат (каждый такой клиент занимает ровно один узел), соединенный с банковским сервером, который также размещен в одном узле. В кубе, представ­ляющем узел, могут также изображаться объекты, находящиеся в этом узле. Во втором примере, где несколько клиентов и серверов соединены локальной сетью, сама сеть также присутствует в виде узла. Подобная нотация применяется в тех случаях, когда в сети есть более двух узлов-компьютеров.

Рис. 2.11. Нотация UML для сообщений

Рис. 2.12. Нотация UML для параллельной диаграммы кооперации

Рис. 2.13. Нотация UML для диаграммы развертывания

2.10. Механизмы расширения UML

В UML имеются три механизма расширения языка [3]:

– стереотипы. Стереотип определяет новый строительный блок, производ­ный от существующего в UML элемента моделирования, но адаптирован­ный к решаемой задаче. В UML определено несколько стандартных стереотипов, но проектировщик может создавать и собствен­ные. Названия стереотипов заключаются в кавычки. На рис. 2.1 два вида зависимостей между прецедентами отмече­ны  стереотипами  «include»  и  «extend». На  рис. 2.9 представлены стереоти­пы «система» и «подсистема» для обозначения разных видов пакетов. На рис. 2.10 стереотипы помогают отличить активные объекты от пассивных: ак­тивному объекту соответствует стереотип «задача», а пассивному – «объект». На рис. 2.11 с помощью стереотипов задаются разные виды сообщений;

– помеченные значения. Помеченное значение расширяет свойства строитель­ного блока UML, сообщая тем самым новую информацию. Оно заключается в фигурные скобки {метка = значе­ние}. Друг от друга помеченные значения отделяются запятыми. Например, класс на рис. 2.14 имеет два помеченных значения (номер версии и автор): {версия = 1.0, автор = Gill};

Рис. 2.14. Нотация UML

для помеченных значений и ограничений

– ограничения. Ограничение задает условие, которое должно выполняться. В UML ограничение семантически расширяет элемент, добавляя новые пра­вила или изменяя существующие. Например, в классе Счет на рис. 2.14 есть ограничение на  атрибут  баланс, состоящее в том, что баланс не  должен  быть  отрицательным {баланс ≥ 0}. Помимо этого, в состав UML входит объектный язык ограничений Object Constraint Language [15].