Объявление неабстрактной операции одновременно является и объявлением её метода.

⇐ Назад

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

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

В теле метода описывается алгоритмическая реализация операции (логика процесса).

Пример комментария:

Операции могут быть сигналами,т.е. описывать поведение объекта класса при получении сообщения в виде сигнала.

Сигнал (signal)является спецификацией асинхронной коммуникации (взаимодействия) между объектами. Сигнал является фундаментальным видом коммуникации, имеет характер одностороннего сообщения, идущего от одного объекта к другому. Поэтому операция по сигналу не имеет возвращаемого значения. Перед ней ставится стереотип «signal». Более подробно сигналы, события и сообщения будут изучаться далее.

Общий синтаксис записи операции: строка текста

Стереотип» <видимость> имя (<список параметров>): <возвращаемый тип> {строка свойств}.

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

Приведём примеры более развёрнутой спецификации классов.

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

Отношения между классами.

Классы могут находиться между собой в различных отношениях (связях). Базовыми отношениями являются:

· отношение зависимости (dependency relationship);

· отношение ассоциации (association relationship);

· отношение обобщения (generalization relationship);

· отношение реализации (realization relationship).

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

В UML определены следующие стандартные стереотипы зависимостей:

become (превращаться), bind (связывать), call (вызывать), copy (копировать), create (создавать), derive (выводить), extend (расширять), friend (быть дружественным), import (импортировать), include (включать), instanceOf (являться экземпляром), instantiate (создать экземпляр), powertype (множество всех типов), send (отправить), trace (трассировать), use (использовать).

Источник 1

Источник 2

Класс А

Класс В

Источников зависимости может быть несколько:

Отношение зависимости является наиболее общим в языке UML. Все остальные могут считаться частным случаем этого отношения.

Ассоциация (association) – описывает связи между экземплярами классов (объектами). Для понимания семантики этой связи нужно оперировать с частными примерами классов (в отличие от зависимости, которые относятся к классу в целом). Кроме того, в ассоциации проставляется множественность участия экземпляров в связи и обязательность. Обозначается непрерывной сплошной линией

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

Экземпляром этого отношения является, например, пара Иванов – ООО «Ракурс».

В N–арной ассоциации участвуют три и более класса, при этом один класс может участвовать в ассоциации более, чем один раз. Каждый экземпляр такой ассоциации - N-мерный кортеж из объектов соответствующих классов.

Графически N-арная ассоциация обозначается ромбом. Пример: тернарная ассоциация из классов: футбольная команда, год, игра ( ).

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

Важной характеристикой ассоциации является множественность ассоциации. Обозначения множественности такие же, как у атрибутов класса (см. раздел ). Символ “*” обозначает “0. .*”, т.е. необязательность связи. Ассоциация представляет собой ссылки на соответствующие объекты. В процессе работы системы связи могут появляться и исчезать, соответственно списки корректируются у одного или обоих полюсов.

В более сложном случае ассоциация может быть классом (класс – ассоциация, association class), в нём присутствуют и свойства класса, и свойства ассоциации. Экземплярами класса являются связи, в которых имеются не только ссылки на объекты, но и конкретные значения атрибутов. Классы – ассоциации могут иметь операции, изменяющие атрибуты связи, могут участвовать в различных ассоциациях, но между собой ассоциаций иметь не могут.

Пример обозначения класса-ассоциации Работает в представлен на рисунке .

Обладатель работы

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

Роль сотрудника

Роль фирмы

экземпляра связи, например, несколько значений окладов сотрудника по месяцам, то класс-ассоциацию уже использовать нельзя. Нужно вводить обычный класс с атрибутами (рис ).

1.1. Частным случаем ассоциации является исключающая ассоциация (xor association). Она представляет собой две или более ассоциаций, которые одним полюсом крепятся к единому (базовому) классу.

1.2. Показывает, что из нескольких вариантов ассоциация в каждый момент времени может использоваться только одна: счёт в банке может быть открыт для физического лица или организации (юридического лица).

1.3. Важным частным случаем ассоциации является агрегация.

1.4.

Агрегация (Aggregation) – один из классов (агрегат) состоит из (включает в себя, характеризуется) других классов. (отношение часть/ целое (Part of)). Это отношение является фундаментальным при моделировании сложной системы, позволяет декомпозировать систему на составные части. В агрегации принцип наследования не 7соблюдается. Каждая часть обладает своими атрибутами и поведением. Агрегация в UML обозначается ромбом или

1.5.

лекция №9

1.6. Частным случаем агрегации является композиция.

1.7. Композиция (composition) – усиленная форма агрегации, которой агрегат, называемый композифм, несёт полную ответственность за создание и уничтожение своих частей, т.е. самостоятельно классы – части композита существовать не могут. Таким образом время жизни частей не превышает времени жизни агрегата – композита (она может быть меньше). Кроме того, каждая часть может входить только в один экземпляр агрегации..Композиция обозначается закрашенным видом.

1.8.

1.9. Единственное ограничение, которое вносит агрегация в ассоциации – отсутствие цикличности связи, т.к. класс не может содержаться сам в себе.

1.10. Обобщение (generalization) – обычное таксономическое отношение между родителем (предком) и частными примерами (дочерьми, детьми, сыновьями, потомками).

1.11. Экземпляр потомка могут использовать всюду, где объявлен более общий элемент, сохраняются все свойства и операции (методы). Обобщение используется между классами, пакетами, вариантами использования, актантами и др. Обозначается прямой линией с треугольной стрелкой

1.12.

1.13.

1.14. Граф –нерархичеркое дерево. Различают прямые и непрямые потомки. Цикличность не допускается. UML допускает множественное обобщение (несколько предков), т.е. множественное наследование. В обобщение может использоваться следующие ограничения.

1.15. Несовместимость (disjoint) – классы-потомки не могут содержать экземпляры-объекты, являются экземплярами двух или более классов.

1.16. Перекрытие (overlapping) – отдельные экземпляры классов-потомков может принадлежать одновременно нескольким классам. Например, многоугольник – предок ромба и прямоугольника, квадрата. Квадрат – одновременно ромб и прямоугольник.

1.17.

1.18.

лекция № 10
ОТНОШЕНИЕ РЕАЛИЗАЦИИ (Realization relationship)

1.19. Реализация – это отношение между спецификацией и программной реализацией.

1.20. При этом считается, что в модели есть элемент, определяющий поведение и элемент, определяющий реализацию этого поведения. Есть много способов реализации одной и той же спецификации, одна реализация может относиться к нескольким спецификациям, т.е. это отношение M: N.

1.21. Тот, кто реализует, называется клиентом, носитель спецификации – источник (поставщик). Клиент не наследует операции источника, он их определяет вновь или наследует от своего предка, однако, для полноты должны быть объявлены все операции источника. Если варианты использования не содержат указаний относительно реализации, то классы уже могут содержать полную информацию о реализации (атрибуты, типы).

1.22. Поэтому для спецификации введён ещё один особый класс – «интерфейс», который определяет спецификацию и не содержит деталей реализации. Более подробно интерфейсы будут изучены в следующих разделах (на логическом уровне).

1.23. Кроме того, класс может использоваться и для спецификации, если в нём не определена реализация.

1.24. Таким образом, источниками реализаций и UML являются варианты использованииобычные классы с неполной информацией и специальные классы – интерфейсы.

1.25. Программная реализация осуществляется классом или диаграммой кооперации.

1.26. Если источником является абстрактный класс, то его реализацией считаются его потомки, т.к. им нечего не следовать, кроме спецификации, а собственных методов и значений этот класс не имеет.

1.27.

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

ОБЪЕКТЫ (OBJECTS)

1.28.

Объекты – экземпляр класса, его частный пример, создаётся на этом выполнения программы. Это – мгновенный снимок системы, каждый объект обладает индивидуальностью. Таким образом диаграмма классов, является частным случаем (примером) диаграммы классов, графически объект изображается так же, как класс. Для объекта указываются конкретные значения атрибутов, как его собственных, так и наследуемых от всех классов-предков. Тип атрибута пишется с большой буквы, сам атрибут с малой буквы. Чтобы отличить его от класса, имя подчёркивается.

1.29. Если атрибут изменяемый, по умолчанию, то во время выполнения значение может измениться, если frozen – то нет. Значения должны удовлетворять всем явным и неявным ограничениям в модели. У атрибутов не может быть дубликатов! Наследованием наследуется только один атрибут из дублей. Объект может менять свой непосредственный класс в динамике, но делается это специальной операцией.

1.30. При этом в множественном случае непосредственный класс, хотя бы один, должен оставаться, иначе объект должен быть уничтожен. Для объекта может быть вызвана любая операция его класса и всех классов-предков. Значением типа атрибута может быть класс, тогда в качестве значения может использоваться как этот класс, так и любой из его потомков. В объекте разделов всего 2: имя и атрибуты, операции не изображаются – они общие для всех объектов.

1.31. Перед именем класса может ставиться имя пакета. Оно определяется двойным двоеточием. Пример: displayWindow: WindowingSystem:: GraphicWundows:: Window.

1.32. Таким образом отображается иерархия пакетов. Стереотипы классов на объекте ставится в угловых скобках или изображаются пунктограммой в верхнем правом углу. Все связи – сплошными линиями. При множественном наследовании классы могут быть перечислены через запятую. Например: APerson: Professor, Teacher; Сотрудник: Профессор, преподаватель. В атрибутах типы можно не указывать.

1.33. При изменении значений атрибутов объект надо изображать вновь, связывая с предыдущим символом превращения. Более подробно – в диаграмме кооперации.

1.34. Диаграмма объектов обычно создаётся для отдельных объектов со сложным поведением и взаимодействием.

ШАБЛОНЫ (параметризованные классы)

Шаблон (template) – элемент модели с параметрами, для использования которого необходимо связать параметры с конкретными значениями.

Параметров может быть один или несколько. Таким образом, шаблон определяет варианты элемента (обычно это либо типы атрибутов, либо операции).

Изображается наложением маленького пунктирного прямоугольника на правый верхний угол символа класса.

1.35. Шаблон не может быть использован непосредственно как класс, обычно это суперкласс, а его параметры уточняются в потомках. В этом случае они связываются зависимостью (dependency) bind (стереотип) – связывать с использованием шаблона.

Более частный случай – отношение обобщения с наследованием свойств шаблона.

1.36. Адрес может быть получен из шаблона. Связный – список связыванием параметров S, K, I с атрибутами “улица, дом, квартира”. Этот же шаблон может использоваться и для других классов. Например, точки на плоскости (координаты точки, х,у).

1.37. За счёт шаблонов (параметризированных классов) можно существенно уменшить размеры диаграммы.

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

Рекомендации по построению диаграмм классов

1.39. Диаграмма классов во многом определяет реализации системы. На концептуальном уровне следует использовать русские имена. На логическом уровне и физическом уровнях осуществляется переход на английские имена с использованием рекомендаций по транскрипции и трансляции русских букв латинскими буквами (Ц – ts, Ж – zh, Ы – Y и т.д.).

1.40. Примеры диаграмм классов:

1.41.

1.42.

1.43.

1.44.

1.45.

1.46.

1.47.

1.48.

1.49.

1.50.

Фрагмент диаграммы классов для Асу тепличного хозяйства

1.51.

1.52.

1.53.

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

1.55. 1.8. Диаграмма состояний

1.56. Диаграмма состояний (statechart diagram) – диаграмма, на которой изображается конечный автомат с простыми состояниями, переходами вложенными композитными состояниями.

1.57. Концепция диаграммы состояний разработана Дэвидом Хэрелом (David Harel).

1.58. В отличие от статического представления диаграмма состояний является детализацией диаграммы вариантов использования, на логическом уровне она описывает поведение объектов системы и системы в целом.

1.59. Поскольку речь идёт о состояниях объектов – экземпляров классов, то предварительно должны быть определены классы объектов на логическом уровне, т.е. должна быть построена диаграмма классов.

1.60. В основе диаграммы лежит понятие конечного автомата (state machine).

1.61. Конечный автомат – это спецификация последовательности состояния, через который в течение своей жизни проходит объект, в том числе взаимодействуя с другими объектами и находясь под воздействием некоторого потока событий. Конечный автомат всегда связан или определён для некоторого исходного элемента модели (объекта класса, метода или диаграмма кооперации).

1.62. Состояния, в которых может находиться элемент, образует пространство состояний, обычно оно считается конечным (конечный автомат).

1.63. Графически автомат может быть описан графом, в котором вершинами является состояние, а дугами – возможные переходы.

1.64. Простейший пример: техническое устройство, которое может быть в двух состояниях: исправно/неисправно.

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

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

1.67. Состояния понимаем как условия или ситуация в жизненном цикле объекта, когда объект выполняет какую-либо деятельность, либо ожидает какие-либо события.

1.68. Считается, что в определённом состоянии объект может находиться конечное время. Каждый конечный автомат описывает поведение какого-либо класса. Каждый класс может иметь конечный автомат.

1.69. Переход (transition) – реакция объекта на некоторые событие. Объект выполняет действие, прикреплённое к переходу, и меняет своё состояние. Каждому состоянию соответствует своё множество переходов.

1.70. Изменения состояния является атомарным действием, которое нельзя прервать извне. Обычно время перехода считается нулевым (если оно не оговорено отдельно), т.е. переходы осуществляются мгновенно.

1.71. Поведение объекта определяется как последовательная переменная по графу состояний от вершины к вершине по дугам.

1.72. Из всей совокупности состояний выделяются два особых: начальное состояние и конечное.

1.73. Последовательность изменений состояний упорядочена во времени. Хотя в явном виде время может не указываться.

1.74. Каждое состояние должно быть достижимо, т.е. существовать ориентированный путь в графе от начального состояния к нему.

1.75. Автоматы могут вкладываться друг в друга, в связи с этим состояния могут содержать в себе другие состояния. Макросостояния изображаются большим прямоугольником, содержащим в себе другие состояния.

1.76. Дополнительные автоматы называются подавтоматами (submachines).

1.77. Пример: неисправность может быть подразделена на более детальные подсостояния.

Обязательные условия для конечного автомата:

1. Автомат не помнит историю своего перемещения из состояния в состояние (без памяти); более детально это можно учесть введением специальных исторических состояний.

2. В каждый момент времени автомат может находиться только в одном из состояний (последовательное поведение). Для моделирования параллельного поведения в одной модели рассмотрения несколько отдельных автоматов.

3. Время присутствует в автомате в неявном виде, но в диаграмме активности (activity) (деятельности) может быть указана явно.

4. Количество состояний – конечно, все состояния задаются явно.

5. Не должно быть изолированных состояний и переходов.

6. Не должно быть конфликтирующих переходов, т.е. объект не может перейти одновременно в два состояния из какого-либо (кроме случая параллельных автоматов)

1.78. Исключение конфликтов достигается введением сторожевых условий.

1.79. Состояние (state) – является фундаментальным понятием языка UML и прикладного системного анализа. Вся концепция динамичной системы основывается на понятии состояния.

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

1.81.

Не каждый атрибут класса может определять состояние.

1.82. Имя состояния рекомендуется выражать глаголом в настоящем времени (звонит, печатает) – что делает объект? или причастием (занят, свободен, передано, получено) – результат действия.

1.83. Все состояния, даже анонимные (без имени) должны быть различными. Дублирование состояний на диаграмме не допускается.

Список внутренних действий (action) или деятельностей (activity) отражает те действия, которые выполняются моделируемым объектом в данном состоянии.

1.84. В UML действия и деятельности различаются.

1.85. Действие (action) –выполнимое атомарное вычисление, которое приводит к изменению состояния системы или возврату значения.

1.86. Действие мгновенно, его нельзя прервать извне. Оно либо привязывается к переходу автомата из одного состояния в другое, либо к одному шагу во взаимодействии.

лекция №12

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

1.88. Запуск действий производится переходами. Различают входное событие перехода (поглощение) – автомат устанавливается в определённое состояние и выходное событие перехода – автомат теряет это состояние. Соответственно различают входное и выходное действия.

1.89. Каждое действие описывается отдельной строкой в формате <метка действия ”/” выражение действия>.

1.90. Если выражение действия пусто, то “/” может не указываться. Перечень меток в UML ограничен и не может быть использован в качестве имён событий.

1. Entry – указывает, что действие выполняется в момент входа в данное состояние (входное действие).

2. Exit - указывает, что действие выполняется в момент выхода в данное состояние (выходное действие).

3. Do – специфицирует выполнимую деятельность (“do activity”).

4. Include - указывает, что действие – это обращение к автомату с указанным именем

Деятельность (activity) – продолжительное неатомарное вычисление в конечном автомате.

1.91. Деятельность имеет внутреннюю структуру и может быть прервана переходом по внешнему событию. Оно выполняется в течение конечного времени и поэтому не может быть приписано переходу, а только состоянию в целом.

1.92. Деятельность может продолжаться безостановочно до внешнего прерывания или прекращаться само по себе.

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

1.94. Пример: ввод пароля пользователя.

1.95.

1.96.

1.97.

1.98. Для обозначения выражения действия в UML нет строго определённой нотации. Предполагается, что для этого будет использоваться какой-либо язык программирования. Можно использовать формальный язык описания ограничений Object Constraint Language (OCL), который фактически является частью языка ULM.

1.99. Типовые действия:

· Присваивание цель:= выражение.

· Вызов множество объектов. имя операции (аргумент список).

· Создание new имя класса (аргумент список).

· Уничтожение объект: destroy ().

· Возврат return выражение список.

· Отправка множество объектов. Имя сигнала (аргумент список).

· Превращение terminate.

· Не интерпретируемое действие if (выражение) then (действие) else (действия).

1.100. Для явного различия вызова и отправки можно ставить слова Call и send.

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

1.102. В принципе логику действия может описать и в псевдокоде или даже на ОЭЯ (ограниченном определённом языке). Всё зависит от уровня детализации проекта.

1.103. Начальные и конечные состояния

1.104. Среди всех состояний выделяются частные случаи: начальное состояние (source state) – в некотором по умолчанию объект находится в начальный момент времени. Из него начинается

процесс смены состояний, поэтому никаких внутренних действий и тем более, входных, это состояние не имеет. Изображается закрашенным кружком.

1.105.

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

1.107. Считается, что в момент t = 0 переход работает мгновенно, и, таким образом, время пребывания в начальное состояние всегда равно 0.

1.108.

Конечное состояние (final state)– также не содержит внутренних действий и представляет собой состояние. В котором будет находиться автомат после завершения своей деятельности в конечный момент времени. В этом состоянии объект заканчивает свой жизненный цикл. Изображается закрашенным кружком, помещённым в окружность.

1.109.

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

1.111. На самом высоком уровне переход в конечное состояние помечается как остановка автомата и уничтожение объекта.

1.112.

Переход (transition) – это отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другими.

1.113.

1.114. Изображается направленной стрелкой. В первом состоянии объект может выполнять некоторые действия. Переход во второе состояние возможен только после завершения всех этих действий и при выполнении определённого условия, называемого сторожевым.

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

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

1.117. Если указано сторожевое условие, то оно должно быть истинным в момент наступления переключающего события, иначе переход считается не состоявшимся.

1.118. Возможен переход в себя, т.е. в прежнее состояние, когда исходное и целевое состояния совпадают. Он отличается от внутреннего перехода, т.к. объект покидает состояния и снова входит в него (т.е. выполняются действия exit и entry, в отличие от внутреннего перехода, когда объект остаётся в одном и том же состоянии, но выполняет определённое действие).

лекция №13

1.119. Событие (event) – спецификация некоторого факта в пространстве и во времени. В конечном автомате вызывает переход из одного состояния. В UML различают 4 вида событий.

1.120. Событие вызова (call event) – получение запроса на вызов операции. К получателю события – целевому состоянию – запускается переход, в результате которого операция выполняется, а система переходит в это состояние. Параметры события – ссылки на операцию, её параметры и неявно передаваемый указатель возврата. После завершения перехода или немедленно, если переход не был запущен. Управление возвращается к объекту, вызывавшему операцию.

1.121. Событие изменения (change event) – удовлетворение логического условия, определяемого выражением события. Параметров у этого события нет, считается, что условие проверяется постоянно. События происходит, если условие становится истинным.

1.122. Событие сигнала (signal event) – получение сигнала с параметрами. Одним или множеством объектов. Можно запускать переход. С помощью сигналов объекты осуществляют взаимодействие друг с другом.

1.123. Событие времени (time event) - удовлетворение выражения, содержат время. Это может быть истечение интервала или наступление абсолютного момента времени. Разным объектам могут приписываться разные временные шкалы.

1.124.

Aey

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

В качестве основных составных частей АСОИУ рассматриваются следующие:

· пользователи ;

· эксплуатационный персонал;

· организационно-правовое обеспечение;

· методическое обеспечение;

· техническое обеспечение;

· программное обеспечение;

· информационное обеспечение.

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

⇐ Назад