61
UML SysML и пр. / Re: Шутки и UML
« : 31 Декабря 2021, 15:09:49 »
Удачи всем в наступающем 2022-м!
Пусть сбываются Ваши планы!
Пусть будут успешны Ваши проекты!
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
Удачи всем в наступающем 2022-м!
Пусть сбываются Ваши планы!
Пусть будут успешны Ваши проекты!
62
UML SysML и пр. / Re: "Плавательные дорожки" на диаграмме коммуникации
« : 21 Ноября 2021, 17:44:17 »Вы уже где-то попробовали?Это можно проделать только на листе бумажки или в рисовалке вроде Visio. Мы -- заложники производителей UMLьных инструментов. Как они сделают, так мы и сможем рисовать. Вот в VP решили, что плавательные дорожки на диаграммах коммуникации -- это гуд. И, не моргнув глазом, сделали их там. При этом VP заявляет, что поддерживает стандарт.
63
Примеры / Re: Use case диаграмма снятия денег в банкомате
« : 21 Ноября 2021, 17:04:31 »Это все Thinkler, он отрезал.К слову во многих учебниках сделано также -- банк либо забыт и отрезан от банкомата, либо включён в рамки системы.
64
UML SysML и пр. / "Плавательные дорожки" на диаграмме коммуникации
« : 06 Октября 2021, 18:09:32 »
На сайте Visual Paradigm встретилась замечательная диаграмма:
См.: https://www.visual-paradigm.com/VPGallery/diagrams/Collaboration.html
Замечательна она тем, что авторами VP swimlane-ы, придуманные задолго до UML и взятые в UML почему-то только для диаграмм деятельности, органично вплетены в стандартную нотацию. Залезание в текст стандарта подтверждает ожидания. Это не стандартная нотация. Swimlane-ам место лишь на диаграммах деятельности.
Но что если копнуть глубже и посмотреть, что стандарт не запрещает рисовать на диаграммах коммуникации. И тут нас ждёт сюрприз. Вся диаграмма коммуникации по стандарту = дерево с корнем, являющимся Interaction. В привычной диаграмме коммуникации из Interaction растут ветви в сторону его детей -- Lifeline-ов всяческих, Message-ей. Это согласуется с абстрактным синтаксисом. Но этот синтаксис говорит, что дитём Interaction-а вполне может быть InteractionFragment, то есть, и CombinedFragment. Значит, что стандартом не запрещено рисовать непривычные диаграммы коммуникации -- с alt-, loop- или opt- фрагментами. Чего по привычке никто не делает.
Так что, меняем "плавательные дорожки" на комбинированные фрагменты и вперёд!
См.: https://www.visual-paradigm.com/VPGallery/diagrams/Collaboration.html
Замечательна она тем, что авторами VP swimlane-ы, придуманные задолго до UML и взятые в UML почему-то только для диаграмм деятельности, органично вплетены в стандартную нотацию. Залезание в текст стандарта подтверждает ожидания. Это не стандартная нотация. Swimlane-ам место лишь на диаграммах деятельности.
Но что если копнуть глубже и посмотреть, что стандарт не запрещает рисовать на диаграммах коммуникации. И тут нас ждёт сюрприз. Вся диаграмма коммуникации по стандарту = дерево с корнем, являющимся Interaction. В привычной диаграмме коммуникации из Interaction растут ветви в сторону его детей -- Lifeline-ов всяческих, Message-ей. Это согласуется с абстрактным синтаксисом. Но этот синтаксис говорит, что дитём Interaction-а вполне может быть InteractionFragment, то есть, и CombinedFragment. Значит, что стандартом не запрещено рисовать непривычные диаграммы коммуникации -- с alt-, loop- или opt- фрагментами. Чего по привычке никто не делает.
Так что, меняем "плавательные дорожки" на комбинированные фрагменты и вперёд!
65
Примеры / Re: Use case диаграмма снятия денег в банкомате
« : 18 Сентября 2021, 22:59:37 »
Что-то ржу.
Во всех предложенных экспертами заменах исходной диаграммы отрезано действующее лицо "Банк". В этом они хуже исходной диаграммы, т. к. являются ДВИ не банкомата, а деньго-печать-мата.
Во всех предложенных экспертами заменах исходной диаграммы отрезано действующее лицо "Банк". В этом они хуже исходной диаграммы, т. к. являются ДВИ не банкомата, а деньго-печать-мата.
66
Теория моделирования и нотации / Re: UML диаграмма классификации (категоризации)
« : 20 Августа 2021, 13:08:39 »обрастает рядом дополнительных вопросов, например:...Предположительно, можно взять часть метамодели UML, относящуюся к структуре, кроющую классы и экземпляры. Далее отождествить Class с категорией, а InstanceSpecification с объектом. Получившаяся недометамодель UML даст требуемую якобы гибкость в плане неопределённости объектов, категорий и ответов на вопросы. Но манипулировать данными в такой системе будет неудобно.
Идея подсмотрена у Скотта Амблера. Это расширенная его generic schema, которую он описал для ORM.
67
Теория моделирования и нотации / Re: UML диаграмма классификации (категоризации)
« : 16 Августа 2021, 21:46:13 »
Если задачей является создание программной системы, то Вы подбираете фреймворк и доки к нему и пишете код.
Если задачей является "чтобы на UML", то хотя бы себе Вы должны дать ответ. Зачем именно UML и зачем визуальная модель.
Библиотечная классификация специализирована. Ею пользуются библиотечные спецы. Обычные люди [вроде Вас] и марсиане [вроде меня] ею пользуются с грехом пополам. И там почти всё давно придумано, а специальные институты патчат и дополняют при необходимости. Книга издаётся с метаданными -- готовой пачкой сведений для классификации. Я давно видел библиотекарей, но и тогда они не производили впечатление людей, которые читают книги для выполнения своих библиотекарских обязанностей.
Бутерброды, в принципе, тоже бывают размечены. В самолётной классификации "курицалилирыба" на лоток с питанием может быть наклеен цветной ярлык.
Какие ярлыки на Ваших объектах-записях? Если известно лишь то, что "структура этих объектов-записей довольно простая" и больше нечего сказать, то модель будет тривиальной (не содержательной), и набросать UML-диаграмму не будет никакой возможности (из-за отсутствия сведений). На контрпример, диаграмм про книги Вы на тутошнем форуме можете найти несколько штук.
У Борхеса есть такая классификация:
животные делятся на:
а) принадлежащих императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
Даже на таком шатком основании можно что-то построить.
Но не на облаке.
Если задачей является "чтобы на UML", то хотя бы себе Вы должны дать ответ. Зачем именно UML и зачем визуальная модель.
Библиотечная классификация специализирована. Ею пользуются библиотечные спецы. Обычные люди [вроде Вас] и марсиане [вроде меня] ею пользуются с грехом пополам. И там почти всё давно придумано, а специальные институты патчат и дополняют при необходимости. Книга издаётся с метаданными -- готовой пачкой сведений для классификации. Я давно видел библиотекарей, но и тогда они не производили впечатление людей, которые читают книги для выполнения своих библиотекарских обязанностей.
Бутерброды, в принципе, тоже бывают размечены. В самолётной классификации "курицалилирыба" на лоток с питанием может быть наклеен цветной ярлык.
Какие ярлыки на Ваших объектах-записях? Если известно лишь то, что "структура этих объектов-записей довольно простая" и больше нечего сказать, то модель будет тривиальной (не содержательной), и набросать UML-диаграмму не будет никакой возможности (из-за отсутствия сведений). На контрпример, диаграмм про книги Вы на тутошнем форуме можете найти несколько штук.
У Борхеса есть такая классификация:
животные делятся на:
а) принадлежащих императору,
б) набальзамированных,
в) прирученных,
г) молочных поросят,
д) сирен,
е) сказочных,
ж) бродячих собак,
з) включённых в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей шерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
Даже на таком шатком основании можно что-то построить.
Но не на облаке.
68
Теория моделирования и нотации / Re: UML диаграмма классификации (категоризации)
« : 16 Августа 2021, 17:35:39 »
К теории моделирования и нотациям Ваш вопрос не имеет отношения, насколько я могу судить.
Если речь идёт о полученном Вами задании, то выполните его сами или обратитесь на фриланс-сайт.
Затруднительно понять из Вашего сообщения, что за задача перед Вами стоит, с какой целью Вы ею занимаетесь, при чём тут UML.
Библиотечная классификация -- специализированная вещь, отличающаяся от обобщённой классификации "объектов по каким-либо категориям". Так, на книге есть шифры -- ББК и всякие там ISBNы. Просто глядя на них Вы получаете ответ на вопрос: "содержится" ли книга в категории "Приключения". На книге есть значок ограничения по возрасту (если она издана после вступления в силу соответствующих законов). Глядя на них Вы узнаете, относится ли книга к категории "Детям до 12 лет". На книге есть дата выпуска тиража. По нему Вы получите ответ про "Период публикации".
Но если Ваша система категоризует/классифицирует бутерброды, то, просто взглянув на бутерброд, вряд ли можно определённо ответить:
относится ли он к категории "Приключения"?
предназначен ли он детям до 12 лет и годится ли для детей постарше?
Поверить, что Вам необходимо по-взрослому создать библиотечную систему, у меня не получается, т. к. полным полно готовых решений.
Если речь идёт о полученном Вами задании, то выполните его сами или обратитесь на фриланс-сайт.
Затруднительно понять из Вашего сообщения, что за задача перед Вами стоит, с какой целью Вы ею занимаетесь, при чём тут UML.
Библиотечная классификация -- специализированная вещь, отличающаяся от обобщённой классификации "объектов по каким-либо категориям". Так, на книге есть шифры -- ББК и всякие там ISBNы. Просто глядя на них Вы получаете ответ на вопрос: "содержится" ли книга в категории "Приключения". На книге есть значок ограничения по возрасту (если она издана после вступления в силу соответствующих законов). Глядя на них Вы узнаете, относится ли книга к категории "Детям до 12 лет". На книге есть дата выпуска тиража. По нему Вы получите ответ про "Период публикации".
Но если Ваша система категоризует/классифицирует бутерброды, то, просто взглянув на бутерброд, вряд ли можно определённо ответить:
относится ли он к категории "Приключения"?
предназначен ли он детям до 12 лет и годится ли для детей постарше?
Поверить, что Вам необходимо по-взрослому создать библиотечную систему, у меня не получается, т. к. полным полно готовых решений.
69
UML SysML и пр. / Re: UML Best Practice: "На диаграммах деятельности не рисуйте деятельности"
« : 28 Июля 2021, 17:19:10 »Но если у узла нету пина, то остается неопределенным, чему равен признак isSynchronous этого узла.Приплету, что по стандарту дефолтное значение isSynchronous = true. Из экономии мы можем полагать, что диаграмма без явных указаний чего-либо про isSynchronous означает, что значение дефолтное. Тогда неопределённое значение нашим усилием приравнивается к дефолтному.
А вообще, есть какие-нибудь средства (нотации) моделирования, которые позволяют графически наглядно показать асинхронные вызовы?
Стандарт не содержит примеров явного указания isSynchronous. Поэтому кочку опоры придётся придумать самим. Например, известно, что класс, которому отказано в праве на переопределение в потомке метится isLeaf=true. Известно, что стандарт не даёт примера конкретного синтаксиса. Поэтому народ рисует так:
Вот и мы можем писать что-то вроде {asynchronous}.
Тут надо заметить, что тот же isLeaf=true для State стандарт позволяет рисовать кейвордом {final} после называния состояния. Это чтобы с final state-ом перепутывать что ли?
В сторону можно заметить, что несчастный класс должен помимо isLeaf ещё размечаться isFinalSpecialization. То есть почва зыбкая, даже авторы стандарта "плывут".
И надо запастись поп-корном и сесть ждать когда наконец будет нормальное описание не только абстрактного синтаксиса UML, но и конкретного синтаксиса тоже.
70
UML SysML и пр. / Re: UML Best Practice: "На диаграммах деятельности не рисуйте деятельности"
« : 19 Июля 2021, 04:25:01 »Запуски могут быть синхронными и асинхронными.Графических средств для этого почти нет. Можно приклеить уродливый коммент с явным выписыванием isSynchronous=true или isSynchronous=false.
На этой диаграмме это как-то отражается какими-нибудь специальными символами?
"Почти нет", т. к. есть один финт.
На фрагменте а) видим узел действия вызова деятельности. И у этого узла видим выходящий пин. По стандарту узлу с isSynchronous=false запрещено иметь такие пины. Значит, этот узел с isSynchronous=true.
Можете показать пример такого "соединения" деятельностей?На практике такое вряд ли кто нарисует. Это всё равно, что две диаграммы вместе слитно нарисовать.
Берём иллюстрацию из стандарта. Рядом справа рисуем деятельность разбирающую компы обратно на части. Заводим ей входной параметр Assembled Comps. Соединяем стрелкой-потоком один из выходных параметров первой деятельности со входным параметров второй.
И можете пожалуйста объяснить, чем по определению деятельность отличается от действия?Деятельность -- это конструкция из кирпичиков, каждый из которых атомарен (элементарен, не раскладывается на части). Кирпичики принято называть узлами. Один из видов узлов -- узлы действия. Т. е. деятельность собирается из действий. А действие ни из чего не собирается. Оно целёхонькое и прочное -- его на куски не расколотить.
71
UML SysML и пр. / UML Best Practice: "На диаграммах деятельности не рисуйте деятельности"
« : 08 Июля 2021, 02:19:20 »
Наткнулось на заметку Geert Bellekens "UML Best Practice: There are no Activities on an Activity Diagram"
Подумало, как клёво, что в 2012-м людям в Бельгии всё уже было ясно.
Стало смотреть диаграммы [глазом из нынешнего 2021го]. Ротовые щупальца встали дыбом.
Чел из Бельгии рисует такое и пишет, что одноимённые узлы (он называет их "деятельностями") это ужас-ужас.
Но потом избавляет нас от ужаса, делая их узлами действия вызова одной и той же деятельности:
Ну, вот, щупальца улеглись, можно продолжать разговор.
По стандарту прямоугольничек со скруглёнными углами, из которого выходит (или в который входит) стрелочка-поток мы не можем прочесть как Activity. Втыкай в эту прямоугольную "картофелину" вилку, вытыкай назад, это никак на стандартное прочтение не повлияет. Потому что, по-любому, это узел действия, т. е. Action. С вилкой Action становится узлом действия специального вида, у которого длинное название: узел действия вызова деятельности. Ну, т. е., действие состоит в том, что запускается некая Activity.
Воткнув вилки и добавив двоеточия бельгиец не избавился от дублирования (глазом это видно). Два раза нарисовано одно и то же. Изменилось лишь одно. Без вилок это были два OpaqueAction или два CallBehaviourAction, что говорило нам о невыразимости средствами UMLя сути хреновины по имени "Process Payment". С вилками мы утверждаем, что кто-то может нарисовать отдельную диаграмму деятельности, где будут видны внутренности "Process Payment".
Может ли на диаграмме деятельности присутствовать деятельность? Может, конечно. Обычно, при этом она выгладит как прямоугольная со скруглёнными углами рамка, внутри которой находится всё содержимое диаграммы. Если заморочиться, то можно нарисовать две такие "диаграммы в рамочках" рядом. Потом можно захотеть их соединить. Стандарт запрещает это делать напрямую. Каждая деятельность сначала должна будет вырастить на своей границе объектный узел специального вида -- параметр. И вот эти выращенные параметры (output с input) можно будет соединить стрелкой-потоком.
Подумало, как клёво, что в 2012-м людям в Бельгии всё уже было ясно.
Стало смотреть диаграммы [глазом из нынешнего 2021го]. Ротовые щупальца встали дыбом.
Чел из Бельгии рисует такое и пишет, что одноимённые узлы (он называет их "деятельностями") это ужас-ужас.
Но потом избавляет нас от ужаса, делая их узлами действия вызова одной и той же деятельности:
Ну, вот, щупальца улеглись, можно продолжать разговор.
По стандарту прямоугольничек со скруглёнными углами, из которого выходит (или в который входит) стрелочка-поток мы не можем прочесть как Activity. Втыкай в эту прямоугольную "картофелину" вилку, вытыкай назад, это никак на стандартное прочтение не повлияет. Потому что, по-любому, это узел действия, т. е. Action. С вилкой Action становится узлом действия специального вида, у которого длинное название: узел действия вызова деятельности. Ну, т. е., действие состоит в том, что запускается некая Activity.
Воткнув вилки и добавив двоеточия бельгиец не избавился от дублирования (глазом это видно). Два раза нарисовано одно и то же. Изменилось лишь одно. Без вилок это были два OpaqueAction или два CallBehaviourAction, что говорило нам о невыразимости средствами UMLя сути хреновины по имени "Process Payment". С вилками мы утверждаем, что кто-то может нарисовать отдельную диаграмму деятельности, где будут видны внутренности "Process Payment".
Может ли на диаграмме деятельности присутствовать деятельность? Может, конечно. Обычно, при этом она выгладит как прямоугольная со скруглёнными углами рамка, внутри которой находится всё содержимое диаграммы. Если заморочиться, то можно нарисовать две такие "диаграммы в рамочках" рядом. Потом можно захотеть их соединить. Стандарт запрещает это делать напрямую. Каждая деятельность сначала должна будет вырастить на своей границе объектный узел специального вида -- параметр. И вот эти выращенные параметры (output с input) можно будет соединить стрелкой-потоком.
72
RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...
« : 19 Июня 2021, 14:37:24 »
"Приключения в ресторане" продолжаются.
Некто поместил в википедию свою версию диаграммы ВИ ресторана. Далее её стали использовать в куче мест. (К слову в самой вики пытаются эту диаграмму читать и как BUC, игноря предупреждения by Kirill Fakhroutdinov с красными человечками, приведённые выше). Например, её использовали создатели рисовалки, не умеющей пунктирные стрелки. Так появилась испорченная версия со сплошными экстендами. Дальше больше. Испорченную версию ещё больше испортила авторка из Томска и поместила в придуманный ею тест на знание UML. Верхний сплошной экстенд стал сплошным инклюдом (отражая, по мнению авторки из Томска, "Неконсистентность связей между прецедентами с вином и едой: include указывает на то, что заказ вина возможен ТОЛЬКО при заказе еды"). Однозначно ошибочным является только нарушение нотации (непунктирные стрелки расширений и включения). Вероятно ошибочным -- направление инклюда. Замороченность тем, что с чем заказывать, выпивку к закуске или закуску к выпивке, ВИ-диаграмма не в силах прояснить, тут необходимо читать тексты сценариев.
Некто поместил в википедию свою версию диаграммы ВИ ресторана. Далее её стали использовать в куче мест. (К слову в самой вики пытаются эту диаграмму читать и как BUC, игноря предупреждения by Kirill Fakhroutdinov с красными человечками, приведённые выше). Например, её использовали создатели рисовалки, не умеющей пунктирные стрелки. Так появилась испорченная версия со сплошными экстендами. Дальше больше. Испорченную версию ещё больше испортила авторка из Томска и поместила в придуманный ею тест на знание UML. Верхний сплошной экстенд стал сплошным инклюдом (отражая, по мнению авторки из Томска, "Неконсистентность связей между прецедентами с вином и едой: include указывает на то, что заказ вина возможен ТОЛЬКО при заказе еды"). Однозначно ошибочным является только нарушение нотации (непунктирные стрелки расширений и включения). Вероятно ошибочным -- направление инклюда. Замороченность тем, что с чем заказывать, выпивку к закуске или закуску к выпивке, ВИ-диаграмма не в силах прояснить, тут необходимо читать тексты сценариев.
73
Теория моделирования и нотации / Re: Самая удобная нотация и инструмент моделирования для проектирования БД
« : 17 Июня 2021, 20:54:06 »А я имел ввиду, что у самой связи (то есть у линии, связывающей две сущности) нету информации о ключах (столбцах), по которым осуществляется эта связь.После уточнения прояснилось, в чём именно видится дефект. Чтобы отразить эти сведения, можно допилить профиль и переложить эти tagged values в стереотипы для связей.
Ну в общем, как-то мне не очень эта идея.
В копилку "не очень идей": рисовать в Visual Paradigm и моделировать категоризацию тем способом, который предложен разрабами VP. Красивые картинки a la IDEF1X получать экспортируя диаграммы в "рисовалки" вроде Visio, где явно пририсовывать категоризацию. Не думаю, что стоит так мучиться, но ничего другого не могу предложить.
74
Теория моделирования и нотации / Re: Самая удобная нотация и инструмент моделирования для проектирования БД
« : 15 Июня 2021, 22:57:29 »Здесь в отношениях нету информации о ключах и полях, с помощью которых "реализуется" эта связь.[в продолжение трындежа]
У Амблера для этого предусмотрены метасвойства/tagged values у столбцов, помеченных как внешние ключи (<<FK>>).
75
Теория моделирования и нотации / Re: Самая удобная нотация и инструмент моделирования для проектирования БД
« : 15 Июня 2021, 15:49:53 »
[Вероятно, имеются в виду реляционные БД.]
[Далее следует порция трындежа, который худо-бедно связан с заданными вопросами, но не даёт на них ответа.]
Инструмент (программу) можно подбирать под задачу. Например, чтобы она из имеющихся DDLей сама рисовала что-то удобоваримое, а после перерисовывания генерила новые версии DDL, и чем, чёрт не шутит, помогала рефакторить содержимое БД. Как следствие, такие полезные свойства инструмента могут помочь смириться с несовершенством поддерживаемой нотации.
Можно ставить в вершину угла выразительные возможности нотации (и, как следствие, мириться с несовершенством инструмента, который её поддерживает).
У нотации полно других свойств, которые могут быть важны (и даже быть важнее выразительных возможностей). Например, если нотация привычна Вашим коллегам, то они с бОльшим энтузиазмом воспримут Ваши диаграммы.
[Тут трындёж как бы заканчивается.]
Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.
[Далее следует порция трындежа, который худо-бедно связан с заданными вопросами, но не даёт на них ответа.]
Инструмент (программу) можно подбирать под задачу. Например, чтобы она из имеющихся DDLей сама рисовала что-то удобоваримое, а после перерисовывания генерила новые версии DDL, и чем, чёрт не шутит, помогала рефакторить содержимое БД. Как следствие, такие полезные свойства инструмента могут помочь смириться с несовершенством поддерживаемой нотации.
Можно ставить в вершину угла выразительные возможности нотации (и, как следствие, мириться с несовершенством инструмента, который её поддерживает).
У нотации полно других свойств, которые могут быть важны (и даже быть важнее выразительных возможностей). Например, если нотация привычна Вашим коллегам, то они с бОльшим энтузиазмом воспримут Ваши диаграммы.
[Тут трындёж как бы заканчивается.]
Мне привычен UML. К нему есть профиль, предложенный на сайте Скотта Амблера. С помощью этого профиля можно приспособить стандартную UML-диаграмму классов к моделированию схемы реляционной БД. Амблер не приводит пример с категоризацией, но в актуальной версии UML есть такие штуки как Generalization Set с Power Type-ами. Это позволяет наUMLылить что-то похожее на IDEF1X-ные categorization-отношения.
Недостатков такого решения прорва:
- инструмент для перевода с/в DDL в/с UML почти наверняка не существует;
- приспособленные UML-диаграммы классов не привычны разработчикам БД, они откажутся их читать;
- пляски с Generalization Set и Power Type-ами лишь отдалённо напоминают то, что было в IDFE1X.