WEBVTT

00:00:07.074 --> 00:00:08.635
Здравствуйте, уважаемые студенты.

00:00:09.475 --> 00:00:14.678
Тема сегодняшней лекции — использование
языка моделирования omel для моделирования

00:00:14.758 --> 00:00:16.318
информационных систем.

00:00:16.878 --> 00:00:22.121
Рассмотрим вопрос моделирования
интерфейсов, интерфейсов

00:00:22.865 --> 00:00:25.467
Подзаголовок: интерфейсы, типы роли.

00:00:27.028 --> 00:00:31.511
Интерфейс определяет границу между
спецификацией того, что делает абстракция,

00:00:31.551 --> 00:00:33.473
и реализацией того, как она это делает.

00:00:33.593 --> 00:00:37.475
Интерфейс — это набор операций,
используемых для специфицирования услуг,

00:00:37.796 --> 00:00:39.917
предоставляемых классам или компонентом.

00:00:40.273 --> 00:00:46.314
Тут напомню, что по правилам Email
интерфейс не может содержать атрибутов,

00:00:46.394 --> 00:00:50.875
только операции. Интерфейсы используются
для визуализации, специфицирования,

00:00:50.915 --> 00:00:55.435
конструирования и документирования
стыковочных узлов между составными частями

00:00:55.555 --> 00:00:56.155
системы.

00:00:56.577 --> 00:01:00.661
Типы и роли обеспечивают механизм
моделирования статического и динамического

00:01:00.781 --> 00:01:03.984
соответствия абстракции интерфейсу в
конкретном контексте.

00:01:06.546 --> 00:01:10.790
Графическое представление интерфейса
показано на следующем рисунке.

00:01:10.990 --> 00:01:16.075
То есть такая нотация позволяет раздельно
визуализировать описание абстракции и её

00:01:16.355 --> 00:01:17.036
реализацию.

00:01:18.394 --> 00:01:22.797
То есть интерфейсы обозначаются как
кружочек.

00:01:23.357 --> 00:01:29.801
В данном случае интерфейсы прикрепляются к
компоненту, то есть, соответственно, это

00:01:30.442 --> 00:01:34.164
элемент физической системы, модель
компонентов.

00:01:34.362 --> 00:01:39.636
Ну, в данном случае к компоненту Word
Smith подключено три интерфейса.

00:01:40.276 --> 00:01:45.430
Это, как мы говорили с вами, сокращённое
обозначение интерфейса, то есть в виде

00:01:45.510 --> 00:01:48.706
кружочка, есть ещё более расширенное, как
стереотипный класс.

00:01:51.682 --> 00:01:55.246
Интерфейсом. Интерфейс называется набор
операций, используемых для

00:01:55.326 --> 00:01:58.769
специфицирования услуг, предоставляемых
классом или компонентом.

00:01:58.929 --> 00:02:00.451
Типом тайп.

00:02:00.571 --> 00:02:05.536
Называется стереотип класса, используемый
для определения области значения объектов

00:02:06.057 --> 00:02:09.260
вместе с применимыми к ним операциями, но
не методами.

00:02:10.578 --> 00:02:14.340
Роль, роу — это поведение сущности в
данном контексте.

00:02:14.500 --> 00:02:18.101
Графический интерфейс изображается в виде
кружочка в развёрнутой форме его можно

00:02:18.262 --> 00:02:23.224
представить как стереотипный класс, чтобы
раскрыть операции другие свойства.

00:02:27.306 --> 00:02:31.708
Обращаю внимание на то, что роль — это
более чисто концептуальное понятие.

00:02:32.188 --> 00:02:34.029
То есть несколько неформальное.

00:02:34.429 --> 00:02:41.070
То есть это именно через роль показывается
каким лицом

00:02:41.550 --> 00:02:44.711
к внешнему миру обращается тот или иной
объект.

00:02:45.191 --> 00:02:49.072
А интерфейс — это более формальное
понятие, то есть предполагается набор

00:02:49.312 --> 00:02:51.312
операций заданным форматом.

00:02:51.837 --> 00:02:54.316
Соответственно, параметры, типы этих
параметров.

00:02:55.115 --> 00:03:02.112
То есть, тоже, в принципе, назначение, то
есть сказать, в каком

00:03:02.232 --> 00:03:06.550
контексте в данном случае данный объект
будет взаимодействовать или каким-то

00:03:06.630 --> 00:03:08.788
образом другим общаться с внешним миром.

00:03:09.864 --> 00:03:14.467
Вот, но уже более формально посредством
операций описывается этот момент.

00:03:14.867 --> 00:03:19.470
Собственно, при описании ассоциаций, как
мы с вами рассматривали, может

00:03:19.710 --> 00:03:21.911
использоваться как интерфейс, так и роль.

00:03:22.472 --> 00:03:25.233
Там есть структура, соответственно,
правила записи.

00:03:26.330 --> 00:03:30.691
Имя роли,точие, имя интерфейса на концах
ассоциации.

00:03:31.811 --> 00:03:37.173
В зависимости от того, какая модель может
быть указана только одной из них, то есть

00:03:37.333 --> 00:03:39.654
либо только роль, либо только интерфейс.

00:03:40.414 --> 00:03:43.175
Вообще эти понятия друг другу не
противоречащие, а скорее

00:03:43.255 --> 00:03:44.215
взаимодополняемые.

00:03:47.107 --> 00:03:50.588
С помощью интерфейсов можно также
специализировать контракт, который

00:03:51.188 --> 00:03:54.228
обязуется выполнять прецедент или
подсистема.

00:03:56.589 --> 00:04:00.749
Имена. У любого интерфейса должно быть
имя, отличающее его от остальных.

00:04:00.829 --> 00:04:04.790
Имя интерфейса представляет собой
текстовую строку, взятое само по себе, оно

00:04:04.870 --> 00:04:05.910
называется простым.

00:04:06.699 --> 00:04:10.659
Составное имя образуется путём добавления
в его начало имени пакета, в который

00:04:10.939 --> 00:04:14.339
входит данный интерфейс. То есть имя
интерфейса должно быть уникальным

00:04:14.739 --> 00:04:16.099
всеобъемлющего пакета.

00:04:16.459 --> 00:04:19.979
При изображении интерфейса можно
ограничиться только его именем.

00:04:23.700 --> 00:04:27.420
На данном слайде приводятся примеры —
простые составные имена.

00:04:28.345 --> 00:04:32.266
Видите, все интерфейсы обозначены в
сокращённой форме, то есть в виде

00:04:32.346 --> 00:04:38.627
кружочка. Между именем пакета и именем
интерфейса ставится двойное двоеточие.

00:04:38.908 --> 00:04:44.909
Как мы говорили, хорошим тоном является
давать имена интерфейсам, начинающимся с

00:04:44.949 --> 00:04:46.309
буквы Ай, то есть И.

00:04:46.771 --> 00:04:49.768
...и анон, и Spal, и сенсор.

00:04:50.368 --> 00:04:54.204
Так, ну вот на данном примере простые
имена показаны, содержится только имя

00:04:54.404 --> 00:04:56.042
соответствующего интерфейса.

00:04:56.362 --> 00:04:58.880
Составное имя включает ещё имя пакета.

00:04:58.999 --> 00:05:01.037
Причём уровень пакетов может быть

00:05:02.089 --> 00:05:03.770
Соответственно, не один, а несколько.

00:05:03.930 --> 00:05:08.213
То есть тогда через двойное двоеточие
будет указано имя объемлющего пакета, имя

00:05:08.293 --> 00:05:11.214
текущего пакета и наконец, собственно, сам
элемент.

00:05:11.495 --> 00:05:12.775
В данном случае интерфейс.

00:05:16.703 --> 00:05:21.538
Операции. Мы говорили, что интерфейс,
собственно, представляет собой именованный

00:05:21.658 --> 00:05:26.294
набор операций. В отличие от классов и
типов, интерфейсы не описывают структуру,

00:05:26.453 --> 00:05:28.651
поэтому не могут содержать атрибуты.

00:05:29.011 --> 00:05:32.088
Это вот особенность именно UL ирезации.

00:05:32.128 --> 00:05:35.125
А значит, не содержит реализующих операций
и методов.

00:05:35.245 --> 00:05:35.844
То есть класс

00:05:36.453 --> 00:05:40.693
Как и как и класс, интерфейс может
включать любое число операций, которые

00:05:40.973 --> 00:05:46.653
могут быть дополнены свойствами видимости
параллельности, стереотипами, помеченными

00:05:46.733 --> 00:05:48.573
значениями и ограничениями.

00:05:52.733 --> 00:05:54.693
Упрощённое изображение интерфейса.

00:05:54.773 --> 00:05:56.893
То есть, изображая интерфейс в виде
кружочка

00:05:59.746 --> 00:06:06.099
Самым обычным образом Вы по определению
подавляете показ этих операций.

00:06:06.219 --> 00:06:11.253
Однако, если это необходимо для понимания
модели, можно изобразить интерфейс как

00:06:11.373 --> 00:06:15.089
стереотипный класс, перечислив операции в
соответствующем разделе.

00:06:16.637 --> 00:06:20.991
При этом можно показывать только имя
операции или же предоставлять развёрнутое

00:06:21.031 --> 00:06:23.188
описание сигнатурой и другими свойствами.

00:06:23.548 --> 00:06:27.623
Как дополнительное свойство может быть
набор сигналов, который воспринимает

00:06:29.300 --> 00:06:29.940
непосредственно

00:06:42.885 --> 00:06:44.446
Данный интерфейс.

00:06:44.806 --> 00:06:51.727
Так, вот на данном слайде показан
интерфейс как стереотипный класс.

00:06:51.847 --> 00:06:56.407
Как видите, тут в кавычках записано:
«интерфейс слова», то есть указано, что

00:06:56.527 --> 00:06:59.168
это не просто класс, а это именно
интерфейс.

00:06:59.448 --> 00:06:59.888
Соответственно

00:07:01.868 --> 00:07:07.795
Поле, которое отводится под атрибуты
пустое по интерфейсу по-другому и быть не

00:07:07.875 --> 00:07:11.599
может. И, соответственно, записано набор
операций операций.

00:07:11.679 --> 00:07:16.925
То есть Open Connection Pars Sap or X
form.

00:07:17.764 --> 00:07:24.206
Так, то есть вот такой специфический
интерфейс какой-то управления URL Stream

00:07:31.048 --> 00:07:33.928
Примечание. С интерфейсом можно
ассоциировать и сигналы.

00:07:36.546 --> 00:07:39.946
То есть вот можно, соответственно, тут
добавить дополнительный раздел.

00:07:41.306 --> 00:07:45.145
Соответственно, имя этого раздела указать
как сигналы.

00:07:47.185 --> 00:07:53.864
Соответственно, в этом разделе уже можно
записать сигналы, которые данный объект,

00:07:53.944 --> 00:07:56.024
ну, в данном случае интерфейс будет
воспринимать.

00:08:00.728 --> 00:08:05.207
Отношения. Подобно классам, интерфейсы
могут принимать участие в отношениях

00:08:05.287 --> 00:08:07.606
обобщения, ассоциации и зависимости.

00:08:08.006 --> 00:08:12.445
Кроме того, для них определено ещё
отношение реализации, представляющее собой

00:08:12.485 --> 00:08:15.245
семантическое отношение между двумя
классификаторами.

00:08:15.525 --> 00:08:19.164
Один из которых определяет ряд
обязательств, то есть контракт.

00:08:19.669 --> 00:08:21.684
А другой обеспечивает их выполнение.

00:08:35.917 --> 00:08:39.633
Интерфейсы и классы. Интерфейс
специфицирует контракт класса или

00:08:39.793 --> 00:08:43.069
компонента, но не накладывает никаких
ограничений на реализацию.

00:08:43.189 --> 00:08:46.745
То есть класс или компонент могут
реализовывать несколько интерфейсов.

00:08:47.105 --> 00:08:47.824
При этом они

00:08:48.952 --> 00:08:53.237
Обязуется выполнять все свои контракты, то
есть должны содержать методы, корректно

00:08:53.318 --> 00:08:55.640
резующие объявленные интерфейсом операции.

00:08:56.241 --> 00:09:01.047
Точно так же класс или компонент может
зависеть от нескольких интерфейсов.

00:09:03.690 --> 00:09:05.212
Интерфейсы и компоненты.

00:09:05.635 --> 00:09:11.276
При этом интерфейс ожидает, что
объявленные контракты будут выполняться

00:09:11.476 --> 00:09:14.517
каким-то набором реализующих их
компонентов.

00:09:14.637 --> 00:09:17.837
То есть, собственно, все декларируемые
операции должны быть так или иначе

00:09:17.917 --> 00:09:22.118
реализованы. Именно поэтому говорят, что
интерфейс представляет собой стыковочный

00:09:22.158 --> 00:09:22.958
узел в системе.

00:09:23.652 --> 00:09:25.609
Он определяет условия контракта.

00:09:25.809 --> 00:09:30.803
После чего обе стороны, и клиент, и
поставщик, могут действовать независимо

00:09:30.923 --> 00:09:35.079
друг от друга, полностью полагаясь,
полагаясь на взаимные обязательства.

00:09:35.998 --> 00:09:37.875
Собственно, в этом и суть реализации.

00:09:42.214 --> 00:09:45.377
Связь интерфейса с реализующим его
элементом можно графически представить

00:09:45.657 --> 00:09:48.660
двумя способами. Во-первых, существует
простая форма.

00:09:48.820 --> 00:09:51.943
Отношение между интерфейсом его
реализацией изображается кружочком со

00:09:52.023 --> 00:09:56.507
стороны класса или компонента способ
удобен.

00:09:57.548 --> 00:09:59.830
Так, ну имеется в виду класс или
компонент.

00:10:00.405 --> 00:10:04.125
Соответственно, просто интерфейс
подрисовывается, как мы вот уже приводили

00:10:04.285 --> 00:10:09.685
не ряд примеров. В виде кружочка
реализация, собственно, линия реализации в

00:10:09.725 --> 00:10:11.925
этом случае показана прямой линией.

00:10:13.764 --> 00:10:18.444
Этот способ удобен, когда требуется
показать стыковочные узлы системы как

00:10:18.524 --> 00:10:19.044
таковые.

00:10:19.586 --> 00:10:23.983
Однако операции и сигналы, предоставляемые
интерфейсом таким способом визуализировать

00:10:24.182 --> 00:10:29.978
нельзя. Ну вот, собственно, для этого и
используется расширенный

00:10:31.217 --> 00:10:34.255
способ представления интерфейса как
стереотипного класса.

00:10:35.415 --> 00:10:37.294
Визуализация и реализация интерфейса.

00:10:37.454 --> 00:10:40.852
Во-вторых, можно воспользоваться
расширенной формой, когда интерфейс

00:10:40.932 --> 00:10:45.090
представляет в виде стереотипного класса и
связывает с отношением реализации

00:10:45.250 --> 00:10:47.129
классификатором или компонентом.

00:10:47.369 --> 00:10:51.247
При этом разрешается показывать его
операции и другие свойства.

00:10:51.367 --> 00:10:55.365
Ну, то есть имеется в виду, возможно,
параметры и типы.

00:10:56.171 --> 00:11:02.218
этих операций возвращаемые значения,
свойства синхронизации, ну и масса других

00:11:02.299 --> 00:11:04.862
свойств, которые, в принципе, мы уже с
вами рассмотрели.

00:11:05.342 --> 00:11:09.628
В обоих случаях класс или компонент,
использующий интерфейс, соединяет с ним

00:11:09.828 --> 00:11:11.110
отношением зависимости.

00:11:17.923 --> 00:11:21.722
Так, на данном слайде показаны как раз
примеры визуализации интерфейса.

00:11:22.042 --> 00:11:28.320
То есть, соответственно, как видите, нужно
различать реализуемые непосредственно

00:11:28.520 --> 00:11:29.120
интерфейсом

00:11:30.878 --> 00:11:33.038
непосредственно каким-то классом.

00:11:33.117 --> 00:11:36.356
Ну, в данном случае на абстрактном уровне
классом интерфейс.

00:11:36.636 --> 00:11:41.194
И другие классы сторонние, которые
используют этот самый интерфейс.

00:11:41.714 --> 00:11:44.513
В данном случае, собственно, реализация.

00:11:44.913 --> 00:11:48.311
Как видите, на первом верхнем рисунке
показана прямой линией.

00:11:48.431 --> 00:11:50.350
Соответственно, интерфейс abzover.

00:11:50.920 --> 00:11:55.085
Обозреватель и класс Tagi-трекер.

00:11:55.165 --> 00:11:59.491
Предполагается, что интерфейс Обзервер
реализуется классом Tagi-Traker.

00:11:59.931 --> 00:12:05.218
В то время как просто трекер использует
уже готовый интерфейс Обзёр.

00:12:05.338 --> 00:12:05.819
В данном случае

00:12:07.154 --> 00:12:10.235
Он связывает соотношение зависимости с
этим интерфейсом.

00:12:10.675 --> 00:12:13.476
Ну и снизу приведена более подробная
структура.

00:12:13.636 --> 00:12:20.199
Тут показано, что, собственно, какой-то
класс теджит является наследником класса,

00:12:20.399 --> 00:12:22.480
соответственно. Показано.

00:12:23.691 --> 00:12:29.806
Название пакетов в пакете Джаво, подпакет
Util и, соответственно,

00:12:31.205 --> 00:12:32.884
какой-то пакет от ёрбл.

00:12:32.924 --> 00:12:35.522
В нём находится непосредственно класс
Taget.

00:12:35.842 --> 00:12:39.079
Вот, с описаны его атрибуты и операции.

00:12:40.144 --> 00:12:44.550
Интерфейс обзовер уже показан в
развёрнутой форме, в виде стереотипного

00:12:44.670 --> 00:12:50.278
класса. В этом случае, как видите,
собственно, класс, реализующий его в

00:12:50.358 --> 00:12:53.763
данном случае теджи-трекер, тот же самый,
связан уже

00:12:56.287 --> 00:12:58.165
Линия реализации уже другого вида.

00:12:58.325 --> 00:13:01.921
То есть, в принципе, и то, и то есть
реализация, и то, и то указано, что

00:13:02.600 --> 00:13:07.795
указывает на то, что интерфейс Abir
реализуется посредством класса

00:13:08.035 --> 00:13:09.513
Педжи-трекер.

00:13:10.032 --> 00:13:13.509
Вот, но только по правилам AML стрелочки
разные, как видите.

00:13:14.057 --> 00:13:17.776
В первом случае стрелочка вообще
отсутствует, просто прямая линия.

00:13:17.896 --> 00:13:19.775
Важно не путать с ассоциацией.

00:13:20.135 --> 00:13:24.014
Вот. Но признаком того, что это есть
реализация, является интерфейс на конце

00:13:24.934 --> 00:13:26.853
этого отношения. Так.

00:13:26.933 --> 00:13:29.293
Ну, или вот классическое обозначение.

00:13:30.735 --> 00:13:34.140
Отношение реализации поте посредством
пунктирной стрелочки с закрытым

00:13:34.861 --> 00:13:38.065
наконечником с закрытой стрелочкой.

00:13:38.505 --> 00:13:43.351
Ну и, собственно, класс Taget уже
использует данный интерфейс обзора,

00:13:43.431 --> 00:13:45.995
который реализован посредством класса
Tagetraker.

00:13:54.995 --> 00:13:57.638
Интерфейсы стыковочные узлы системы.

00:13:57.758 --> 00:14:01.121
Интерфейс напоминают абстрактные классы, в
частности, потому что у них нет

00:14:03.462 --> 00:14:07.023
Что ни у тех, ни у других нет
непосредственных экземпляров.

00:14:07.343 --> 00:14:10.943
Но всё же между ними имеется достаточно
различий, чтобы считать их отдельными

00:14:11.023 --> 00:14:15.344
элементами моделирования. У абстрактного
класса могут быть атрибуты, а у интерфейса

00:14:15.504 --> 00:14:19.345
нет. Кроме того, интерфейсы пересекают
границы модели, то есть являясь

00:14:19.385 --> 00:14:20.785
стыковочными узлами системы.

00:14:21.181 --> 00:14:24.583
Например, один и тот же интерфейс может
быть реализован как классом.

00:14:24.623 --> 00:14:29.226
Ну, имеется в виду, если на абстрактном
уровне, так и компонентом, если мы

00:14:29.306 --> 00:14:30.747
рассматриваем физическую модель.

00:14:34.882 --> 00:14:39.598
На языке MoL вы можете связывать с
интерфейсом значительно больше информации,

00:14:39.718 --> 00:14:41.237
чтобы сделать его понятнее.

00:14:41.357 --> 00:14:45.794
Можно писать предусловия и потусловия для
каждой операции, а также инварианты для

00:14:45.874 --> 00:14:47.433
класса или компонентов в целом.

00:14:47.553 --> 00:14:50.510
Как мы говорили, для этого используются
стереотипные

00:14:52.140 --> 00:14:56.097
Комментарий. К интерфейсу можно
присоединить автомат и использовать его

00:14:56.257 --> 00:15:00.094
для специфицирования корректной части
упорядоченности операций.

00:15:00.613 --> 00:15:04.970
С ним допустимо связать кооперации,
описывающие ожидаемое поведение интерфейса

00:15:05.090 --> 00:15:07.208
с помощью последовательности диаграмм
взаимодействия.

00:15:14.527 --> 00:15:19.887
Типы и роли. Класс может реализовывать
несколько интерфейсов.

00:15:20.007 --> 00:15:23.967
Любой экземпляр данного класса должен
поддерживать их все, так как интерфейс

00:15:24.087 --> 00:15:25.847
определяет условия контракта.

00:15:26.087 --> 00:15:29.407
И все соответствующие ему абстракции
обязаны соблюдать эти условия.

00:15:29.567 --> 00:15:33.287
Тем не менее, в конкретном контексте
экземпляр может предоставлять только те

00:15:33.447 --> 00:15:35.687
интерфейсы, которые соответствуют
ситуации.

00:15:36.427 --> 00:15:40.832
Это означает, что каждый интерфейс
определяет роль, которую играет объект.

00:15:43.516 --> 00:15:47.681
Роль таким образом, это именованное
поведение некоторой сущности в конкретном

00:15:47.801 --> 00:15:51.606
контексте, или иными словами, лицо,
которым абстракция обращено к миру.

00:15:52.148 --> 00:15:54.590
Роли принимают участие также в
кооперациях.

00:15:55.031 --> 00:15:58.914
Ну, имей в виду, что роль — это такое
несколько концептуальное, несколько

00:15:59.194 --> 00:16:00.756
неформальное понятие.

00:16:01.236 --> 00:16:08.002
То есть предполагает просто некоторый
определённый контекст, не описывая

00:16:08.203 --> 00:16:10.405
подробности самого взаимодействия.

00:16:12.273 --> 00:16:16.194
То есть, скажем, в данном случае человек
играет роль работодателя, а другой человек

00:16:16.474 --> 00:16:18.755
играет роль наоборот наёмного рабочего.

00:16:19.475 --> 00:16:24.556
Так. На языке OML роль, которую одна
абстракция играет по отношению к другой,

00:16:24.876 --> 00:16:28.756
можно описать, дополнив соответствующую
концевую точку ассоциации именем

00:16:28.876 --> 00:16:31.117
интерфейса, ну или, собственно, именем
роли.

00:16:32.698 --> 00:16:36.697
Как мы говорили, связка интерфейс роли
через двоеточие.

00:16:36.777 --> 00:16:39.815
Сначала идёт имя роли, потом имя
интерфейса.

00:16:41.455 --> 00:16:46.053
Интерфейсы и роли. Например, на следующем
рисунке будет показан интерфейс «Ротник»,

00:16:46.133 --> 00:16:48.492
определение которого включает три
операции.

00:16:56.998 --> 00:17:00.835
Между классами «Человек и компания»
существует ассоциация, в контексте которой

00:17:00.995 --> 00:17:04.553
человек играет роль, относящаяся к типу
работника.

00:17:04.593 --> 00:17:08.070
В другой ассоциации этот класс может быть
обращён к миру иным лицом.

00:17:08.350 --> 00:17:13.146
То есть, возможно, человек будет выступать
наоборот как работодатель.

00:17:15.882 --> 00:17:19.522
В данном случае, видите, описан интерфейс
работника.

00:17:19.922 --> 00:17:23.882
Соответственно, набор три операции: Gent
eployment History.

00:17:24.122 --> 00:17:30.122
То есть получить какую-то историю работ,
как он работал Get compensation, get

00:17:31.778 --> 00:17:37.697
Соответственно, два класса: человек и
компании связаны посредством ассоциаций,

00:17:37.777 --> 00:17:40.737
то есть обозначаются в ОМЛ как сплошная
линия.

00:17:41.257 --> 00:17:45.536
Соответственно, здесь предполагается

00:17:47.377 --> 00:17:49.336
Указана роль работник.

00:17:49.375 --> 00:17:55.572
Ну, как раз роль — это вот этот первый
элемент, а работник — это, собственно, уже

00:17:55.892 --> 00:17:58.731
интерфейс. В данном случае интерфейс
работника.

00:17:59.010 --> 00:18:03.848
Эти вещи, то есть, собственно, роль
интерфейса иногда между собой считают

00:18:03.888 --> 00:18:04.927
синонимами, хотя

00:18:05.585 --> 00:18:07.906
Собственно, в OML есть чёткое различие.

00:18:08.306 --> 00:18:11.548
Роль — это как бы некоторое такое
неформальное понятие, интерфейс — это

00:18:11.588 --> 00:18:14.550
чётко заданная структура, вот как здесь
описано.

00:18:14.750 --> 00:18:16.071
Задано три операции.

00:18:16.151 --> 00:18:21.034
Правда, не показаны параметры, которые, в
принципе, тоже могут быть.

00:18:22.447 --> 00:18:26.046
Так, ну и вот, собственно, связь,
множественность на концах ассоциации один

00:18:26.286 --> 00:18:31.205
ко многим. То есть предполагается компания
одна, со стороны человек может быть много

00:18:32.005 --> 00:18:33.564
работников компании.

00:18:36.044 --> 00:18:37.683
Так, собственно, вот роль.

00:18:38.001 --> 00:18:43.476
Как мы говорили, такая структура, как имя
роли, двоеточие, имя интерфейса.

00:18:43.955 --> 00:18:48.151
На концах ассоциаций может быть варианты
показано, только роль.

00:18:51.548 --> 00:18:55.783
Если, соответственно, роль, как у нас там
был на первых примерах

00:18:56.745 --> 00:18:58.547
Обучающий, обучаемый.

00:18:59.988 --> 00:19:04.911
Может быть показано, соответственно,
только название интерфейса

00:19:12.477 --> 00:19:15.439
MJ, то есть как бы менеджер управляющий.

00:19:16.059 --> 00:19:21.018
А может быть указано и имя роли, и имя
интерфейса, как вот в данном случае.

00:19:21.218 --> 00:19:24.656
В данном случае роль — интерфейс
работника.

00:19:28.375 --> 00:19:30.375
Статическое, динамическое связывание.

00:19:30.495 --> 00:19:33.894
Диаграмма классов, подобное приведённой
выше, полезна для моделирования

00:19:34.014 --> 00:19:36.533
статического связывания абстракции с его
интерфейсом.

00:19:37.243 --> 00:19:41.399
То есть вот у нас структура интерфейса
есть, есть классы.

00:19:41.799 --> 00:19:45.156
Мы, соответственно, связали человека с
такой-то компанией.

00:19:45.475 --> 00:19:49.751
Вот. Ну и считаем, что такое положение
будет у нас постоянно.

00:19:49.911 --> 00:19:53.587
То есть, собственно, статическая
типизация, статическое связывание.

00:19:54.416 --> 00:19:57.418
Динамическое связывание абстракции с
интерфейсом моделируется с помощью

00:19:57.458 --> 00:20:01.140
стереотипа бикам на диаграмме
взаимодействия, отражающего смену объектов

00:20:01.340 --> 00:20:06.062
объекта. То есть можно, допустим, какой-то
класс, который

00:20:08.744 --> 00:20:12.145
был, например, студентом, стал аспирантом.

00:20:12.782 --> 00:20:14.740
Был абитуриентом, стал студентом.

00:20:14.860 --> 00:20:16.258
Вот таким образом показать.

00:20:16.378 --> 00:20:20.374
При этом, собственно, обращаю внимание,
что сам объект остался тем же самым,

00:20:20.534 --> 00:20:24.610
изменилась его роль или в некоторых
случаях тип, если это допустимо.

00:20:27.103 --> 00:20:28.424
Ну, к этому мы ещё вернёмся.

00:20:28.745 --> 00:20:32.508
Типы. Для формального моделирования
семантики абстракции и её соответствия

00:20:32.548 --> 00:20:35.872
некоторому интерфейсу применяется
предопрелетный стереотип тап.

00:20:37.532 --> 00:20:41.449
Это стереотип класса с его помощью
определяет область действия объектов

00:20:41.569 --> 00:20:45.887
совместно с операциями, но не методами,
применями к объектам этого типа.

00:20:46.047 --> 00:20:51.204
Концепция типа тесно связана с концепцией
интерфейса, только описание типа может

00:20:51.524 --> 00:20:52.763
содержать атрибуты.

00:20:53.367 --> 00:20:55.049
А описания интерфейса нет.

00:20:55.249 --> 00:20:59.375
То есть, в принципе, если для нас,
собственно, набор атрибутов неважен, то

00:20:59.455 --> 00:21:01.498
лучше использовать интерфейсы.

00:21:04.183 --> 00:21:07.904
Статическая типизация. Если надо показать,
что некоторая абстракция статически

00:21:08.064 --> 00:21:12.705
типизирована, используется стереотип
Implimination Class, который специфицирует

00:21:12.745 --> 00:21:16.105
класс со статически типизированными
экземплярами и определяет физическую

00:21:16.185 --> 00:21:20.786
структуру данных и методы объекта так, как
это делается в традиционных языках

00:21:20.866 --> 00:21:21.546
программирования.

00:21:27.634 --> 00:21:30.639
В большинстве случаев понятно, типы
интерфейсов взаимозаменяемы.

00:21:30.759 --> 00:21:35.447
Вот только помним, что в соответствии с
правилом UL, интерфейс не может содержать

00:21:35.527 --> 00:21:37.330
структурные части, то есть атрибутов.

00:21:42.197 --> 00:21:44.358
Рекомендации к моделированию стыковочных
узлов.

00:21:44.438 --> 00:21:49.241
Изобразив набор классов и компонентов
системы, проведите линии, отделяющие друг

00:21:49.401 --> 00:21:52.403
от друга группы тесно связанных классов и
компонентов.

00:21:52.803 --> 00:21:56.365
Уточните выбранное разделение с учётом
изменяемости системы.

00:21:56.485 --> 00:22:00.007
Совместно изменяемые классы или компоненты
должны быть сгруппированы в отдельные

00:22:00.087 --> 00:22:00.808
кооперации.

00:22:01.417 --> 00:22:05.652
Изучите операции и сигналы, которые
пересекают определённые вам границы.

00:22:05.772 --> 00:22:09.567
Объедините логически связанный набор
операций и сигналов, оформив их как

00:22:09.767 --> 00:22:13.722
интерфейсы. За каждой обнаруженной
системой коопераций

00:22:15.670 --> 00:22:19.755
Идентифицируйте интерфейсы, на которые она
полагается в своей работе, то есть

00:22:19.915 --> 00:22:24.641
импортирует и те, которые она представляет
другим, то есть экспортирует.

00:22:25.001 --> 00:22:30.408
Импорт интерфейсов моделируется с помощью
отношения зависимости, а экспорт с помощью

00:22:30.488 --> 00:22:31.729
отношения реализации.

00:22:33.092 --> 00:22:36.968
Документируйте динамику интерфейсов с
помощью предусловий и спорт-условий для

00:22:37.088 --> 00:22:42.763
каждой операции, а также прецедентов и
автоматов для интерфейса в целом, если это

00:22:43.003 --> 00:22:49.997
необходимо Например, на рисунке изображены
стыковочные узлы библиотеки

00:22:50.117 --> 00:22:52.435
LetGer DL, динамической библиотеки.

00:22:53.573 --> 00:22:56.012
компонента, взятого из финансовой системы.

00:22:56.292 --> 00:22:58.651
Этот компонент реализует три интерфейса.

00:22:59.291 --> 00:23:05.608
Соответственно, как видите, idger или

00:23:06.487 --> 00:23:08.167
Repots, и стриминг

00:23:13.912 --> 00:23:17.237
На диаграмме первый из них показан в
расширенной форме, остальные два в

00:23:17.317 --> 00:23:23.886
сокращённой. Вот интерфейс ya Non показан
в

00:23:23.966 --> 00:23:24.767
расширенной форме.

00:23:29.933 --> 00:23:34.577
Все три интерфейса реализуются компонентом
lodger DL и экспортируются другие

00:23:34.657 --> 00:23:37.380
компоненты, которые используют их в своей
работе.

00:23:37.540 --> 00:23:41.423
То есть, собственно, logger DL ещё раз
посмотрим.

00:23:42.064 --> 00:23:47.869
Реализуют интерфейсы Yon, который показан
развёрнуто со всеми, как видите.

00:23:48.905 --> 00:23:50.825
...описанными операциями.

00:23:52.305 --> 00:23:56.585
Соответственно, два интерфейса, которые
тоже реализуют данный компонент.

00:23:56.945 --> 00:24:00.665
Показаны в сокращённом виде, lager, и
repots.

00:24:01.145 --> 00:24:05.865
Вот. Соответственно, указывается, что сам

00:24:07.767 --> 00:24:14.049
Компонент Logger DL использует интерфейсы
стриминг из каких-то системных библиотек

00:24:14.809 --> 00:24:21.452
обработки потоковых систем.

00:24:21.852 --> 00:24:25.253
Кроме того, используется интерфейс
Itranzaction.

00:24:26.154 --> 00:24:29.590
То есть, который здесь, видите, описан
довольно подробно.

00:24:29.910 --> 00:24:35.583
Указывается, соответственно, набор
операций, четыре операции связанные с

00:24:35.903 --> 00:24:37.821
описанием интерфейса транзакшн.

00:24:37.980 --> 00:24:42.375
И вот то, что до этого у нас таких
примеров не было, дополнительный раздел.

00:24:42.816 --> 00:24:47.297
В дополнительном разделе, в котором
приводятся исключительные ситуации,

00:24:47.417 --> 00:24:50.498
исключения exeption filur.

00:24:52.192 --> 00:24:56.152
То есть предполагается, что во время
работы этого интерфейса может возникнуть

00:24:56.232 --> 00:24:58.072
вот эта самая исключительная ситуация.

00:24:58.272 --> 00:24:59.752
Поскольку это транзакция.

00:25:00.032 --> 00:25:04.792
Транзакция должна в итоге пройти, то есть
окончательно все данные помещены по

00:25:04.832 --> 00:25:06.912
местам. Если до конца это произойти не
может

00:25:08.078 --> 00:25:11.556
То, собственно, нужно реализовать откат и
повторить всё снова.

00:25:12.195 --> 00:25:16.233
То есть по принципу того, что знаем, что
транзакция должна быть атамарной.

00:25:25.662 --> 00:25:30.144
Как видно из диаграммы, компонент Ladger
DL импортирует два интерфейса: и стриминг

00:25:30.304 --> 00:25:33.386
и Tranzaction. Причём последний показан в
расширенной форме.

00:25:33.466 --> 00:25:37.027
Оба нужны компоненты lager DL для
конкретной работы.

00:25:37.107 --> 00:25:40.629
Следовательно, в работающую систему вы
должны будете включить также реализующие

00:25:40.669 --> 00:25:41.550
их компоненты.

00:25:42.193 --> 00:25:46.916
Выделив интерфейс, например, IT
Tranzaction, вы тем самым разъединили

00:25:47.076 --> 00:25:49.637
находящиеся по разные стороны от него
компоненты.

00:25:49.717 --> 00:25:54.040
А это значит, что вы можете использовать
любой компонент, лишь бы он соответствовал

00:25:54.080 --> 00:25:55.761
спецификации интерфейса.

00:25:56.641 --> 00:25:58.082
Вот это, в общем, очень удобно.

00:25:58.202 --> 00:26:00.523
То есть, собственно, показаны эти
стыковочные узлы.

00:26:01.211 --> 00:26:06.610
То есть по одну сторону интерфейс
предполагается, что он будет реализован,

00:26:06.690 --> 00:26:10.770
по другую все могут использовать
возможности данного интерфейса.

00:26:11.370 --> 00:26:15.769
Собственно, если используется интерфейс,
обозначается это отношением зависимости:

00:26:15.809 --> 00:26:17.489
пунктирная линия, открытая стрелочка.

00:26:18.774 --> 00:26:21.376
Если интерфейс реализуется, отношение
реализации.

00:26:21.736 --> 00:26:25.100
Вот в данном случае два способа
обозначения реализации показаны.

00:26:33.685 --> 00:26:35.847
Так, вернёмся к статическим динамическим
типам.

00:26:35.967 --> 00:26:38.490
Большинство объектно-ориентированных
языков в программировании является

00:26:38.810 --> 00:26:40.172
статически типизированными.

00:26:40.292 --> 00:26:43.455
Тип связывается с объектом в момент
создания последнего.

00:26:43.495 --> 00:26:47.419
И всё же объект будет, вероятно, играть
различные роли в разные моменты времени.

00:26:48.018 --> 00:26:52.693
Это означает, что использующие объекты
клиенты взаимодействуют с ним посредством

00:26:52.733 --> 00:26:59.286
различных наборов интерфейсов, которые
описывают представляющий интерфейс и,

00:26:59.326 --> 00:27:01.763
возможно, перекрывающийся множество
операций.

00:27:05.066 --> 00:27:08.462
Модель статических характеристик объекта
может быть визуализирована в виде

00:27:08.502 --> 00:27:11.618
диаграммы классов. Однако при
моделировании таких сущностей, как

00:27:11.698 --> 00:27:15.733
бизнес-объекты, чьи роли, естественно,
изменяются по ходу работы, бывает полезно

00:27:15.853 --> 00:27:20.488
явным образом промоделировать динамическую
природу типа таких объектов.

00:27:21.104 --> 00:27:25.828
В этих условиях объект во время своей
жизни может приобретать и утрачивать типы.

00:27:28.751 --> 00:27:32.515
Так, рекомендации к моделированию
динамического типа состоят из следующих

00:27:32.595 --> 00:27:37.480
шагов: определите возможные типы объекта,
показав каждый из них в виде класса со

00:27:37.560 --> 00:27:38.641
стереотипом тайп.

00:27:39.554 --> 00:27:44.194
Если от абстракции требуется структура и
поведение или интерфейс, если требуется

00:27:44.354 --> 00:27:47.834
только поведение. Ну, то есть можно
обойтись без атрибутов.

00:27:48.274 --> 00:27:52.154
Смоделируйте все роли класса объекта в
любой возможный момент времени.

00:27:52.234 --> 00:27:53.634
Это делается двумя способами.

00:27:53.754 --> 00:27:56.474
Во-первых, на диаграмме классов явно

00:27:57.313 --> 00:28:01.557
Прописывается каждая роль, которую данный
класс играет в ассоциациях с другими

00:28:01.637 --> 00:28:06.241
классами. Тем самым определяется лицо,
которое класс имеет в контекст

00:28:06.321 --> 00:28:07.923
ассоциированного с ним объекта.

00:28:08.283 --> 00:28:13.087
Во-вторых, на диаграмме классов с помощью
обобщения специфицируется отношение класс

00:28:13.128 --> 00:28:13.488
тип.

00:28:14.540 --> 00:28:17.381
На диаграмме взаимодействия изобразите
каждый экземпляр динамически

00:28:17.581 --> 00:28:21.302
типизированного класса. Роль экземпляра
можно указать в скобках ниже имени

00:28:21.422 --> 00:28:26.303
объекта. Чтобы показать смену ролей
объекта, изобразите объект по одному по

00:28:26.423 --> 00:28:30.864
одному разу для каждой роли, которую он
играет во взаимодействии, соедините эти

00:28:31.024 --> 00:28:33.704
объекты сообщением со стереотипом Бикам.

00:28:34.301 --> 00:28:37.984
Так, ну сейчас рассмотрим примеры к этим
рекомендациям.

00:28:38.064 --> 00:28:40.906
Прежде всего, вот моделирование
статических типов.

00:28:41.386 --> 00:28:46.550
Предполагается, что, как видите, человек в
данном случае используется множественное

00:28:46.590 --> 00:28:51.073
наследование, то есть непосредственно весь
набор свойств, атрибутов и операций.

00:28:51.633 --> 00:28:55.549
Что относится к человеку как кандидату, к
человеку как работнику, человеку как

00:28:56.308 --> 00:29:01.422
пенсионеру, наследуется непосредственно в
класс человек.

00:29:01.542 --> 00:29:05.777
То есть вот используется множественное
наследования различных типов.

00:29:08.669 --> 00:29:12.430
В качестве примера показаны роли, которые
класс человек может играть в контексте

00:29:12.470 --> 00:29:14.790
системы управления человеческими
ресурсами.

00:29:15.110 --> 00:29:18.071
То есть, вот кандидат, работник,
пенсионер.

00:29:21.511 --> 00:29:24.992
Динамическая природа типа «человек»
изображена на следующем рисунке.

00:29:25.331 --> 00:29:31.375
В этом фрагменте диаграммы взаимодействия
объект человек меняет роль кандидата на

00:29:31.455 --> 00:29:37.740
работника. То есть непосредственно
П-двоеточие.

00:29:37.860 --> 00:29:41.863
Человек — это указанный класс, к которому
принадлежит экземпляр класса П, то есть

00:29:41.983 --> 00:29:42.423
объект.

00:29:42.921 --> 00:29:46.041
И в квадратных скобках, как видите,
указывается роль.

00:29:46.761 --> 00:29:51.562
Собственно, обращаем внимание на то, что
класс человека не меняется.

00:29:51.602 --> 00:29:53.322
То есть он как был человек, так и есть.

00:29:53.442 --> 00:29:54.642
Меняется только роль.

00:29:55.083 --> 00:30:01.763
Так, вот таким образом, собственно,
средствами ML можно показать динамическую

00:30:01.923 --> 00:30:02.403
природу.

00:30:03.025 --> 00:30:07.145
Изменение классов. По сути, собственно,
здесь класс-то остаются тем же самым,

00:30:07.225 --> 00:30:08.545
меняются только роли.

00:30:08.985 --> 00:30:15.785
Поэтому, собственно, отмечаем, что в самом
языке OML напрямую он не является.

00:30:16.384 --> 00:30:18.225
Не поддерживает динамическую типизацию.

00:30:18.345 --> 00:30:22.666
Ну, можно вот таким образом выкрутиться,
используя именно роли.

00:30:22.786 --> 00:30:26.147
То есть можно считать, что остаётся класс
тем же.

00:30:26.387 --> 00:30:29.989
Экземпляр класса остаётся в том же самом
классе, но меняется его роль.

00:30:30.149 --> 00:30:31.149
Ну, или интерфейс

00:30:32.135 --> 00:30:36.176
Или вот в данном случае дополнительный
тип.

00:30:37.256 --> 00:30:41.017
Используется сообщение Bikam, которое
указывает на то, что человек был

00:30:41.177 --> 00:30:43.017
кандидатом, стал работником.

00:30:46.432 --> 00:30:50.393
Моделируемый интерфейс на языке OML
помните, что он должен описывать некоторый

00:30:50.513 --> 00:30:53.714
стыковочный узел системы, отделяя
спецификацию от реализации.

00:30:53.794 --> 00:30:57.074
Хорошо структурированный интерфейс
характеризуется следующими свойствами.

00:30:57.274 --> 00:31:02.515
Одновременно обладает простотой и
завершённостью, то есть содержит все

00:31:02.795 --> 00:31:06.596
операции, необходимые и достаточные для
специфицирования конкретного сервиса.

00:31:07.252 --> 00:31:12.139
Понятен, то есть содержит информацию
достаточную для применения и не требую для

00:31:12.299 --> 00:31:15.264
этого обращения к его реализации и
примерам использования.

00:31:15.624 --> 00:31:20.271
Содержит информацию достаточную для
понимания пользователем основных свойств.

00:31:22.618 --> 00:31:26.217
Но не перегружен сведениями, касающимися
деталей всех операций.

00:31:26.497 --> 00:31:30.735
Изображая интерфейс на языке OML,
руководствуйтесь приведёнными следующими

00:31:30.855 --> 00:31:34.893
правилами. Используйте сокращённую
нотацию, если нужно просто показать

00:31:35.293 --> 00:31:37.212
наличие стыковочного узла в системе.

00:31:37.412 --> 00:31:41.251
Чаще всего она применяется при работе с
компонентами, а не классами, то есть в

00:31:41.291 --> 00:31:42.090
виде кружочка.

00:31:42.740 --> 00:31:45.421
И просто прямой линией указывается
реализация.

00:31:45.821 --> 00:31:50.344
Расширенную форму применяйте в случае,
если надо визуализировать детали самого

00:31:50.464 --> 00:31:54.786
сервиса. Чаще всего это нужно делать при
специфицировании стыковочных узлов в

00:31:54.826 --> 00:31:57.227
системе, содержащей пакеты или подсистемы.

00:32:07.010 --> 00:32:10.332
Рассмотрим. Следующий вопрос —
моделирование событий и сигналов в

00:32:10.452 --> 00:32:13.734
информационных системах средствами ЗКМ.

00:32:15.855 --> 00:32:17.056
События-сигналы.

00:32:17.176 --> 00:32:21.218
Событие event — это описание существенного
факта, который занимает некоторое

00:32:21.338 --> 00:32:22.859
положение во времени и пространстве.

00:32:22.939 --> 00:32:26.821
В контексте автоматов событие — это
стимул, который может вызвать переход из

00:32:26.942 --> 00:32:28.142
одного состояния в другое.

00:32:29.005 --> 00:32:34.126
Сигнал, сигнал — это вид события, в
котором стимул передаётся синхронно от

00:32:34.246 --> 00:32:35.887
одного экземпляра к другому.

00:32:40.128 --> 00:32:42.368
События, сигналы, примеры моделирования.

00:32:42.448 --> 00:32:47.930
То есть в данном случае показан сигнал как
стереотипный класс.

00:32:48.010 --> 00:32:50.130
То есть трубка повешена как сигнал.

00:32:51.853 --> 00:32:56.893
Вот. Соответственно, в контексте автомата,
видите, переход из состояния активен в

00:32:56.933 --> 00:33:01.932
состояние ожидания. Такой фрагмент
автомата приходит указывает, что,

00:33:02.012 --> 00:33:06.852
собственно, событие «трубка повешенная»
является причиной перехода,

00:33:06.972 --> 00:33:10.212
соответственно, вот данного, который
изображён от активен к ожиданию.

00:33:10.730 --> 00:33:15.931
Ну и при этом, собственно, выполняется ещё
и операция Drop Connection, то есть

00:33:16.251 --> 00:33:19.612
действия, связанные с этим переходом.

00:33:22.933 --> 00:33:25.413
События могут быть внутренними или
внешними.

00:33:25.573 --> 00:33:28.774
Внешние события передаются между системой
и её актёрами.

00:33:29.198 --> 00:33:33.435
Примерами могут служить наличие кнопки или
прерывание от датчика столкновений.

00:33:33.954 --> 00:33:37.632
Внутреннее событие передаётся между
объектами, существующими внутри самой

00:33:37.712 --> 00:33:42.188
системы. Так, исключение, генерируемое при
переполнении, является примером

00:33:42.268 --> 00:33:46.385
внутреннего события. В emaile можно
моделировать четыре вида событий: сигналы,

00:33:46.505 --> 00:33:48.743
вызовы, истечение промежутка времени.

00:33:50.363 --> 00:33:52.004
...и изменения состояния.

00:33:57.567 --> 00:34:02.169
Сигнал — это именованный объект, который
синхронно возбуждается одним объектом и

00:34:02.329 --> 00:34:04.330
принимается, то есть перехватывается
другим.

00:34:05.074 --> 00:34:07.791
Исключения, которые поддерживаются в
большинстве современных языков

00:34:07.911 --> 00:34:10.868
программирования, — это наиболее
распространённый вид внутренних сигналов,

00:34:11.028 --> 00:34:12.907
который вам придётся смоделировать.

00:34:16.743 --> 00:34:19.780
У сигналов есть много общего с классами.

00:34:19.940 --> 00:34:23.696
Например, можно говорить об экземплярах
сигналов, хотя обычно не возникает

00:34:23.776 --> 00:34:25.295
необходимость моделировать их явно.

00:34:25.976 --> 00:34:29.420
Сигналы могут также участвовать в
отношениях обобщения, что позволяет

00:34:29.540 --> 00:34:34.105
моделировать иерархии событий, в которые
одни, например, сигнал сбоя сети является

00:34:34.586 --> 00:34:39.151
общими, а другие, например, специализация
события сбоя сети под названием отказ

00:34:39.431 --> 00:34:41.073
плонского сервера — частными.

00:34:42.165 --> 00:34:45.128
Как и классы, сигналы могут иметь атрибуты
операций.

00:34:45.249 --> 00:34:49.093
Атрибуты сигнала выступают в роли его
параметров.

00:34:49.213 --> 00:34:53.377
Например, при посылке сигнала столкновения
можно указать значение его атрибутов в

00:34:53.417 --> 00:34:57.982
виде параметров: столкновение в скобках
3,5.

00:35:00.504 --> 00:35:02.783
Какой-то параметр. Сигналы в автоматах.

00:35:02.903 --> 00:35:07.060
Сигнал может быть послан как действие
перехода, изменения состояния в автомате

00:35:07.380 --> 00:35:09.978
или как отправка сообщения при
взаимодействии.

00:35:10.618 --> 00:35:14.496
При выполнении операции также могут
посылаться сигналы.

00:35:14.576 --> 00:35:18.613
На практике, когда моделируется класс или
интерфейс важной частью спецификации

00:35:18.773 --> 00:35:19.413
поведения.

00:35:19.965 --> 00:35:22.965
Является указание сигналов, которые он
может посылать.

00:35:23.765 --> 00:35:28.804
В связь между операцией и событиями,
которые она может посылать, моделируется с

00:35:28.844 --> 00:35:34.883
помощью отношения зависимости со
стереотипом "Сент, то есть послать.

00:35:35.643 --> 00:35:37.563
Примеры моделирования в данном случае

00:35:38.551 --> 00:35:44.712
Есть какой-то класс агент перемещения с
атрибутами положения, скорость и операции

00:35:44.913 --> 00:35:48.353
нуфту, то есть двигаться в направлении
таком-то.

00:35:48.673 --> 00:35:53.635
И сигнал, как стереотипный класс показан
со стереотипом сигнал.

00:35:53.915 --> 00:35:56.835
Как видите, сигнал написан по-русски, это,
в принципе, допускается.

00:35:56.966 --> 00:36:00.886
В моделях моей можно использовать и любые
языки.

00:36:00.966 --> 00:36:05.327
Хотя, конечно, сигнал по-английски — это
предопределённый тип.

00:36:05.807 --> 00:36:08.247
Так, ну и в качестве параметра показана
сила.

00:36:08.327 --> 00:36:10.567
Ну, наверное, имеется в виду сила
столкновения.

00:36:10.727 --> 00:36:12.687
Формат fload с плавающей.

00:36:13.425 --> 00:36:18.946
Связаны эти элементы непосредственно в
зависимости со стереотипом cent.

00:36:19.426 --> 00:36:21.026
Вот по направлению к

00:36:21.106 --> 00:36:29.266
сигналу,

00:36:29.306 --> 00:36:33.066
ну вот это вот самый подробный и явный
способ моделирования сигналов.

00:36:36.325 --> 00:36:40.205
Если событие сигнала представляет
возбуждение сигнала, то событие вызова

00:36:40.285 --> 00:36:42.606
предназначено для описания выполнения
операции.

00:36:42.846 --> 00:36:46.846
И в том, и в другом случае событие может
вызвать переход состояние в автомате.

00:36:47.246 --> 00:36:51.967
В то время как сигнал является событием
энхронным, ну то есть, собственно, событие

00:36:52.087 --> 00:36:52.487
произошло

00:36:53.864 --> 00:36:59.030
Вот. Реакция на него либо последует, либо
последует, зависит уже, собственно, от

00:36:59.951 --> 00:37:02.834
всех участников этого процесса
взаимодействия.

00:37:03.515 --> 00:37:05.877
То событие вызова обычно синхронно.

00:37:05.997 --> 00:37:09.962
То есть, это означает, что когда один
объект инициирует выполнение операции на

00:37:10.082 --> 00:37:10.763
другом объекте

00:37:11.418 --> 00:37:12.819
...у которого есть свой автомат.

00:37:12.899 --> 00:37:15.939
Управление передаётся от отправителя к
получателю.

00:37:16.459 --> 00:37:20.859
Срабатывает соответствующий переход, затем
операция завершается, получатель переходит

00:37:21.019 --> 00:37:23.860
в новое состояние и возвращает управление
отправителю.

00:37:25.887 --> 00:37:30.083
То есть целая цепочка получается действий.

00:37:30.243 --> 00:37:34.799
Самое главное, что инициатор
взаимодействия как бы ждёт отклика.

00:37:34.919 --> 00:37:39.914
И всё это время, в принципе, только этим и
занимается, в отличие от асинхронного

00:37:40.034 --> 00:37:44.430
взаимодействия. Так, примеры, собственно,
моделирования.

00:37:44.645 --> 00:37:50.454
В контексте автомата, вот фрагмент
автомата показан ручной режим

00:37:51.175 --> 00:37:55.421
событие является, собственно, стимулом к
этому переходу.

00:37:55.621 --> 00:37:57.143
Кроме того, показан параметр.

00:38:03.292 --> 00:38:07.456
Хотя визуально событие сигнала вызова
неотличимы, разница совершенно отчётливо

00:38:07.536 --> 00:38:09.097
проявляется на заднем плане модели.

00:38:09.177 --> 00:38:13.301
Получатель события, конечно же, знает о
различии путём объявления операции в своём

00:38:13.421 --> 00:38:17.224
списке операций. Сигнал, как правило,
обрабатывается на уровне автомата, а

00:38:17.304 --> 00:38:18.625
событие вызова методом.

00:38:19.414 --> 00:38:22.493
Для перехода от события к сигналу или
операции можно воспользоваться

00:38:22.573 --> 00:38:24.132
инструментальной программой.

00:38:28.610 --> 00:38:30.569
Событие времени и изменение.

00:38:30.769 --> 00:38:33.328
Ещё одни из вариантов событий.

00:38:33.408 --> 00:38:37.047
Событие времени представляет собой
истечение промежутка времени.

00:38:37.588 --> 00:38:41.384
Событие времени моделируется с помощью
ключевого слова «авто», то есть «после».

00:38:41.663 --> 00:38:46.577
За которым следует выражение, носящее
некоторый промежуток, вычисляющее

00:38:46.617 --> 00:38:48.016
некоторый промежуток времени.

00:38:48.135 --> 00:38:49.693
Выражение может быть простым.

00:38:49.893 --> 00:38:52.730
Например, авто 2 Seconds, то есть после
двух секунд.

00:38:53.204 --> 00:38:59.364
либо с ложным авто1 мсеку с момента выхода
из состояния ожидания Если явно не указано

00:38:59.484 --> 00:39:03.444
противное, то отсчёт времени начинается с
момента входа в текущее состояние.

00:39:03.764 --> 00:39:06.044
Можно, кстати, использовать и абсолютное
время.

00:39:07.333 --> 00:39:11.254
С помощью события изменяется описание
изменения состояния или выполнение

00:39:11.374 --> 00:39:15.056
некоторого условия. В Umail событии
изменения моделируются посредством

00:39:15.096 --> 00:39:16.496
ключевого слова «дэн».

00:39:17.136 --> 00:39:20.057
То есть когда, за которым следует более
выражение.

00:39:20.177 --> 00:39:23.779
Такое выражение может использоваться для
обозначения абсолютного момента времени.

00:39:23.859 --> 00:39:27.020
То есть, например, w tim равняется 11:59.

00:39:28.039 --> 00:39:33.684
Так, ну, в принципе, кроме как времени
может использоваться и другое условие.

00:39:36.006 --> 00:39:38.729
То есть, например, температура достигла
нужного значения.

00:39:38.809 --> 00:39:44.174
В принципе, любая физическая величина
какой-то параметр проверки: две на тют

00:39:44.294 --> 00:39:44.975
меньше тысячи.

00:39:45.690 --> 00:39:48.489
То есть там какой-то параметр цикла меньше
тысячи.

00:39:51.328 --> 00:39:54.487
Событие времени изменения показано
моделирование.

00:39:54.567 --> 00:40:00.804
То есть как раз фрагмент автомата
приводится два состояния активно ожидания.

00:40:01.084 --> 00:40:04.443
Состояние ожидания периодически, видите, в
11:49

00:40:06.625 --> 00:40:11.625
Производится самотестирование, то есть сам
селф-тест выполняется

00:40:11.985 --> 00:40:13.706
событие-изменения.

00:40:13.986 --> 00:40:18.866
Событие времени. То есть из состояния
активен, соответственно, через 2 секунды

00:40:19.266 --> 00:40:24.867
имеется в виду, если никаких других
факторов нет.

00:40:25.757 --> 00:40:27.839
Система переходит в состояние ожидания.

00:40:28.119 --> 00:40:31.802
Соответственно, наблюдается дроп-конешн,
то есть разрыв связи.

00:40:32.283 --> 00:40:35.886
Выполняется соответствующее действие,
оформленное как операция.

00:40:36.486 --> 00:40:41.050
Так, ещё раз: событие времени с помощью
служебного слова авто.

00:40:42.385 --> 00:40:45.381
Событие изменения с помощью служебного
слова.

00:40:45.500 --> 00:40:47.458
Причём необязательно время.

00:40:47.577 --> 00:40:49.614
Может использоваться событии изменения.

00:40:49.774 --> 00:40:52.570
Любая физическая величина либо доступный
параметр.

00:40:55.643 --> 00:40:59.160
Примечание. Хотя событие изменений
моделируют условия, проверяемые

00:40:59.200 --> 00:41:02.677
непрерывно, обычно, проанализировав
ситуацию, можно выявлять дискретные

00:41:02.837 --> 00:41:05.994
моменты времени, когда это условие можно
проверять.

00:41:06.274 --> 00:41:09.192
В начале какого-то большого цикла, как
правило, это делается.

00:41:10.267 --> 00:41:13.709
В событиях сигнала и вызова участвуют по
крайней мере два объекта.

00:41:13.789 --> 00:41:17.911
То есть объект, посылающий сигнал или
инициирующий операцию, и объект, которому

00:41:18.071 --> 00:41:19.352
событие адресовано.

00:41:19.832 --> 00:41:24.235
Поскольку сигналы по своей природе
ассинхронные, а синхронные вызовы сами по

00:41:24.275 --> 00:41:27.676
себе являются сигналами, то семантика
событий перекликается с семантикой

00:41:27.836 --> 00:41:29.397
активных и пассивных объектов.

00:41:32.485 --> 00:41:36.804
Экземпляр любого класса может посылать
сигнал по именуемому объекту или

00:41:36.884 --> 00:41:38.564
инициировать в нём операцию.

00:41:39.164 --> 00:41:43.283
Отправив сигнал получателю, он продолжает
свой поток управления, не дожидаясь от

00:41:43.363 --> 00:41:44.083
него ответа.

00:41:44.530 --> 00:41:46.928
Собственно, это асинхронный способ
взаимодействия.

00:41:47.208 --> 00:41:51.125
В некоторых случаях возникает
необходимость в изображении объекта,

00:41:51.205 --> 00:41:53.803
который посылает сигнал сразу нескольким
объектам.

00:41:53.962 --> 00:41:59.878
Так называемое мультивещание, Multicasting
или всем ожидающим объектам в системе.

00:42:00.318 --> 00:42:02.719
То есть широковещание в Broadcasting.

00:42:02.799 --> 00:42:06.999
Для моделирования и мультивещания следует
изобразить объект, посылающий сигнал

00:42:07.119 --> 00:42:11.480
коллекции, то есть пакет со стереотипом
Collection, в который входят все

00:42:11.680 --> 00:42:15.441
получатели. Для моделирования
широковещания нужно показать, что объект

00:42:15.721 --> 00:42:19.241
посылает сигнал другому объекту,
представляющему всю систему целом.

00:42:19.361 --> 00:42:21.322
Опять же, пакет со стереотипом System.

00:42:23.772 --> 00:42:26.850
Приводить примеры не будем, наверное,
понятно, о чём идёт речь.

00:42:28.090 --> 00:42:29.609
Посылка и получение событий.

00:42:29.729 --> 00:42:33.767
Любой экземпляр любого класса может быть
получателем события вызова или сигнала.

00:42:33.927 --> 00:42:36.925
Если это синхронное событие, то
отправитель и получатель находится в

00:42:36.965 --> 00:42:38.045
состоянии НДУ.

00:42:38.580 --> 00:42:40.503
На всём протяжении выполнения операции.

00:42:40.663 --> 00:42:45.068
Если это сигнал, то есть асинхронно, то
отправитель и получатель не входят в

00:42:45.108 --> 00:42:49.273
состояние НДВ. То есть отправитель
посылает сигнал, но не дожидается ответа

00:42:49.353 --> 00:42:53.918
от получателя. В любом случае, событие
может быть потеряно.

00:42:56.248 --> 00:42:58.008
...если не указано, что нужен ответ.

00:42:58.288 --> 00:43:01.688
Может вызвать переход состояния в
автомате, если он существует, или

00:43:01.848 --> 00:43:04.248
постоянно инициировать обычный вызов
метода.

00:43:04.488 --> 00:43:08.408
В моде события вызова, который получает
объект, моделируется как операция над

00:43:08.488 --> 00:43:09.688
классом этого объекта.

00:43:09.968 --> 00:43:13.888
Именованные сигналы, полученные объектом,
моделируются путём перечисления в

00:43:13.928 --> 00:43:15.288
дополнительном разделе класса.

00:43:19.479 --> 00:43:21.598
Моделирование сигналов в разделе «класса».

00:43:21.838 --> 00:43:24.437
Вот в данном случае, как видите,
специальный раздел.

00:43:24.676 --> 00:43:28.994
Напоминаю, что первый раздел — имя, второй
раздел — атрибуты не показаны здесь.

00:43:29.394 --> 00:43:32.153
Следующий раздел «Операции» тоже здесь не
показаны.

00:43:32.393 --> 00:43:33.832
И вот, собственно, сигналы.

00:43:33.992 --> 00:43:36.231
В данном случае четвёртый раздел содержит
сигналы.

00:43:36.351 --> 00:43:39.109
Собственно, четвёртый раздел всегда
подписывается, что имеется в виду.

00:43:39.723 --> 00:43:41.401
Ну и, собственно, вот четыре сигнала.

00:43:41.521 --> 00:43:43.678
Видите, сигнал Push Bot'on с параметром.

00:43:43.758 --> 00:43:46.035
То есть какая кнопка нажата нажата?

00:43:46.155 --> 00:43:51.867
Наверное, какой-то скат-кон, скан-код этой
клавиши передаётся как параметр.

00:43:52.666 --> 00:43:55.383
Ну, плюс регистры Power app, powerdown.

00:43:58.916 --> 00:44:01.833
Моделирование семейств сигналов включает
следующие этапы.

00:44:02.233 --> 00:44:06.469
Первое — рассмотрите все разновидности
сигналов, на которые может отвечать данное

00:44:06.589 --> 00:44:08.268
множество активных объектов.

00:44:08.587 --> 00:44:13.103
Выявите схожие виды сигналов, поместите их
в иерархию типа обобщения специализации,

00:44:13.143 --> 00:44:14.462
используя наследование.

00:44:15.207 --> 00:44:18.764
На верхних уровнях иерархии будут
располагаться общие сигналы, на нижних

00:44:18.884 --> 00:44:23.999
специализированные. Определите возможности
полиморфизма в автоматах этих активных

00:44:24.119 --> 00:44:27.996
объектов. Обнаружив полиморфизм,
скорректируйте иерархию, добавив при

00:44:28.076 --> 00:44:30.274
необходимости промежуточные абстрактные
сигналы.

00:44:36.075 --> 00:44:38.516
Так, ну вот пример моделирования семейства
сигналов.

00:44:38.636 --> 00:44:42.399
То есть есть какой-то сигнал верхнего
уровня, как абстрактный класс, сигнал

00:44:42.479 --> 00:44:48.283
роботу. Он подразделяется на сигналы, как
видите, столкновения и

00:44:49.123 --> 00:44:52.886
аппаратный отказ. Аппаратный отказ — тоже
целая группа сигналов.

00:44:52.966 --> 00:44:55.568
Ну, допустим, сигнал-отказ двигательного
механизма

00:44:56.979 --> 00:45:01.940
соответствует ему дочерний класс останов
электромотора.

00:45:02.020 --> 00:45:08.703
Ну, как правило, желательно, даже может
быть, несколько искусственно получить

00:45:08.863 --> 00:45:12.865
общую иерархию, то есть единую, не две
отдельные иерархии, скажем

00:45:13.638 --> 00:45:17.719
Аппаратная и программная, а всё-таки
объединить их и использовать какие-то

00:45:17.799 --> 00:45:20.159
идентификаторы, коды и тому подобное.

00:45:20.400 --> 00:45:25.200
То есть привести как бы все сигналы к
какой-то единой системе.

00:45:25.320 --> 00:45:29.961
Как правило, это удобно потом будет для их
распознавания и реагирования на них.

00:45:32.528 --> 00:45:34.367
Исключение. Другой случай.

00:45:34.487 --> 00:45:38.165
Важной частью визуализации,
специфицирования и документирования

00:45:38.645 --> 00:45:43.283
поведения класса или интерфейса является
спецификация исключений, которые могут

00:45:43.363 --> 00:45:44.802
возбуждать его операции.

00:45:45.322 --> 00:45:49.280
Если вам предоставили класс или интерфейс,
то операции, которые можно

00:45:50.061 --> 00:45:52.259
...на нём вызвать ясны записания.

00:45:52.299 --> 00:45:56.854
Но понять, какие исключения они могут
возбуждать, нелегко, если это явно не

00:45:56.934 --> 00:46:02.088
указано в модели. В ОМЭЛ исключения или
исключительные ситуации являются частным

00:46:02.168 --> 00:46:05.405
случаем сигналов и моделируется с помощью
стереотипных классов.

00:46:06.193 --> 00:46:09.152
Исключение можно присоединять к
спецификациям операций.

00:46:09.791 --> 00:46:12.430
Моделирование исключений является
операцией в некотором смысле

00:46:12.550 --> 00:46:14.948
противоположной моделированию семейства
сигналов.

00:46:15.308 --> 00:46:18.826
Основная цель моделирования семейства
сигналов — это специфицировать, какие

00:46:18.986 --> 00:46:21.025
сигналы могут получать активные объекты.

00:46:22.286 --> 00:46:25.928
Цель же моделирования исключений состоит в
том, чтобы показать, какие исключения

00:46:26.048 --> 00:46:29.291
могут возбуждаться объектом через свои
операции.

00:46:33.693 --> 00:46:36.375
Моделирование исключений производится
следующим образом.

00:46:36.815 --> 00:46:40.658
Для каждого класса и интерфейса и для
каждой определённой у них операции

00:46:40.858 --> 00:46:43.300
рассмотрите, какие исключения могут
возбуждаться.

00:46:44.280 --> 00:46:46.082
Организуйте исключения в иерархию.

00:46:46.202 --> 00:46:50.127
На верхних уровнях разместите общие
исключения, на нижних специализированные.

00:46:50.247 --> 00:46:53.090
А при необходимости введите промежуточные
исключения.

00:46:53.650 --> 00:46:57.494
Укажите для каждой операции, какие
исключения она может возбуждать.

00:46:57.694 --> 00:47:01.659
Это можно сделать явно на диаграмме,
проведя зависимости типа cent от операции

00:47:01.819 --> 00:47:02.740
к её исключениям.

00:47:03.227 --> 00:47:06.550
Либо поместить перечень исключений в
спецификацию операций.

00:47:06.871 --> 00:47:09.193
То есть, получается, на задний план
модели.

00:47:12.277 --> 00:47:17.403
На данном слайде показан вариант
моделирования исключений.

00:47:17.483 --> 00:47:17.883
То есть есть

00:47:19.201 --> 00:47:23.246
Стереотипный класс исключения с именем
Exception.

00:47:24.567 --> 00:47:31.375
Соответственно, имеющие стандартную
структуру, какое-то абстрактное

00:47:31.776 --> 00:47:35.180
исключение: set hunder, Ferstunder, last
Hunder.

00:47:35.844 --> 00:47:39.966
Хандер — это, как правило, какое-то поле
управления, которое содержит набор

00:47:40.046 --> 00:47:45.168
параметров: время возникновения события,
пользователь, ну и тому подобное, как

00:47:45.288 --> 00:47:47.048
правило, системную информацию.

00:47:48.329 --> 00:47:51.810
Соответственно, три конкретных исключения:
дубликайт, werflow и

00:47:52.865 --> 00:47:58.508
Underflow. То есть, в данном случае мы
видим шаблон класса set, то есть

00:47:58.588 --> 00:48:04.152
множества. Соответственно, знаем, что по
принципу множества не могут сходить

00:48:04.312 --> 00:48:09.275
одинаковые элементы. Если такое
появляется, то, соответственно, возникает

00:48:09.435 --> 00:48:10.836
исключение дубликат.

00:48:10.916 --> 00:48:13.317
То есть элементы должны быть только в
одном экземпляре.

00:48:16.485 --> 00:48:22.372
Кроме того, множество может быть либо
переполнено, соответственно, пытаются

00:48:22.773 --> 00:48:26.617
дополнить, когда уже, собственно, весь
размер исчерпан.

00:48:26.697 --> 00:48:31.182
Либо андерфлоу, когда пытаются что-то
удалить, когда у нас ещё уже в этом

00:48:31.222 --> 00:48:32.183
множестве ничего нет.

00:48:33.034 --> 00:48:38.559
Так, ну и две операции этого шаблона
класса как множество, то есть AD и ремоф.

00:48:38.839 --> 00:48:45.565
То есть, соответственно, можно удалить
элемент, можно добавить элемент Ad.

00:48:45.805 --> 00:48:49.769
Соответственно, как видите, тут указано,
что именно какая-то операция конкретно

00:48:49.889 --> 00:48:51.451
вызывает тот или иной

00:48:53.718 --> 00:48:57.561
Исключения. К сожалению, конкретные
инструментальные средства не всегда это

00:48:57.721 --> 00:49:03.485
позволяют. Чаще всего удаётся только
указать, что такой-то класс может вызывать

00:49:03.765 --> 00:49:05.006
те или иные исключения.

00:49:05.166 --> 00:49:09.329
Значит, обращаем внимание, что стрелка
Sent в зависимости направлена по отношению

00:49:09.449 --> 00:49:10.169
к исключению.

00:49:11.424 --> 00:49:13.104
От класса, где он может произойти

00:49:19.065 --> 00:49:23.346
при моделировании событий исходите из
следующих соображений.

00:49:23.466 --> 00:49:27.506
Стройте иерархию сигналов так, чтобы можно
было воспользоваться общими для них

00:49:27.546 --> 00:49:28.547
свойствами. То есть

00:49:29.166 --> 00:49:35.321
По возможности использовать иерархию и по
возможности как более связанную, насколько

00:49:35.400 --> 00:49:38.877
это возможно. В идеале вообще единую
иерархию всех событий.

00:49:39.317 --> 00:49:43.473
Не прибегайте к посылке сигналов и тем
более к возбуждению исключений, если

00:49:43.713 --> 00:49:46.191
позволяет обойтись обычным потоком
управления.

00:49:47.172 --> 00:49:51.255
Не забывайте ассоциировать подходящий
автомат с каждым элементом, который может

00:49:51.455 --> 00:49:56.940
получать событие. Обязательно моделируйте
не только те элементы, которые могут

00:49:57.020 --> 00:50:00.063
получать события, но и те, которые могут
их посылать.

00:50:00.463 --> 00:50:04.467
Изображая событие в Amail в общем случае
моделируйте иерархию событий явно.

00:50:05.171 --> 00:50:08.928
А их использование специфицируйте на
заднем плане тех классов или операций,

00:50:08.968 --> 00:50:11.366
которые посылают или получают события.

00:50:19.359 --> 00:50:23.035
Рассмотрим следующий важный вопрос — это
моделирование информационных систем в

00:50:23.075 --> 00:50:24.514
условиях многозадачности.

00:50:26.035 --> 00:50:27.354
Процессы и нити.

00:50:29.513 --> 00:50:31.433
Базовое определение. Активный объект.

00:50:31.513 --> 00:50:35.631
Эктив-объект — это объект, который владеет
процессом или нитью и может инициировать

00:50:35.871 --> 00:50:37.151
управляющее воздействие.

00:50:37.431 --> 00:50:42.709
Активный класс. Эктив-класс — это класс,
экземплярами которого являются активные

00:50:42.829 --> 00:50:43.228
объекты.

00:50:44.243 --> 00:50:49.120
Процесс, процесс — это ресурсоёмкий поток
управления, который может выполняться

00:50:49.200 --> 00:50:50.759
параллельно с другими процессами.

00:50:50.999 --> 00:50:55.116
Нить фрит — это облегчённый поток
управления, который может выполняться

00:50:55.156 --> 00:50:57.874
параллельно с другими нитями в рамках
одного процесса.

00:50:58.314 --> 00:51:02.152
Графически активный класс изображается в
виде прямоугольника с жирными границами.

00:51:02.782 --> 00:51:07.106
Процессы и нити изображаются в виде
стереотипных активных классов, а на

00:51:07.186 --> 00:51:10.469
диаграммах взаимодействия часто выступают
в роли последовательности.

00:51:14.342 --> 00:51:18.303
Активные классы — это именно классы, хотя
и обладающие весьма специфическими

00:51:18.343 --> 00:51:22.625
свойствами. Активный класс представляет
независимый поток управления, тогда как

00:51:22.825 --> 00:51:24.426
обычный класс не связан с таковым.

00:51:24.546 --> 00:51:29.068
В отличие от активных, обычные классы не
явно называют пассивными, так как они

00:51:29.744 --> 00:51:33.022
не способны инициировать независимое
управляющее воздействие.

00:51:33.302 --> 00:51:36.340
Активные классы применяются для
моделирования семейств процессов или

00:51:36.500 --> 00:51:41.136
нитей. Технически это означает, что
активный объект — это экземпляр активного

00:51:41.256 --> 00:51:43.295
класса, материализует процесс или нить.

00:51:43.335 --> 00:51:46.333
При моделировании параллельных систем с
помощью активных объектов

00:51:47.001 --> 00:51:50.285
Вы присваиваете имя каждому независимому
потоку управления.

00:51:50.405 --> 00:51:54.290
Когда активный объект создаётся,
запускается ассоциированный с ним поток

00:51:54.370 --> 00:51:58.575
управления. Когда активный объект
уничтожается, этот поток завершается.

00:51:59.364 --> 00:52:02.921
Активные классы обладают теми же
свойствами, что любые другие классы.

00:52:03.001 --> 00:52:06.797
Они могут иметь экземпляры, атрибуты и
операции, также принимать участие в

00:52:06.837 --> 00:52:09.355
отношениях зависимостей, обобщений и
ассоциаций.

00:52:09.834 --> 00:52:13.671
Активные классы вправе пользоваться
предоставленными умейл механизмами

00:52:13.751 --> 00:52:17.627
расширения, в том числе и стереотипами,
помеченными значениями и ограничениями.

00:52:18.321 --> 00:52:22.325
Встречаются активные классы, реализующие
реализацию интерфейсов.

00:52:22.365 --> 00:52:25.528
И наконец, они могут реализовываться
кооперациями, а их поведение

00:52:25.689 --> 00:52:27.370
специфицируется с помощью автоматов.

00:52:35.072 --> 00:52:37.029
Так, активный класс. Пример моделирования.

00:52:37.109 --> 00:52:43.223
Значит, некоторый активный класс Blackbold
Controller, то есть контроллер

00:52:43.742 --> 00:52:49.696
доски, на которой пишут, предполагается
атрибут какой-нибудь Noch souls.

00:52:50.215 --> 00:52:53.172
Операции упущены, либо их нет, сигналы.

00:52:53.725 --> 00:52:59.048
Соответственно, два сигнала показано Hisa
Hit, то есть иметь вот этот

00:52:59.288 --> 00:53:01.929
фокус-подсказочки.

00:53:02.210 --> 00:53:03.890
Обычно такой экранчик возникает.

00:53:03.930 --> 00:53:05.651
И Blackbolt sow.

00:53:05.892 --> 00:53:08.533
То есть какое-то решение передано на
доску.

00:53:08.893 --> 00:53:10.294
Имеется в виду, скорее всего.

00:53:11.241 --> 00:53:15.562
Так, напоминаю, что границы класса должны
быть более жирные по отношению к другим

00:53:15.642 --> 00:53:20.164
классам. И вот, собственно, визуально
именно так отличается активный класс от

00:53:20.244 --> 00:53:24.885
обычных. Ну, скажем, если у нас будут
указаны либо, если все активные классы,

00:53:24.965 --> 00:53:26.646
это не всегда может и броситься в глаза.

00:53:27.913 --> 00:53:31.310
Вот, если показывать рядом активный и
пассивный, то понятно, что у активного

00:53:31.510 --> 00:53:34.187
должна быть более жирная ярко выраженная
граница класса.

00:53:34.307 --> 00:53:36.305
То есть вот этот габаритный прямоугольник.

00:53:41.154 --> 00:53:45.117
Все механизмы расширения ОМЭЛ применимы в
том числе и к активным классам.

00:53:45.237 --> 00:53:48.560
Чаще всего используются помеченные
значения для расширения их свойств.

00:53:48.680 --> 00:53:51.923
Например, для специфицирования политики
планирования активного класса.

00:53:52.403 --> 00:53:57.127
В ОМЭЛ определены два стандартных
стереотипа, применимых к активным классам:

00:53:57.247 --> 00:54:01.490
процесс — ресурсоёмкий поток управления,
который может выполняться параллельно с

00:54:01.530 --> 00:54:02.851
другими процессами. Нить

00:54:03.777 --> 00:54:07.500
...или подпроцесс. Облегчённый поток
управления, который может выполняться

00:54:07.580 --> 00:54:10.623
параллельно с другими нитями в рамках
одного и того же процесса.

00:54:11.223 --> 00:54:15.507
Ну, кроме того, следует обратить внимание,
что процесс фиксируется непосредственно

00:54:15.867 --> 00:54:17.148
операционной системой.

00:54:17.668 --> 00:54:19.790
Скажем, если вы зайдёте в диспетчер
программ

00:54:21.148 --> 00:54:23.949
Выведите на экран список процессов
активных.

00:54:24.149 --> 00:54:27.110
Там, собственно, будут указаны именно
процессы.

00:54:27.190 --> 00:54:33.432
Например, Winvort X, если используется
эксплоер, если он запущен и тому подобное.

00:54:34.152 --> 00:54:38.554
Вот. А под процессы или нити, они
выступают в рамках процесса,

00:54:38.714 --> 00:54:39.354
соответственно.

00:54:40.054 --> 00:54:41.616
Самим процессом не фиксируется.

00:54:41.736 --> 00:54:47.141
Ну, например, при видеозаписи идёт
одновременно и записи видеоизображения —

00:54:47.221 --> 00:54:51.625
один поток и записи аудиоизображения,
другой поток, соответственно, другие

00:54:51.666 --> 00:54:55.669
кодики. Возможно ещё другие дополнительные
какие-то кодеки могут работать.

00:54:56.070 --> 00:54:57.191
Субтитры, например.

00:54:58.787 --> 00:55:02.911
Либо, соответственно, какие-то фоны и тому
подобное.

00:55:06.074 --> 00:55:09.958
Коммуникация. Кооперирующиеся друг с
другом объекты взаимодействуют путём

00:55:10.038 --> 00:55:14.242
обмена сообщениями. В системе, где есть
одновременно активные и пассивные объекты,

00:55:14.282 --> 00:55:16.844
следует рассматривать четыре возможные
комбинации.

00:55:17.304 --> 00:55:22.787
Во-первых, сообщение может быть передано
одним пассивным объектом другому такому же

00:55:23.147 --> 00:55:26.990
в предложении, что в момент времени
существует лишь один поток управления,

00:55:27.030 --> 00:55:30.472
проходящий через оба объекта, такое
взаимодействие — не что иное, как простой

00:55:30.552 --> 00:55:35.195
вызов операции. Ну, собственно, вызов
операции — это и есть синхронный способ

00:55:35.275 --> 00:55:36.116
взаимодействия.

00:55:37.750 --> 00:55:41.229
Синхронная коммуникация. Во-вторых,
сообщение может быть передано от одного

00:55:41.309 --> 00:55:43.268
активного объекта к другому активному.

00:55:43.588 --> 00:55:47.387
Здесь мы имеем случай межпроцессной
коммуникации, которая может осуществляться

00:55:47.467 --> 00:55:52.545
двумя способами. Во-первых, некоторый
активный объект может синхронно вызвать

00:55:52.705 --> 00:55:56.384
операцию другого. Такой способ имеет
семантику рандево.

00:55:57.173 --> 00:56:00.013
Вот написано так, но читается как рандево.

00:56:00.373 --> 00:56:05.214
Вызывающий объект затребует выполнения
операции и ждёт, пока принимающая сторона

00:56:05.334 --> 00:56:11.134
получит вызов, выполнит операцию и вернёт
некоторые объекты, если есть что

00:56:11.254 --> 00:56:11.734
возвращать.

00:56:12.293 --> 00:56:15.490
Затем оба объекта продолжают работать
независимо друг от друга.

00:56:15.610 --> 00:56:20.247
В течение всего времени выполнения вызова
оба потока управления будут блокированы.

00:56:20.766 --> 00:56:22.964
То есть как бы такой тет-а-тет происходит.

00:56:23.084 --> 00:56:27.361
Один процесс ждёт отклика, и пока,
соответственно, этого отклика не получит,

00:56:27.681 --> 00:56:29.200
ничем другим не занимается.

00:56:29.320 --> 00:56:31.478
Вот это, собственно, синхронная
коммуникация.

00:56:32.228 --> 00:56:35.544
Или коммуникации по принципу рандево.

00:56:36.103 --> 00:56:37.182
Какие используются слова?

00:56:38.669 --> 00:56:43.673
Во втором варианте один активный объект
может асинхронно послать сигнал другому

00:56:43.953 --> 00:56:45.394
или вызвать его операцию.

00:56:45.555 --> 00:56:48.878
Семантика такого напоминает почтовый ящик
в Mailbox.

00:56:48.958 --> 00:56:53.802
То есть вызывающая сторона посылает сигнал
и вызывает операцию, после чего продолжает

00:56:53.882 --> 00:56:56.284
выполняться, ну то есть заниматься своей
работой.

00:56:56.938 --> 00:57:00.980
Тем временем получающая сторона принимает
сигнал или вызов, и как только будет к

00:57:01.060 --> 00:57:06.263
этому готова, вот, соответственно, она на
это дело отреагирует.

00:57:07.104 --> 00:57:11.547
Пока она обрабатывает запрос, все вновь
поступающие события или вызовы становятся

00:57:11.587 --> 00:57:15.589
в очередь. Отреагировав на один запрос,
принимающий объект продолжает свою работу.

00:57:16.158 --> 00:57:21.754
Семантика почтового ящика представляет в
том, что оба объекта не синхронизированы.

00:57:21.914 --> 00:57:24.033
Просто один оставляет сообщение другого.

00:57:24.432 --> 00:57:29.429
Ну, и предполагается, что по мере
возможности отрабатывает эти сообщения.

00:57:30.068 --> 00:57:33.346
В email синхронное сообщение изображается
полной стрелкой.

00:57:33.620 --> 00:57:35.698
Асинхронная полустрелка.

00:57:41.332 --> 00:57:45.488
В-третьих, сообщение может быть передано
от активного объекта пассивному.

00:57:45.608 --> 00:57:49.444
Трудности возникают в случае, когда сразу
несколько активных объектов передают свой

00:57:49.524 --> 00:57:51.522
поток управления одному и тому же
пассивному.

00:57:52.288 --> 00:57:56.090
В такой ситуации следует очень аккуратно
моделировать синхронизацию потоков.

00:57:56.250 --> 00:57:57.851
О чём мы поговорим чуть позже.

00:57:58.211 --> 00:58:01.814
В четвёртых, пассивный объект может
передавать сообщение активному.

00:58:01.934 --> 00:58:04.775
На первый взгляд может показаться
некорректным, но если вспомнить, что

00:58:04.895 --> 00:58:07.737
каждый поток управления принадлежит
некоторому активному объекту

00:58:08.471 --> 00:58:12.554
То становится ясно, что передача пассивным
объектом сообщения активному имеет ту же

00:58:12.674 --> 00:58:16.316
семантику, что обмен между двумя активными
объектами.

00:58:16.437 --> 00:58:19.799
То есть второй способ, который мы
рассматривали.

00:58:20.479 --> 00:58:23.562
Так, ну вот на данном слайде приводится
пример коммуникации.

00:58:24.222 --> 00:58:31.141
Указаны объекты, то есть подчёркивается
имя связи между объектами и сообщения

00:58:31.541 --> 00:58:35.701
между объектами. Объекты обмениваются
сообщениями, которые показаны стрелочками.

00:58:36.642 --> 00:58:41.601
Стрелочкой, соответственно, с двух сторон
закрыто, это синхронное сообщение.

00:58:42.481 --> 00:58:47.720
Вот, в данном случае inialation,
инициализация является синхронным

00:58:47.880 --> 00:58:49.960
сообщением. Вот.

00:58:50.240 --> 00:58:54.079
Полустрелочкой — это ассинхронное
сообщение, то есть по принципу почтового

00:58:54.199 --> 00:58:54.679
ящика.

00:58:55.620 --> 00:59:01.056
То есть, в данном случае старт Seach
Evulate и тому подобное.

00:59:01.176 --> 00:59:05.772
То есть, собственно, остальные у нас
сообщения асинхронны.

00:59:12.225 --> 00:59:15.787
С помощью ограничений можно моделировать
различные варианты посылки синхронных и

00:59:15.867 --> 00:59:20.751
синхронных сообщений. Например, для
моделирования отложенного нвуш Rendew

00:59:22.152 --> 00:59:25.594
имеющегося в языке ада, можно
воспользоваться синхронным сообщением с

00:59:25.634 --> 00:59:29.357
ограничением wight равно нулю, то есть не
ждать, которое говорит о том, что

00:59:29.437 --> 00:59:32.158
вызывающий объект не будет дожидаться
получателя.

00:59:32.707 --> 00:59:38.391
Может смоделировать и тайм-аут с помощью
ограничений вида vite равно 1 MS.

00:59:38.391 --> 00:59:43.114
Ну, то есть 1 мсекунда, можно указать 50
наносекунд, который говорит, что

00:59:43.194 --> 00:59:47.477
вызывающий объект будет ждать приёма
сообщений получателем не более указанного

00:59:47.678 --> 00:59:48.078
времени.

00:59:51.465 --> 00:59:55.820
Синхронизация. Проблема возникает тогда,
когда в одном объекте находится сразу

00:59:56.099 --> 00:59:57.537
несколько потоков управления.

00:59:57.817 --> 01:00:02.251
Если не проявить осторожность, то потоки
могут мешать друг другу, что приведёт к

01:00:02.331 --> 01:00:04.328
некорректному изменению состояния объекта.

01:00:05.151 --> 01:00:07.549
Это классическая проблема взаимного
исключения.

01:00:07.669 --> 01:00:12.306
Ошибки при обработке этой ситуации могут
стать причиной различных видов конкуренции

01:00:12.466 --> 01:00:18.821
между потоками. То есть рейс-кондишн и их
взаимные интерференции, что проявляется в

01:00:18.901 --> 01:00:22.339
таинственных и неподдающихся
воспроизведению сбоях.

01:00:22.787 --> 01:00:26.863
параллельной системы. Ключом к решению
этой проблемы в объектно-ориентированных

01:00:26.943 --> 01:00:29.941
системах является трактовка объекта как
критической области.

01:00:30.061 --> 01:00:32.219
У этого подхода есть три разновидности.

01:00:32.498 --> 01:00:36.175
Суть каждой из которых заключается в
присоединении к операциям определённым в

01:00:36.215 --> 01:00:38.174
классе некоторых синхронизирующих свойств.

01:00:39.261 --> 01:00:42.942
Позволяет моделировать, соответственно,
все эти три возможности.

01:00:43.502 --> 01:00:47.624
Вот, они у нас встречались как
дополнительные свойства, собственно, это и

01:00:47.664 --> 01:00:49.024
есть свойство синхронизации.

01:00:50.066 --> 01:00:52.067
Секвента, то есть последовательно.

01:00:52.187 --> 01:00:56.350
Вызывающие стороны должны координировать
свои действия ещё до входа в вызываемый

01:00:56.430 --> 01:01:00.673
объект, так что в любой момент времени
внутри объекта находится ровно один поток

01:01:00.753 --> 01:01:04.996
управления. При наличии нескольких потоков
управления не могут гарантироваться

01:01:05.116 --> 01:01:06.677
семантика и целостность объекта.

01:01:06.877 --> 01:01:08.318
Гвардед — охраняемое.

01:01:09.000 --> 01:01:12.317
Семантика и целостность объекта
гарантируется при наличии нескольких

01:01:12.397 --> 01:01:17.233
потоков управления путём упорядочивания
вызовов всех охраняемых операций объекта.

01:01:17.633 --> 01:01:21.310
По существу, в каждый момент времени может
выполняться ровно одна операция над

01:01:21.389 --> 01:01:24.147
объектом, что сводит такой подход к
последовательному.

01:01:25.459 --> 01:01:27.659
Конкурент — параллельная семантика.

01:01:27.819 --> 01:01:30.739
И целостность объекта при наличии
нескольких потоков управления

01:01:30.819 --> 01:01:34.059
гарантируется тем, что операция
рассматривается как атомарная.

01:01:36.059 --> 01:01:42.940
То есть, таким образом, при
последовательности предполагается, что

01:01:43.180 --> 01:01:47.020
каким-то объектом может завладеть только
один активный

01:01:48.044 --> 01:01:50.843
Класс, то есть какой-то со стороны одного
процесса.

01:01:51.003 --> 01:01:53.362
И больше не предполагается.

01:01:53.522 --> 01:01:58.320
Гвардет предполагает, что одним объектом
может овладеть несколько процессов, но

01:01:58.440 --> 01:02:01.878
каждый будет работать, выполнять только
свою отдельную операцию.

01:02:03.678 --> 01:02:07.236
Вот. Конкурент предполагает, что со
стороны различных

01:02:08.750 --> 01:02:11.149
Соответственно, процессов.

01:02:12.309 --> 01:02:16.468
Различные процессы могут воздействовать на
один и тот же объект, при этом возможно,

01:02:16.508 --> 01:02:18.108
даже на одну и ту же операцию.

01:02:18.228 --> 01:02:23.946
Но при этом получается, что либо, если это
возможно, операция выполняется полностью,

01:02:24.066 --> 01:02:24.906
то есть атамарно

01:02:25.810 --> 01:02:27.848
Если возможности нет, то делается откат.

01:02:28.207 --> 01:02:31.244
Соответственно, система возвращается в то
же состояние, что и была, то есть

01:02:31.363 --> 01:02:33.561
состояние объекта возвращается к
исходному.

01:02:33.800 --> 01:02:38.075
И через некоторое время предполагается,
предпринимается попытка снова выполнить

01:02:38.115 --> 01:02:38.874
эту операцию.

01:02:39.697 --> 01:02:44.021
Ну и вот здесь возможны такие проблемы,
так называемые мёртвые объятия, когда два

01:02:44.221 --> 01:02:49.907
процесса пытаются поочерёдно друг другом
овладеть и сделать какое-то действие.

01:02:50.388 --> 01:02:55.313
Вот. И как раз получается так, что они
только занимаются откатами, а до конца

01:02:55.433 --> 01:02:56.234
провести не могут.

01:02:56.411 --> 01:03:00.416
Ну, для этого случая нужен какой-то
внешний арбитр по отношению к процессам,

01:03:00.736 --> 01:03:06.623
который бы такие в те времена, такие
моменты выяснял и, собственно, как бы один

01:03:06.863 --> 01:03:10.427
из этих процессов остановил, дал бы
другому сделать работу, а потом,

01:03:10.467 --> 01:03:11.668
собственно, запустил и второй.

01:03:12.508 --> 01:03:16.992
Ну вот здесь следует обратить внимание,
что наша задача при построении этих

01:03:17.032 --> 01:03:21.316
моделей только декларировать способ
синхронизации, и это решает решение ключом

01:03:21.597 --> 01:03:27.562
проблемы. Решается, собственно, сама
синхронизация на системном уровне, чаще

01:03:27.682 --> 01:03:29.444
всего путём создания копий.

01:03:30.172 --> 01:03:31.572
объектов. Вот.

01:03:31.692 --> 01:03:36.692
Но это уже вопрос более тонкосистемного
программирования, который вот при

01:03:36.812 --> 01:03:39.092
построении наших моделей не
рассматривается.

01:03:39.572 --> 01:03:42.412
То есть весь механизм реализации ложится
на систему.

01:03:42.572 --> 01:03:46.212
Наша задача только определить тот или иной
тип синхронизации.

01:03:49.690 --> 01:03:51.370
Так, варианты примеров синхронизации.

01:03:51.450 --> 01:03:54.771
Некоторые языки программирования
поддерживают перечисленные конструкции

01:03:54.931 --> 01:03:59.653
непосредственно. Так, например, в языке
Javo есть свойство Sinchonyzite, то есть

01:03:59.733 --> 01:04:03.454
эквивалентное свойство Concurent в Омоэле,
то есть параллельное.

01:04:03.774 --> 01:04:06.855
В любом языке, поддерживающем
параллельность, все три подхода можно

01:04:07.015 --> 01:04:08.655
реализовать с помощью семофоров.

01:04:09.383 --> 01:04:12.704
Вот симафоры в том же C++ C.

01:04:13.225 --> 01:04:17.426
Применение примечание.

01:04:17.507 --> 01:04:21.348
С помощью ограничений можно моделировать
различные вариации примитивов

01:04:21.508 --> 01:04:24.710
синхронизации. Например, можно
моделировать свойства конкурента.

01:04:25.549 --> 01:04:29.352
Разрешит наличие нескольких читателей, но
только одного писателя.

01:04:31.313 --> 01:04:34.115
Ну, вот такие вот особые случаи можно
также моделировать.

01:04:34.235 --> 01:04:36.117
Пример моделирования активного класса.

01:04:36.277 --> 01:04:41.160
Класс-буфер, атрибуты, операции и,
собственно, свойства синхронизации к

01:04:41.240 --> 01:04:42.441
операциям добавлены.

01:04:42.521 --> 01:04:44.082
Операции имеют конкурента.

01:04:44.848 --> 01:04:47.086
То есть параллельный способ синхронизации.

01:04:52.281 --> 01:04:54.359
Моделирование потоков управления.

01:04:54.959 --> 01:04:57.676
Моделирование нескольких потоков
управления осуществляется следующим

01:04:57.716 --> 01:05:01.473
образом. Идентифицируйте возможности
распараллелирования действий и

01:05:01.593 --> 01:05:05.389
материализируйте каждый поток управления в
виде активного класса.

01:05:05.942 --> 01:05:10.583
Сгруппируйте общие множества активных
объектов в активный класс.

01:05:10.744 --> 01:05:14.785
Избегайте переусложнения вида системы с
точки зрения процессов.

01:05:15.185 --> 01:05:19.187
Причиной которой может стать введение
слишком большой степени параллелизма.

01:05:19.467 --> 01:05:23.188
Рассмотрите баланс распределения
обязанностей между активными классами, а

01:05:23.269 --> 01:05:26.070
затем исследуйте, с какими другими
активными классами

01:05:27.379 --> 01:05:31.338
С какими-то и пассивными классами
статически кооперируется каждый из них.

01:05:31.418 --> 01:05:35.058
Убедитесь, что каждый активный класс имеет
внутреннюю структуру с высокой степенью

01:05:35.058 --> 01:05:39.097
связанности и слабо связан с соседними
классами и что для каждого класса

01:05:39.497 --> 01:05:42.177
правильно выбран набор атрибутов операций
сигналов.

01:05:42.870 --> 01:05:46.511
Отобразите статические решения в виде
диаграмм классов, явно выделив каждый

01:05:46.591 --> 01:05:51.272
активный класс. Рассмотрите, как каждая
группа классов динамически кооперируется с

01:05:51.352 --> 01:05:54.993
прочими. Отобразите свои решения на
диаграммах взаимодействия.

01:05:55.353 --> 01:05:59.154
Явно покажите активные объекты как
начальные точки соответствующих потоков

01:05:59.314 --> 01:06:03.355
управления. Идентифицируйте каждую
связанную последовательность, присваивая

01:06:03.515 --> 01:06:04.996
ей имя активного объекта.

01:06:05.196 --> 01:06:08.597
Обратите особое внимание на коммуникации
между активными объектами.

01:06:09.212 --> 01:06:12.815
Пользуйтесь по мере необходимости как
синхронными, так и ассинхронными

01:06:12.895 --> 01:06:17.017
сообщениями. Обратите внимание, что
синхронизацию активных объектов и тех

01:06:17.097 --> 01:06:21.860
пассивных объектов, с которыми они
кооперируются, применяйте наиболее

01:06:21.900 --> 01:06:26.743
подходящую семантику, последовательную и
охраняемую, либо параллельную.

01:06:30.114 --> 01:06:34.708
Так. Ну, в данном плакате показано
моделирование потоков управления.

01:06:35.147 --> 01:06:39.740
То есть есть какая-то трейдинговая
система, которая, собственно, следит за

01:06:39.820 --> 01:06:40.659
курсом акций.

01:06:46.175 --> 01:06:50.933
Вы видите три объекта, которые параллельно
питают систему информации: сток-тикер, то

01:06:50.973 --> 01:06:56.091
есть биржевой тикер, индекс Watcher,
наблюдатель индекса, CNN News Fit, то есть

01:06:56.171 --> 01:06:57.771
новостная лента CN.

01:06:58.131 --> 01:07:01.090
Соответственно, эти объекты имеют имена S
и C.

01:07:01.250 --> 01:07:06.088
Два из них: SI обменивается каждый со
своим экземпляром класса «аналитик».

01:07:06.488 --> 01:07:08.527
То есть, соответственно, имеет свой
аналитик.

01:07:08.647 --> 01:07:11.766
То есть AI аналитик, как видите, A2 —
аналитик.

01:07:12.555 --> 01:07:18.232
Ну и оба, собственно, связаны с классом
Alert Manager, то есть какой-то менеджер

01:07:18.352 --> 01:07:18.792
тревоги.

01:07:23.608 --> 01:07:26.566
То есть диспетчер оповещений, которому мы
дали имя M.

01:07:26.686 --> 01:07:30.643
Следовательно, M необходимо спроектировать
так, чтобы он сохранял свою семантику в

01:07:30.683 --> 01:07:32.641
присутствии нескольких потоков управления.

01:07:32.801 --> 01:07:37.398
M и Ц одновременно общается с Т, то есть
объектом класса трейдинг-менеджер, то есть

01:07:37.518 --> 01:07:38.637
управляющий трейдингом.

01:07:39.358 --> 01:07:43.793
Каждому соединению присвоен порядковый
номер, определяющий тем, какой поток

01:07:43.873 --> 01:07:45.511
управления им владеет.

01:07:46.150 --> 01:07:50.465
Так, ну вот, собственно, на уровне
взаимодействия показан-показан принцип

01:07:50.745 --> 01:07:54.820
синхронизации. То есть источники
информации курса акций у нас

01:07:55.693 --> 01:08:01.927
Биржевой тикер, индекс Wature и даже CNM
News Fit тоже играет роль

01:08:02.806 --> 01:08:06.641
в конце концов на принятие решения
трейдинг-менеджером.

01:08:07.201 --> 01:08:10.517
Вот. Ну и промежуточный класс Alvert
Manager, который при

01:08:12.501 --> 01:08:17.905
...в каком-то катастрофическом падении или
росте курса акций дало бы сигнал,

01:08:17.986 --> 01:08:23.270
соответственно, по Stald непосредственно
основному блоку, который принимает

01:08:23.550 --> 01:08:25.592
решение. В данном случае Трейдинг

01:08:30.796 --> 01:08:32.918
Так, ну это всё можно сказать...

01:08:34.304 --> 01:08:37.145
В рамках одного одного процесса всё
работает.

01:08:37.306 --> 01:08:39.867
То есть подпроцессы разные или нити.

01:08:40.068 --> 01:08:44.350
Но всё это, собственно, можно
рассматривать как одну, один процесс.

01:08:44.551 --> 01:08:45.912
Система нераспределённая.

01:08:47.949 --> 01:08:49.470
Межпроцессная коммуникация.

01:08:49.550 --> 01:08:53.311
При включении в систему нескольких потоков
управления необходимо также рассмотреть

01:08:53.351 --> 01:08:57.272
механизмы, с помощью которых объекты из
разных потоков управления взаимодействуют

01:08:57.312 --> 01:09:02.033
друг с другом. Объекты, находящиеся в
разных нитях, существующих в рамках одного

01:09:02.113 --> 01:09:05.554
и того же процесса, могут общаться с
помощью событий, сигналов или вызовов.

01:09:06.052 --> 01:09:09.777
Причём последние могут иметь синхронную
или асинхронную семантику.

01:09:10.178 --> 01:09:14.664
Для обмена информацией через границы
процессов, у каждого из которых своё

01:09:14.824 --> 01:09:18.149
собственное адресное пространство, обычно
применяются другие механизмы.

01:09:20.855 --> 01:09:24.492
Сложность проблемы межпроцессной
коммуникации усугубляется ещё и тем, что в

01:09:24.572 --> 01:09:28.409
распределённых системах процессы могут
исполняться на различных узлах.

01:09:28.569 --> 01:09:31.966
Существует два классических подхода к
межпроцессной коммуникации.

01:09:32.126 --> 01:09:33.525
Прежде всего, передача сообщений

01:09:35.273 --> 01:09:39.313
Собственно, синхронный способ и вызова
удалённых процедур — синхронный способ.

01:09:39.353 --> 01:09:42.513
Вле эти механизмы моделируются,
соответственно, как ассинхронные и

01:09:42.633 --> 01:09:44.632
синхронные события, соответственно.

01:09:44.992 --> 01:09:48.752
Но поскольку это уже не просто вызовы
внутри одного процесса, то проект

01:09:48.872 --> 01:09:50.992
необходимо обогатить дополнительной
информацией.

01:09:51.692 --> 01:09:52.933
Пример будет приведён.

01:09:54.134 --> 01:09:57.976
Рекомендации. Моделирование межпроцессной
коммуникации производится следующим

01:09:58.016 --> 01:10:02.699
образом. Смоделируйте несколько потоков
управления, рассмотрите, какие из этих

01:10:02.779 --> 01:10:06.302
активных объектов могут быть представлены
процессами, а какие нитями.

01:10:06.382 --> 01:10:09.183
Чтобы их различать, воспользуйтесь
подходящими стереотипами.

01:10:09.708 --> 01:10:13.551
Смоделируйте обмен сообщениями с помощью
ассинхронных, а вызовы удалённых процедур

01:10:13.631 --> 01:10:15.512
с помощью синхронных коммуникаций.

01:10:15.792 --> 01:10:20.195
Неформально опишите используемый механизм
с помощью примечателей или более строк с

01:10:20.275 --> 01:10:21.756
помощью коопераций.

01:10:23.077 --> 01:10:26.519
Вот, собственно, моделирование
межпроцессной коммуникации показано на

01:10:26.599 --> 01:10:26.839
данном

01:10:28.159 --> 01:10:34.000
Слайды. То есть есть какая-то система
подготовки путешествий.

01:10:34.520 --> 01:10:37.361
То есть, собственно, турпоездки от
турфирмы.

01:10:37.521 --> 01:10:42.441
То есть, с одной стороны, как видите, у
нас, соответственно, какой-то клиент

01:10:43.401 --> 01:10:44.002
непосредственно

01:10:44.787 --> 01:10:49.352
Клиентская программа взаимодействует с
каким-то сервером резервейшн-Агент,

01:10:49.432 --> 01:10:52.716
который, собственно, это путешествие и
готовит, который, в свою очередь,

01:10:53.116 --> 01:10:57.161
взаимодействует непосредственно с
гостиничным агентом по поводу бронирования

01:10:57.281 --> 01:11:01.125
билетов, с айлан-сервисом, то есть сервер

01:11:02.580 --> 01:11:06.623
Для билетов, авиабилетов.

01:11:07.664 --> 01:11:11.306
Вот. При этом тут, видите, указывается,
что коммуникация на основе службы

01:11:11.426 --> 01:11:14.428
сообщений Джавобинс предполагается.

01:11:18.137 --> 01:11:21.975
На рисунке показана распределённая система
бронирования билетов, в которую процессы

01:11:22.095 --> 01:11:26.173
использования, так, ну, скорее не билетов,
а всей поездки в целом, то есть включая

01:11:26.333 --> 01:11:28.532
гостиничный номер, в которые процессы

01:11:29.449 --> 01:11:31.090
Исполняется на четырёх узлах.

01:11:31.170 --> 01:11:35.252
Каждый объект мортирован стереотипом
process, а также помеченными значениями

01:11:35.372 --> 01:11:38.613
location, который определяет его
физическое положение.

01:11:38.773 --> 01:11:42.815
Коммуникация между объектами reservation
agent, то есть агент бронирования,

01:11:43.015 --> 01:11:44.696
тикет-менеджер, то есть диспетчер

01:11:45.757 --> 01:11:49.555
Выдача билетов. Холтел-агент, то есть
гостиничный агент, асинхронны.

01:11:49.915 --> 01:11:54.672
В примечании написано, что коммуникации
построены на основе службы сообщения,

01:11:54.672 --> 01:11:56.112
реализованной на джавоз.

01:11:56.192 --> 01:12:01.349
Коммуникация между объектами 3 плэнер, то
есть планировщик маршрута, и reservation

01:12:01.429 --> 01:12:03.788
System система резервирования, синхронная.

01:12:05.562 --> 01:12:11.444
Семантика их взаимодействия может быть
раскрыта, если раскрыть кооперацию Корба

01:12:11.604 --> 01:12:16.926
ОРБ. Три планера выступает в роли клиента,
а реверсвешн один, соответственно,

01:12:16.966 --> 01:12:20.847
сервера. Раскрыв эту кооперацию, вы
увидите детали совместной работы сервера и

01:12:20.927 --> 01:12:21.327
клиента.

01:12:22.312 --> 01:12:25.153
То есть, вот, собственно, такая система
распределённая.

01:12:25.513 --> 01:12:29.033
Как видите, указывает, что модули
удалённые процессы.

01:12:29.193 --> 01:12:33.834
Один процесс расположен соответственно в
location Client, другой

01:12:34.880 --> 01:12:39.160
Локэшiн-резервейшн-сервер, то есть это,
наверное, вот основной как раз сервер

01:12:39.720 --> 01:12:41.361
туристической компании.

01:12:41.561 --> 01:12:48.082
Причём они взаимодействуют непосредственно
с онлайн-сервисом по поводу билетов.

01:12:48.282 --> 01:12:51.842
И, как видите, Holdal-сервер.

01:12:51.962 --> 01:12:54.483
То есть ещё, наверное, таких несколько.

01:12:55.164 --> 01:12:57.925
Не один же, не с одной же они гостиницей
имеют дело.

01:12:58.686 --> 01:13:03.569
Так, ну вот, собственно, взаимодействие
между клиентом и сервером, то есть

01:13:03.969 --> 01:13:08.291
клиентской программой, сервером какого-то
турбюро, осуществляется по принципу

01:13:08.411 --> 01:13:09.932
Клиент-сервер.

01:13:10.853 --> 01:13:14.975
Эта коммуникация более подробно может быть
раскрыта, если мы раскроем вот эту

01:13:15.015 --> 01:13:16.897
кооперацию CorbaRB.

01:13:33.531 --> 01:13:34.970
Так, ну из блок советов.

01:13:35.050 --> 01:13:38.928
Хорошо структурированный активный класс, и
активный объект обладает следующим набором

01:13:38.968 --> 01:13:43.326
свойств. Представляет независимый поток
управления, который максимально использует

01:13:43.446 --> 01:13:46.485
потенциальные возможности истинного
параллелизма в системе.

01:13:49.164 --> 01:13:53.202
Не только, не настолько мелки, чтобы
требовать наличия множества других

01:13:53.282 --> 01:13:55.201
активных элементов, которые можно привести
к

01:13:55.823 --> 01:14:00.186
переусложнённой или нестабильной
архитектуре процессов Аккуратно управляет

01:14:00.306 --> 01:14:04.109
коммуникацией между активными элементами,
выбирая наиболее подходящий случай

01:14:04.149 --> 01:14:05.910
механизм синхронный или ассинхронный

01:14:06.667 --> 01:14:10.944
Исходят из трактовки каждого объекта как
критической области, используя подходящие

01:14:11.064 --> 01:14:15.380
синхронизирующее свойства для сохранения
его семантики в присутствии нескольких

01:14:15.460 --> 01:14:19.417
потоков управления. Явно различают
семантику, процесса и нити.

01:14:19.937 --> 01:14:24.094
Рисуя в эмоль, активный класс или активный
объект, показывайте только те атрибуты,

01:14:24.134 --> 01:14:27.611
операции и сигналы, которые важны для
понимания абстракции в соответствующем

01:14:27.651 --> 01:14:28.170
контексте.

01:14:29.016 --> 01:14:32.378
Явно показываете все синхронизирующие
свойства операции.

01:14:36.260 --> 01:14:38.582
Так, ну на этом сегодня мы с вами
закончим.

01:14:38.742 --> 01:14:39.662
Спасибо за внимание.