Уважаемые коллеги, друзья.

Многие из вас знают, что я преподаю в университете. В том числе и структурные методы анализа и проектирования. Среди них встречается (пока) и IDEF0. IDEF0 достаточно прост. Есть неплохая книга деМарко. И все равно возникают разные проблемы с выбором и интерпретации модели. Особенно в дискуссиях со студентами, которые настолько горячие порой бывают, что они пишут некоторую неправду, например в prepodam.net

Казалось чего проще:
прямоугольник - функциональный блок, символизирующий деятельность, процесс, операцию или действие;
3 вида входа - 1 просто вход (то, что является материалом изменения в блоке), управление (то, что регламентирует работу по изменению входа), механизм (то, с помощью чего производится изменение входа)
выход - результат преобразования.
Входами чаще всего являются материальные и информационные объекты.

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

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

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

Есть более изощренные моменты:
контекст: абонемент библиотеки
- вход: читательский билет
- выход: электронный формуляр читателя
- процесс: идентификация читателя

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

вопрос: читательский билет преобразуется в ходе идентификации в формуляр читателя
ответ: ну в общем, так и есть

внимание далее:
- вход: электронный формуляр читателя
- выход: формуляр читателя с отметкой о сдаче
- процесс: списание книги с формуляра читателя

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

Внимание вопрос к аудитории: Скажите, пожалуйста, а как вы объясняете, производите обзор и рецензию в подобных случаях? Какие правила и проверки вы используете? Спасибо

Ну привет, приехали...
Проблема в том, что "писатели" моделей многого не знают, и не понимают многого. Возможно, их просто плохо учили :о)) Nothing personal only business))) А может им просто до фонаря.
Очевидно, что они (подобные студенты) не знают / не понимают:
 - что такое "функция"
 - какие виды информации (данных) используются, как они используются / преобразуются в информационные объекты
 - что такое состояние, в т.ч. состояние информационных объектов
 - какие операции могут выполняться с информационными объектами (их можно назвать в ОО стиле - методами обработки), как меняющие состояния объектов, так и порождающие из одних объектов другие.
(кстати, эти преобразования - одна из самых сложных тем, потому что здесь очень большая вариативность возможна)
ну и так далее (навскидку вспомнил далеко не все)

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

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

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

Спасибо, Водолей.

Алгоритм есть. Он описан в книге деМарко, книгах Эдварда Йордана, в методических материалах, дается на лекциях.
Он достаточно прост (пропуская правила декомпозиции, только касаясь конкретного блока):
- дайте название блоку в формате Глагол (отглагольное существительное) дополнение (чаще всего основной выход блока)
- определите выходы блока
- определите управляющие входы
- определите входы (стараясь понять какой вход нужен для получения выхода)
- определите механизмы
- прочитайте всю полученную картинку (блок под Управлением преобразует Вход в Выход, используя Механизм)

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

Вот скажи, плиз, моделируем магазин.
Функция: Продать товар
Выход: проданный товар, чек
Вход: деньги
Управление: цена, политика скидок, правила продажи
Механизм: Кассир, Покупатель, POS-система

Что тут правильно или не правильно?

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

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

3. Следуя логике "клиента и белья", на модели непонятно откуда взялся товар (который оказался проданным) :о)))
Здесь может быть применена известная формула тов.К.Г.Маркса "товар-деньги-товар", например, на момент получения денег на вход товар вполне может быть на складе продавца (но может и не быть - вспоминаем схему работы наших интернет-магазинов :о))))
Хотя я бы деньги на входе заменил на какую-нибудь заявку, а проданный товар на выходе - на чек на проданный товар. Но это существенно зависит от точки зрения. Да и границы системы было бы неплохо определить...

За что я тебя люблю, Водолеюшка, так это за твои ясные обтекаемые ответы

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

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

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

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

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

3. Следуя логике "клиента и белья", на модели непонятно откуда взялся товар (который оказался проданным) :о)))
Здесь может быть применена известная формула тов.К.Г.Маркса "товар-деньги-товар", например, на момент получения денег на вход товар вполне может быть на складе продавца (но может и не быть - вспоминаем схему работы наших интернет-магазинов :о))))
Хотя я бы деньги на входе заменил на какую-нибудь заявку, а проданный товар на выходе - на чек на проданный товар. Но это существенно зависит от точки зрения. Да и границы системы было бы неплохо определить...

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

Если я не прав, то как правильно?

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

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

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

ну да, возмещение ущерба - процесс, запускаемый претензией. все остальное в обсуждаемом контексте несущественно...

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

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

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

Что значит не надо перескакивать.
Кто-то - автор - моделирует систему. Он отображает материальный поток и информационный поток. Естественно одно другое не заменяет. Ясно, что информационный поток сопровождает материальный. Ясно, что если мы говорим о требованиях к информационной системе, мы рассуждаем о информационных потоках.

Однако вопрос был: как вы объясняете (своим студентам, своим сотрудникам, своим оппонентам). Каковы правила?

Ты вот высказал: не прописано как выбирать выход, вход, управление.

Ну вот скажи!
Может ли, к примеру, входящий в блок Принять книгу поток Книга оседать в этом блоке и не иметь выхода, кроме пометки о сдаче в формуляре? Если выходящим должен быть "принятая (сданная) книга", то должна ли она выходить из системы, если мы рассматриваем границы абонемента библиотеки?
Если мы рассматриваем модель с точки зрения библиотекаря абонемента, может ли быть механизмом сам библиотекарь-абонемента?

В принципе "дезинтеграция" материальных объектов нормальна, в сетях Петри, вернее их расширении Е-сети, существует типичная конструкция - Аккумулятор, роль которого гасить выходящие из системы заявки-метки, если ты понимаешь о чем я толкую. Но будет ли это частью работы абонемента? Т.е. на входе книга - на выходе только информация (при сдаче) и на входе информация - на выходе книга (при выдаче). Правда я бы вообще не разделял эти две операции. Я бы назвал их Прием/выдача книг. И у меня было управление (а может механизм) Фонд библиотеки...

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

Согласен - это одно из самых сложных моментов, но и это момент логических построений...
А какие у тебя подходы? Как ты это делаешь? Обращаюсь к тебе (других видимо нет

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

потом надо описать систему словами в виде простых предложений, это чем-то похоже на user story (а может user story и есть). это позволит определить границы системы. из предложений выделяем действия = глаголы и сущности = существительные. если говорить в терминах idef0, то сущности - это стрелки, действия - они активити и есть. важно составив подобным образом словарь системы не выходить за его рамки, иначе придется пересматривать границы. можно отсортировать сущности по принципу "глубины"
дополнительно я обычно для каждой сущности определяю в ОО стиле, что с ней можно вообще делать с точки зрения того, от чей т.зр. составляется модель: что с книгой (сдать/принять, проверить, положить на полку, выдать), что с формуляром (заполнить? что еще?), и т.п., но это в явном виде в стандартной методике вроде отсутствует. мне так легче рассматривать сущности, в конце концов они чаще всего имеют вполне ясное и понятное отражение в реальном мире.

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

тут будут уместны твои вопросы

1. Может ли, к примеру, входящий в блок Принять книгу поток Книга оседать в этом блоке и не иметь выхода, кроме пометки о сдаче в формуляре?
2. Если выходящим должен быть "принятая (сданная) книга", то должна ли она выходить из системы, если мы рассматриваем границы абонемента библиотеки?
3. Если мы рассматриваем модель с точки зрения библиотекаря абонемента, может ли быть механизмом сам библиотекарь-абонемента?

попробую ответить:
1. А что с книгой-то происходит? С самой книгой ничего, она физически перемещается из рук читателя, через несколько других рук, на свое место на полочке, которое указывает библиотечный каталог. В принципе при некоторых ракурсах рассмотрения можно отражать во входах/выходах разные состояния книги: книга, полученная от читателя, книга на столе регистратора, книга на полке.
С формуляром IMHO проще - это вторая цепочка (потому что формуляр это информационная карточка книги (в определенном смысле). Когда книга на руках, он где лежит? Когда книгу сдают, что с формуляром происходит? Когда книгу на полку кладут, куда формуляр девается? и т.п.
Тут либо книга и формуляр всегда вместе "путешествуют", либо по-разному...
2. Почему выходом должна быть книга-то? Или мы рассматриваем в качестве системы операцию сдачи/приемки? Если нет, то вообще говоря, выходов может быть много и разных, отчетность какая-нибудь с анализом востребованности литературы, например... Короче говоря, надо на задачу смотреть (цель какая? границы какие? - не могу сказать, что сейчас внятно понимаю термин "границы абонемента библиотеки" )
3. ну а почему нет. если хочешь, назови его "я - библиотекарь абонемента".

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

последний этап - проверка. нужно попытатся "прокрутить" систему: дали что-то нужное на вход, что и как будет при этом входе.

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

других видимо нет

другие не занимаются такой ерундой - они моделируют сразу на UML

другие не занимаются такой ерундой - они моделируют сразу на UML

А ты резок, как я посмотрю. Назови мне в UML альтернативу IDEF0, т.е. что обладает относительной простотой изображения и возможность легко и просто использовать функциональную декомпозицию. Что дает возможность оторваться от структурных моментов и сосредоточиться на назначении? К тому же в ГОСе это прописано, мы вынуждены знакомить с этим студентов.

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

мы это делаем, тем же примерно способом.

потом надо описать систему словами в виде простых предложений, это чем-то похоже на user story (а может user story и есть). это позволит определить границы системы. из предложений выделяем действия = глаголы и сущности = существительные. если говорить в терминах idef0, то сущности - это стрелки, действия - они активити и есть. важно составив подобным образом словарь системы не выходить за его рамки, иначе придется пересматривать границы. можно отсортировать сущности по принципу "глубины"
дополнительно я обычно для каждой сущности определяю в ОО стиле, что с ней можно вообще делать с точки зрения того, от чей т.зр.

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

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

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

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

Как ты определяешь (какие критерии) что две функции одинаковы/различны по нагрузке?

тут будут уместны твои вопросыпопробую ответить:
1. А что с книгой-то происходит? С самой книгой ничего, она физически перемещается из рук читателя, через несколько других рук, на свое место на полочке, которое указывает библиотечный каталог. В принципе при некоторых ракурсах рассмотрения можно отражать во входах/выходах разные состояния книги: книга, полученная от читателя, книга на столе регистратора, книга на полке.
С формуляром IMHO проще - это вторая цепочка (потому что формуляр это информационная карточка книги (в определенном смысле). Когда книга на руках, он где лежит? Когда книгу сдают, что с формуляром происходит? Когда книгу на полку кладут, куда формуляр девается? и т.п.

Да согласен может и так. Что исключить книгу из рассмотрения?

2. Почему выходом должна быть книга-то? Или мы рассматриваем в качестве системы операцию сдачи/приемки? Если нет, то вообще говоря, выходов может быть много и разных, отчетность какая-нибудь с анализом востребованности литературы, например... Короче говоря, надо на задачу смотреть (цель какая? границы какие? - не могу сказать, что сейчас внятно понимаю термин "границы абонемента библиотеки" )

именно ее и рассматриваем. абонемент библиотеке - место где читатели берут и сдают книги.

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

не могу сказать, что понял посыл данной фразы. повтори плиз?

последний этап - проверка. нужно попытатся "прокрутить" систему: дали что-то нужное на вход, что и как будет при этом входе.

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

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

понятно, что пример вырван из контекста. точка зрения библиотекаря абонемента. границы системы  - именно абонемент библиотеки

границы абонемента библиотеки

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

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

Друзья, спасибо за интерес к теме. Толкьо дискуссия пошли не в том русле.

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

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

Вот типичный сценарий, наблюдаемый мною в нашей библиотеке. Он естественно может идти с множеством вариаций

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

Вот скажи, плиз, моделируем магазин.
Функция: Продать товар
Выход: проданный товар, чек
Вход: деньги
Управление: цена, политика скидок, правила продажи
Механизм: Кассир, Покупатель, POS-система

Что тут правильно или не правильно?

По собственному опыту могу сказать, что объекты не должны появляться без действий и исчезать бесследно.
В данном случае:
1. Входными данными является также "Корзина". Имеется в виду корзина набранных покупателем товаров.
2. В выходные данные добавить "Чек", "Непроданный товар", также можно добавить информационные составляющие "Копия чек в pos-терминале".

По собственному опыту могу сказать, что объекты не должны появляться без действий и исчезать бесследно.
В данном случае:
1. Входными данными является также "Корзина". Имеется в виду корзина набранных покупателем товаров.
2. В выходные данные добавить "Чек", "Непроданный товар", также можно добавить информационные составляющие "Копия чек в pos-терминале".

Отлично! Обратите внимание чек в оригинале есть. Задача заведома содержала ошибку, по товарам мы согласовали потоки, а по деньгам? Деньги аккумулируются в блоке? Во что они должны трансформироваться?
Достаточно ли нам данных для формирования чека? Откуда следует брать по-вашему эти данные?