196
О Сайте и Форуме / Re: Просмотр форума на мобильных устройствах
« : 19 Августа 2018, 10:48:23 »
Ссылка работает лучше.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Страницы: « 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 »
197
Методологии / Re: По методологии DDD температура воздуха и метеоэлемент чем является сущностью?
« : 07 Августа 2018, 21:28:27 »
Гм. Можно зайти с другой стороны. "Сводка" -- это объединение нескольких значений различных параметров погоды, заносимых одновременно. Значение относится к моменту времени и географической точке. Значение либо замеренное, либо прогнозируемое. У значения есть число, единица измерения и параметр погоды, который был замерен или предсказан. Если набор параметров фиксирован, то получается набор классов по 1 на каждый: ТемператураВоздуха, АтмосферноеДавление, Влажность, ... . Если набор не фиксирован, то можно обойтись 1 классом. Вывод "сводки" -- поиск подходящего объекта среди значений нужных параметров погоды.
198
Методологии / Re: По методологии DDD температура воздуха и метеоэлемент чем является сущностью?
« : 07 Августа 2018, 00:05:07 »
Здравствуйте.
Предыдущее моё сообщение лучше читать в том смысле, что предлагая диаграммы как сырьё для построения ответа на Ваш вопрос, Вы скорее всего получите мало полезные Вам комменты о том, что исходных данных маловато. Затруднительно найти ошибки (или способы улучшения) диаграммы, используя её саму как единственный источник сведений о разрабатываемой модели.
DDD говорит о классе для объектов-сущностей и классе для объектов-значений как о разных типах классов. К Вашим вопросам о том, какие данные в одном классе, какие в другом, сколько и каких классов нужно, это DDD-рассмотрение напрямую не относится. Например, в книжке Эванса "Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем" (вероятно, Вы используете её) на рис. 5.6 Customer -- "сущность", Address -- "значение". Это два разных класса и две (как минимум, в рамках обычных стратегий ORM) разные таблицы.
В связи с этим, хочется ясности, какой вопрос стоит перед Вами? 1) "Построить модель которая максимально была бы приближена к будущей БД" или 2) Разобрать на примере отличия между "сущностями" и "значениями"?
В Вашем ответе появились пояснения. Они немного приподымают занавес над тем, что такое "хранить полученные данные" и "показать какая сегодня погода". Но немного. Для того, чтобы судить о "лишнем обновлении данных всех таблиц" нужен глоссарий ПрО, нужны сценарии. Например, глоссарий (пояснение терминов ПрО и их взаимосвязей) дали бы понять в каком смысле "метеоэлемент" является частью "погоды".
Кажется странным с самого начала озаботиться эффективностью обновлений и схожестью модели классов со схемой будущей БД. Обычно в начале строят простой эскиз, кроющий базовую функциональность, а потом перерабатывают его с учётом вопросов хранения и эффективности.
Дополнительный туман сгущается из-за использования Вами нотации. Ромбики были (и не разрешали двум Погодам иметь общий Метеоэлемент см. "метеоэлементы совпадают"). Теперь ромбиков нету. И надо решать, почему "Метеоэлемент не является отдельным классом" (т. е. в моём прочтении, почему объекты-метеоэлементы у разных погод не могут совпадать).
Вижу, что моё подключение скорее запутывает, а раз так, то спешу улететь.
Кажется, что есть набор "сводок", упорядоченных по дате/времени. У "сводки" есть флажок, является ли она наблюдённым фактом или же прогнозом (замечу, что ожидаемо в прогнозе видеть не точное значение, а диапазон). У "сводки" есть перечень составляющих: t воздуха, t воды, давление, влажность ... . Любой составляющей может не быть. Выводимые сведения о погоде на дату/время дд.мм чч.мм берутся из последней "сводки" из тех, что не позже дд.мм чч.мм, если в ней не все нужные составляющие, то их ищут в предшествующей "сводке" и идут по перечню в сторону против хода времени, пока не соберут все составляющие. Что-то ещё делают со "сводками-прогнозами". Вероятно, когда хотят видеть сведения о погоде, то указывают, что нужно: факт или прогноз.
Такой вот прогноз по увиденному сквозь туман.
Предыдущее моё сообщение лучше читать в том смысле, что предлагая диаграммы как сырьё для построения ответа на Ваш вопрос, Вы скорее всего получите мало полезные Вам комменты о том, что исходных данных маловато. Затруднительно найти ошибки (или способы улучшения) диаграммы, используя её саму как единственный источник сведений о разрабатываемой модели.
DDD говорит о классе для объектов-сущностей и классе для объектов-значений как о разных типах классов. К Вашим вопросам о том, какие данные в одном классе, какие в другом, сколько и каких классов нужно, это DDD-рассмотрение напрямую не относится. Например, в книжке Эванса "Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем" (вероятно, Вы используете её) на рис. 5.6 Customer -- "сущность", Address -- "значение". Это два разных класса и две (как минимум, в рамках обычных стратегий ORM) разные таблицы.
В связи с этим, хочется ясности, какой вопрос стоит перед Вами? 1) "Построить модель которая максимально была бы приближена к будущей БД" или 2) Разобрать на примере отличия между "сущностями" и "значениями"?
В Вашем ответе появились пояснения. Они немного приподымают занавес над тем, что такое "хранить полученные данные" и "показать какая сегодня погода". Но немного. Для того, чтобы судить о "лишнем обновлении данных всех таблиц" нужен глоссарий ПрО, нужны сценарии. Например, глоссарий (пояснение терминов ПрО и их взаимосвязей) дали бы понять в каком смысле "метеоэлемент" является частью "погоды".
Кажется странным с самого начала озаботиться эффективностью обновлений и схожестью модели классов со схемой будущей БД. Обычно в начале строят простой эскиз, кроющий базовую функциональность, а потом перерабатывают его с учётом вопросов хранения и эффективности.
Дополнительный туман сгущается из-за использования Вами нотации. Ромбики были (и не разрешали двум Погодам иметь общий Метеоэлемент см. "метеоэлементы совпадают"). Теперь ромбиков нету. И надо решать, почему "Метеоэлемент не является отдельным классом" (т. е. в моём прочтении, почему объекты-метеоэлементы у разных погод не могут совпадать).
Вижу, что моё подключение скорее запутывает, а раз так, то спешу улететь.
Кажется, что есть набор "сводок", упорядоченных по дате/времени. У "сводки" есть флажок, является ли она наблюдённым фактом или же прогнозом (замечу, что ожидаемо в прогнозе видеть не точное значение, а диапазон). У "сводки" есть перечень составляющих: t воздуха, t воды, давление, влажность ... . Любой составляющей может не быть. Выводимые сведения о погоде на дату/время дд.мм чч.мм берутся из последней "сводки" из тех, что не позже дд.мм чч.мм, если в ней не все нужные составляющие, то их ищут в предшествующей "сводке" и идут по перечню в сторону против хода времени, пока не соберут все составляющие. Что-то ещё делают со "сводками-прогнозами". Вероятно, когда хотят видеть сведения о погоде, то указывают, что нужно: факт или прогноз.
Такой вот прогноз по увиденному сквозь туман.
199
Методологии / Re: По методологии DDD температура воздуха и метеоэлемент чем является сущностью?
« : 01 Августа 2018, 22:17:26 »
Предлагая вопрос, Вы также предлагаете по ключевым словам "погода", "прогноз" догадаться, что именно Вы моделируете. Это может быть трудно или невозможно. Но от точности догадки зависит ответ на Ваш вопрос, если анализировать по смыслу.
Формально, если верить Вашим композициям (анализ по смыслу я не провожу), то Температура не может быть сущностью, т. к. не расшаривается. Аналогично, Метеоэлемент. Поясню. Если в разных экземплярах Метеоэлемента одна и та же температура "Fahrenheit 451", то в Вашей модели это должны быть два разных экземпляра Температуры, равенство которых Вы установите не по тому, что соединения от обоих экземпляров Метеоэлемента идут в одно и то же место. Если бы на диаграмме была надпись {readOnly} перед атрибутом Температуры, это бы ещё больше убеждало, что перед нами объект-значение.
Как непрошенный совет получите рекомендацию сначала перетрясти набор классов и набор их атрибутов, а уж потом переходить к DDD-анализу. Так, температура (как и, например, длина) может измеряться в разных "градусах" (в примере с длиной -- в "попугаях", в "слонёнках", в "мартышках").
Формально, если верить Вашим композициям (анализ по смыслу я не провожу), то Температура не может быть сущностью, т. к. не расшаривается. Аналогично, Метеоэлемент. Поясню. Если в разных экземплярах Метеоэлемента одна и та же температура "Fahrenheit 451", то в Вашей модели это должны быть два разных экземпляра Температуры, равенство которых Вы установите не по тому, что соединения от обоих экземпляров Метеоэлемента идут в одно и то же место. Если бы на диаграмме была надпись {readOnly} перед атрибутом Температуры, это бы ещё больше убеждало, что перед нами объект-значение.
Как непрошенный совет получите рекомендацию сначала перетрясти набор классов и набор их атрибутов, а уж потом переходить к DDD-анализу. Так, температура (как и, например, длина) может измеряться в разных "градусах" (в примере с длиной -- в "попугаях", в "слонёнках", в "мартышках").
200
Теория моделирования и нотации / Re: Что это за связь типа агрегат между классами со стрелкой на конце?
« : 01 Августа 2018, 21:34:43 »
Так как вопрос решён, то можно донудеть до конца, не влияя на решение.
I. Связь агрегации или композиции показывает, что:
1) для связанных классов характерно, что экземпляры одного класса на довольно длительные сроки соединяются с экземплярами второго класса;
2) соединённые экземпляры неравноправны, экземпляры того класса, возле которого ромб, главнее;
3) при композиции есть дополнительные ограничения:
3а) экземпляры подчинённого класса не могут быть соединены одновременно с более чем одним экземпляром главного класса;
3б) при удалении экземпляра главного класса удаляются экземпляры подчинённого класса, соединённые с ним в этот момент.
II. Стрелка на любой ассоциации (а композиция и ассоциация -- это подвиды ассоциации) явно указывает на возможность навигации вдоль соединений между экземплярами связанных классов в обозначенную сторону. Если навигация возможна, то, идя от экземпляра класса на другом конце, можно эффективно придти ко всем связанным с ним экземплярам класса на конце, куда указывает стрелка. Для простоты "эффективно придти" читают как "есть ссылки", но это не совсем по стандарту. Отсутствие стрелки на другом конце можно прочесть разными способами. Например: а) что мы явно не обозначаем, есть ли навигация в другую сторону; б) что навигации в другую сторону нет; в) что навигация в другую сторону не указана, т. к. её можно определить по тому, кто владеет концом ассоциации.
Наличие навигации, вообще говоря, не означает, что доступны составляющие связанного класса. Видимость (visibility) составляющих (как и самого класса) определяет будут доступны части соединённых экземпляров или нет. Но это всё буквоедство. Если не копать глубоко, то указанное прочтение может быть использовано.
III. 0..3 -- это не просто 0..3, а {unordered, unique} 0..3. Это значит, что соединённые с каким-либо экземпляром класса Наблюдение экземпляры класса Видимость составляют коллекцию со следующими свойствами:
1) в коллекцию входят от 0 до 3-х элементов;
2) элементы коллекции не упорядочены (ни для одного из них нельзя указать предшествующий ему и/или следующий за ним);
3) элементы коллекции не повторяются (каждый входит в коллекцию однократно).
Замечание о глубоком копании, сделанное выше, справедливо и здесь.
I. Связь агрегации или композиции показывает, что:
1) для связанных классов характерно, что экземпляры одного класса на довольно длительные сроки соединяются с экземплярами второго класса;
2) соединённые экземпляры неравноправны, экземпляры того класса, возле которого ромб, главнее;
3) при композиции есть дополнительные ограничения:
3а) экземпляры подчинённого класса не могут быть соединены одновременно с более чем одним экземпляром главного класса;
3б) при удалении экземпляра главного класса удаляются экземпляры подчинённого класса, соединённые с ним в этот момент.
II. Стрелка на любой ассоциации (а композиция и ассоциация -- это подвиды ассоциации) явно указывает на возможность навигации вдоль соединений между экземплярами связанных классов в обозначенную сторону. Если навигация возможна, то, идя от экземпляра класса на другом конце, можно эффективно придти ко всем связанным с ним экземплярам класса на конце, куда указывает стрелка. Для простоты "эффективно придти" читают как "есть ссылки", но это не совсем по стандарту. Отсутствие стрелки на другом конце можно прочесть разными способами. Например: а) что мы явно не обозначаем, есть ли навигация в другую сторону; б) что навигации в другую сторону нет; в) что навигация в другую сторону не указана, т. к. её можно определить по тому, кто владеет концом ассоциации.
Наличие навигации, вообще говоря, не означает, что доступны составляющие связанного класса. Видимость (visibility) составляющих (как и самого класса) определяет будут доступны части соединённых экземпляров или нет. Но это всё буквоедство. Если не копать глубоко, то указанное прочтение может быть использовано.
III. 0..3 -- это не просто 0..3, а {unordered, unique} 0..3. Это значит, что соединённые с каким-либо экземпляром класса Наблюдение экземпляры класса Видимость составляют коллекцию со следующими свойствами:
1) в коллекцию входят от 0 до 3-х элементов;
2) элементы коллекции не упорядочены (ни для одного из них нельзя указать предшествующий ему и/или следующий за ним);
3) элементы коллекции не повторяются (каждый входит в коллекцию однократно).
Замечание о глубоком копании, сделанное выше, справедливо и здесь.
201
Примеры / Re: Диаграмма деятельности. Выбор по событию
« : 29 Июня 2018, 14:59:52 »Если есть другие примеры - дайте, пожалуйста, ссылки.По-моему, их нет. Одна попытка изобразить прерывающим ребром досрочный выход из цикла скорректирована в пользу стандарта.
202
Примеры / Re: Диаграмма деятельности. Выбор по событию
« : 23 Июня 2018, 22:57:18 »Может мы слегка запутались.Авторы стандарта, в частности Бок (мама дорогая, сколько лет тому назад) смотрят на прерываемые регионы с использованием метафоры обработки исключительных ситуаций. Вероятно, Вы используете другую метафору. Это ни плохо, ни хорошо. Я пока толкую, исходя из общей с авторами стандарта метафоры.
Можно вводить собственные термины, такие как "по смыслу прерывающее ребро". Но это оправдано, к. м. к., тогда, когда стандартная терминология неудобна или не применима.
203
Примеры / Re: Диаграмма деятельности. Выбор по событию
« : 20 Июня 2018, 11:26:57 »Диаграмма во вложении эквивалентна диаграмме слайдов?Угу.
204
Примеры / Re: Диаграмма деятельности. Выбор по событию
« : 20 Июня 2018, 11:25:55 »Роли равны - ЛЮБОЙ из двух может прервать другого.Как по мне, в любой из двух реализаций придётся указать прерывающего и прерываемого. Симметрии в решениях не вижу. Язык не даёт подходящего средства.
А какая разница "молнией" или "прямой" выходить из региона - в обоих случаях всё, что связано с регионом прерывается.ДД -- не мой конёк.
В стандарте сказано, что "молния" прерывает, а обычное ребро -- нет. Т. е. не всякое ребро через границу прерывающее. Также там есть Figure 15.73.
Есть подозрение, что на Ваши последние варианты надо добавить "руну Соул".
205
Примеры / Re: Диаграмма деятельности. Выбор по событию
« : 19 Июня 2018, 17:10:28 »
Введение буфера загромождает модель, как мне кажется, и заставляет действие1 порождать объектный токен.
Прерываемый регион не согласуется с "равнозначностью". Один из двух прерывает другого. Роли не равны.
Прерываемый регион, из которого нет "молнии", сомнителен по стилю. Стандарт в своих ocl-ях зачем-то допускает прерываемые регионы без "молний" и "молнии" без прерываемых регионов. На моей планете не могут взять в толк -- зачем.
Прерываемый регион не согласуется с "равнозначностью". Один из двух прерывает другого. Роли не равны.
Прерываемый регион, из которого нет "молнии", сомнителен по стилю. Стандарт в своих ocl-ях зачем-то допускает прерываемые регионы без "молний" и "молнии" без прерываемых регионов. На моей планете не могут взять в толк -- зачем.
206
Примеры / Re: Диаграмма деятельности. Выбор по событию
« : 19 Июня 2018, 12:18:01 »
Стилистически вложение3 лучше ложится на исходный текст. Вложение4 лучше бы легло на текст "если время истечёт раньше наступления События - Действие3, иначе - Действие2".
Стилистически вложение5 не годится, т. к. "ничегонеделательная" деятельность -- костыль "модельера", который (костыль, не "модельер") не должен торчать явно из модели.
По стандарту, скорее всего, все 3 варианта прочекаются.
P. S. К делу не относится, но задачка от авторов "UML3" (см. слайды 50-51) сомнительная какая-то. Как видится с моей планеты.
Стилистически вложение5 не годится, т. к. "ничегонеделательная" деятельность -- костыль "модельера", который (костыль, не "модельер") не должен торчать явно из модели.
По стандарту, скорее всего, все 3 варианта прочекаются.
P. S. К делу не относится, но задачка от авторов "UML3" (см. слайды 50-51) сомнительная какая-то. Как видится с моей планеты.
207
Для всех / Re: Пожалуйста, оцените правильность USE CASE диаграммы
« : 02 Июня 2018, 09:01:14 »
Диаграмма является продолжением примера, в котором в начале приводится (составляется) диаграмма т. н. "top level UC", а затем вводятся UC уровня пониже. Пример иллюстрирует примитивы языка. Он сродни учебным текстам из учебника английского языка.
Можно в N-ный раз зайти на круг разговоров о том, что язык не является технологией, что на практике отдельные средства языка могут оказаться уместны или не уместны.
В правилах языка может что-то нравиться, что-то не нравиться. Мне, например, не нравится многое накрученное понапрасну вокруг include'ов. Как иллюстрация ещё одна страничка с того же сайта. Увязывание abstract с incomplete, concrete с complete видится мне лишним. Как и заклинание о якобы безусловном включении.
Можно в N-ный раз зайти на круг разговоров о том, что язык не является технологией, что на практике отдельные средства языка могут оказаться уместны или не уместны.
В правилах языка может что-то нравиться, что-то не нравиться. Мне, например, не нравится многое накрученное понапрасну вокруг include'ов. Как иллюстрация ещё одна страничка с того же сайта. Увязывание abstract с incomplete, concrete с complete видится мне лишним. Как и заклинание о якобы безусловном включении.
208
Для всех / Re: Пожалуйста, оцените правильность USE CASE диаграммы
« : 30 Мая 2018, 21:17:15 »А что-нибудь кроме этого?Пример с сайта Kirill'a Fakhroutdinov'a:
При обсуждении правил языка мне сподручнее ссылаться на стандарт и на примеры от известных авторов.
209
Обсуждение статей / Re: Интревью с Грэди Бучем
« : 26 Мая 2018, 20:14:38 »
Главное научиться ловить попутный тахионный поток. Остальное -- дело техники.
210
Для всех / Re: Пожалуйста, оцените правильность USE CASE диаграммы
« : 26 Мая 2018, 20:10:32 »
Пример нарисовали Рамбо и Блаха в своей книге:
Ещё раз обращаю внимание, ответ дан в смысле соблюдения/нарушения стандарта UML.
Можно вместо стандарта рассматривать правила каких-либо методик, стилей рисования диаграмм и проч. Можно восклицать: "Что в голове у автора диаграммы!" -- как это кое-где кое у кого принято. Можно всё.
P. S. Авторы стандарта придумали операцию allIncludedUseCases(), которая собирает все включённые (непосредственно или косвенно) UC для заданного UC. Если бы косвенное включение не допускалось бы стандартом, то учитывать бы его не стали и OCL-body для операции было бы проще.
Ещё раз обращаю внимание, ответ дан в смысле соблюдения/нарушения стандарта UML.
Можно вместо стандарта рассматривать правила каких-либо методик, стилей рисования диаграмм и проч. Можно восклицать: "Что в голове у автора диаграммы!" -- как это кое-где кое у кого принято. Можно всё.
P. S. Авторы стандарта придумали операцию allIncludedUseCases(), которая собирает все включённые (непосредственно или косвенно) UC для заданного UC. Если бы косвенное включение не допускалось бы стандартом, то учитывать бы его не стали и OCL-body для операции было бы проще.