диаграмма состояний (диаграмма автомата) uml — планёрка — коучинг самореализации

Замечания (описание)

Здесь представлен основной набор символов диаграммы состояний , необходимый для того, чтобы суметь прочитать диаграмму. После ознакомления с другими разделами («Пример», «Применение») вы сможете составлять диаграммы состояний самостоятельно!

 Термин Изображение Описание
 Начальное псевдосостояние (initial pseudostate) диаграмма состояний - начальное псевдосостояниеНачальное состояние системы
 Переход Диаграмма состояний (диаграмма автомата) UML — Планёрка — коучинг самореализацииПереход (transition) означает перемещение из одного состояния в другое.
 Состояние Диаграмма состояний (диаграмма автомата) UML — Планёрка — коучинг самореализацииОбозначает выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам.
 Состояние
активности (activity state)
 Диаграмма состояний (диаграмма автомата) UML — Планёрка — коучинг самореализацииСложный шаг в прецеденте можно представить другим прецедентом.
В терминах языка UML мы говорим, что первый прецедент включает (includes) второй.
 Конечное состояние Диаграмма состояний (диаграмма автомата) UML — Планёрка — коучинг самореализацииПозволяет обозначить границы систем или подсистем.
Внутренние активности (internal activities)Диаграмма состояний (диаграмма автомата) UML — Планёрка — коучинг самореализацииСлучай когда состояния могут реагировать на события без совершения перехода, и в этом случае событие, защита и активность размещаются внутри прямоугольника состояния.
Входная активностьВходная активность выполняется всякий раз, когда вы входите в состояние
Выходная активностьВыходная активность – выполняется всякий раз, когда вы покидаете состояние.
СуперсостояниеДиаграмма состояний UML - суперсостояниеЧасто бывает, что несколько состояний имеют общие переходы и внутренние активности. В таких случаях можно их превратить в подсостояния (substates), а общее поведение перенести в суперсостояние (superstate).
Параллельные состоянияДиаграмма состояний UML - параллельные состоянияСостояния могут быть разбиты на несколько параллельных состояний, запускаемых одновременно.

Внутренние активности в диаграмме состояний

Состояния могут реагировать на события без совершения перехода, используя внутренние активности (internal activities), и в этом случае событие, защита и активность размещаются внутри прямоугольника состояния.

На рис. 10.2 представлено состояние с внутренними активностями символов и событиями системы помощи, которые вы можете наблюдать в текстовых полях редактора UI. Внутренняя активность подобна самопереходу (self-transition) – переходу, который возвращает в то же самое состояние. Синтаксис внутренних активностей построен по той же логической схеме события, защиты и процедуры.

Похожее:  ИНСТРУКЦИИ ПО ЛИЧНОМУ КАБИНЕТУ В МИИТ

На рис. 10.2 показаны также специальные активности: входная и выходная активности. Входная активность выполняется всякий раз, когда вы входите в состояние; выходная активность – всякий раз, когда вы покидаете состояние.

Диаграмма взаимодействия (кооперации, collaboration diagram)

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

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

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

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

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

Но давайте же, наконец, перейдем к примерам (рис. 2.15):

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

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

И, наконец, еще один пример (рис. 2.17), который должен вызвать легкое “дежавю” у внимательного читателя.

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

Диаграмма классов (class diagram)

Вообще-то, понятие класса нам уже знакомо, но, пожалуй, не лишним будет поговорить о классах еще раз. Классики о классах говорят очень просто и понятно:

Класс (class) – категория вещей, которые имеют общие атрибуты и операции.

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

Классы используются в процессе анализа предметной области для составления словаря предметной области разрабатываемой системы. Это могут быть как абстрактные понятия предметной области, так и классы, на которые опирается разработка и которые описывают программные или аппаратные сущности.

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

Информация с диаграммы классов напрямую отображается в исходный код приложения – в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования (обычно Java или C ). Таким образом, диаграмма классов – конечный результат проектирования и отправная точка процесса разработки.

Но мы опять заговорились, а, как известно, лучше один раз увидеть, чем сто раз услышать. Мы уже знаем, как классы обозначаются в UML, но пока еще не видели ни одной диаграммы “с их участием”. Итак, посмотрим на примеры диаграмм классов.

Первый пример (рис. 2.5) весьма прост. Как видим, он, хоть и немного однобоко, иллюстрирует с помощью операции наследования или генерализации “генеалогическое древо” бытовой техники. Думаем, мы бы поняли смысл этой диаграммы, даже если бы ничего не знали о классах и не занимались программированием вообще.

Рассмотрим еще пример (рис. 2.6):

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

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

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

Диаграмма развертывания (deployment diagram)

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

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

Какую пользу можно извлечь из диаграмм развертывания? Во-первых, графическое представление ИТ-инфраструктуры может помочь более рационально распределить компоненты системы по узлам сети, от чего, как известно, зависит в том числе и производительность системы.

Диаграмма развертывания показывает топологию системы и распределение компонентов системы по ее узлам, а также соединения – маршруты передачи информации между аппаратными узлами. Это единственная диаграмма, на которой применяются “трехмерные” обозначения: узлы системы обозначаются кубиками. Все остальные обозначения в UML – плоские фигуры. Но приведем пример (рис. 2.24):

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

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

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

А еще на диаграммах развертывания можно обозначать компоненты системы, т. е. показывать их распределение по аппаратным узлам, но на этом мы пока останавливаться не будем: этих двух примеров уже достаточно, чтобы вы научились распознавать этот вид диаграмм, ведь правда?

Если да, то пойдем дальше.

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

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

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

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

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

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

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

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

Состояние

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


Графическое обозначение состояния:

Секция «Список внутренних действий» содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого  элемента  в  данном  состоянии.  Каждое  из  действий записывается в виде отдельной строки и имеет следующий формат:

<метка-дѐйствия ‘/’ выражение-действия>

Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, определенная выражением действия:


  • entry –эта  метка  указывает  на  действие,  специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);
  • exit –эта  метка  указывает  на  действие,  специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);
  • do –эта  метка  специфицирует  выполняющуюся  деятельность («doactivity»), которая выполняется в течение всего времени, пока объект находится  в  данном  состоянии,  или  до  тех  пор,  пока  не  закончится вычисление, специфицированное следующим за ней выражением действия. В  последнем  случае  при  завершении  события  генерируется соответствующий результат;
  • include –эта метка используется для обращения к подавтомату, при этом  следующее  за  ней  выражение  действия  содержит  имя  этого подавтомата.

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

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

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

Переход

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

Переход  осуществляется  при  наступлении  некоторого  события: окончания  выполнения  деятельности  (doactivity),  получении  объектом сообщения или приемом сигнала. На переходе указывается имя события Кроме  того,  на  переходе  могут  указываться  действия,  производимые объектом в ответ на внешние события при переходе из одного состояния в другое. Срабатывание перехода может зависеть не только от наступления некоторого  события,  но  и  от  выполнения  определенного  условия, называемого сторожевым условием. Объект перейдет из одного состояния в другое  в  том  случае,  если  произошло  указанное  событие  и  сторожевое условие приняло значение «истина».

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

<сигнатура события>'[‘<сторожевое условие>’]’ <выражение действия>.

Событие

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

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

Сторожевое условие

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

В общем случае из одного состояния может быть несколько переходов с одним и тем же событием-триггером. При этом никакие два сторожевых условия не должны одновременно принимать значение «истина». Каждое из сторожевых условий необходимо вычислять всякий раз при наступлении соответствующего события.

Диаграмма состояний для моделирования почтовой программы-клиента:

Составное состояние и подсостояние

Составное  состояние  (compositestate) – такое  сложное  состояние, которое состоит из других вложенных в него состояний. Последние будут выступать по отношению к первому как подсостояния (substate).


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

Пример составного состояния:

Примеры диаграмм состояний:

Как применять технику креативности

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

Например, диаграммы взаимодействия (глава 4) прекрасно описывают поведение нескольких объектов в одном прецеденте, а диаграммы деятельности UMLхороши для показа основной последовательности действий нескольких объектов в нескольких прецедентах.

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

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

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

Ооп и последовательность построения диаграмм

Прочитав материал этой лекции, нетерпеливый читатель скажет: “Это ведь все элементарно!”. Да, это правда, простые задачи решаются с помощью UML без особого труда. А вот более сложные системы, прочитав только эту лекцию, возможно, так же адекватно смоделировать не удастся.

Естественно, читать об UML недостаточно – надо им пользоваться! Может быть, даже сразу вы чего-то и не поймете, но по мере увеличения опыта использования UML вы все лучше начнете понимать его конструкции.

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

И еще одно – никогда не выбрасывайте даже “забракованные” диаграммы: они могут в дальнейшем оказаться полезными при анализе направления вашей мысли, поиске ошибок проектирования, да и просто для экспериментов по незначительному изменению системы.

Диаграммы, как уже говорилось выше, можно и нужно строить в некоторой логической последовательности. Но как выработать эту последовательность, если у вас нет опыта моделирования? Как научиться этому? Вот несколько простых приемов, которые помогут вам (или вашей команде) выработать свой стиль проектирования.

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

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

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

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

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

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

И напоследок еще несколько советов относительно использования UML.

Хорошее и полезное упражнение – строить модели классов и отношений между ними для уже написанного вами кода на С или Java.

Применяйте UML для того, чтобы прояснить неявные детали реализации существующей системы или использованные в ней “хитрые механизмы программирования”.

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

Обратите особое внимание на средства UML для моделирования компонентов, параллельности, распределенности, паттернов проектирования. Большинство из этих вопросов мы рассмотрим далее.

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

Кроме прочего, важным моментом здесь является выбор пакета UML-моделирования (CASE-средства), что тоже может повлиять на ваш индивидуальный стиль проектирования. Более подробно мы поговорим об этом в одной из последующих лекций, пока же отметим, что все диаграммы, виденные вами в этой лекции, построены с помощью TAU G2 от Telelogic.

Состояния активности в диаграмме состояний

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

Состояние Searching (Поиск) на рис. 10.3 является таким состоянием активности (activity state): ведущаяся активность обозначается символом do/; отсюда термин do-activity(проявлять активность). После того как поиск завершен, выполняются переходы без активности, например показ нового оборудования (Display New Hardware). Если в процессе активности происходит событие отмены (cancel), то do-активность просто прерывается и мы возвращаемся в состояние Update Hardware Window (Обновление окна оборудования).
Диаграмма состояний UML - состояние с активностью

И do-активности, и обычные активности представляют проявление некоторого поведения. Решающее различие между ними заключается в том, что обычные активности происходят «мгновенно» и не могут быть прерваны обычными событиями, тогда как do-активности могут выполняться в течение некоторого ограниченного времени и могут прерываться, как показано на рис. 10.3.

В UML 1 обычные активности обозначались термином action (действие), а термин activity (активность) применялся только для do-активностей.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *