181

Обучение / Re: Инструментальные средства информационных систем

« : 31 Августа 2018, 22:21:40 »

IS2010 -- список рекомендаций. Он упомянут как пример, в котором есть вязанка курсов о процессах, но нет курса о вязанке инструментов.
Если мы пришли к выводу о том, какого рода дисциплина досталась, то можно двигаться дальше. Например, решить, что делать.
Преподавательская инерция подсказывает такой способ "чтоделания": первый цикл нарезать по пути, проложенному предшественником. Это принесёт меньше сюрпризов для студентов. Это позволит лучше понять, что хорошо, что плохо, что возможно, что невозможно.
Если уже сейчас видно, что наследство плохое и хорошего в нём мало, то второй способ "чтоделания": реформировать курс. Тут может быть много разных направлений:
1) Проверить / повторить / укрепить знания и навыки получаемые студентами в рамках других курсов по процессам ЖЦ ИС.
2) Дополнить другие курсы этим, дав в его рамках материал, которые они не кроют, но который необходимо дать.
...
N) ... . 

182

Обучение / Re: Инструментальные средства информационных систем

« : 31 Августа 2018, 01:15:07 »

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

Конструктивно тут выступить сложно. Наоборот -- запросто. Основное содержание, которое следует донести до студентов, что ставить инструменты в фокус внимания неверно. Если мы зайдём в Леруа/Оби/стройрынок в отдел "Инструменты" и всё там изучим, то что это даст? Много меньше, чем если мы при изучении процесса будем практиковаться в работе с инструментами, используемыми при процессе. Крыловская мартышка изучала очки, но не стала офтальмологом.
А значит, должна быть вязанка дисциплин "Процессы ЖЦ ИС", предполагающих освоение разных инструментов в рамках разных дисциплин. Вместить всю вязанку в один курс нереально. Зато реально оценить уровень экспертов, породивших стандарт специальности. Сопоставление с каким-нибудь IS2010 полученную оценку укрепит.

183

Варианты Использования (Use Case) / Re: Шаблон описания Use Case

« : 31 Августа 2018, 00:39:35 »

1) некорректно.
2) некорректно.

184

Варианты Использования (Use Case) / Re: Отношение обобщения

« : 31 Августа 2018, 00:28:21 »

1. Насколько корректно использовать отношение обобщения, как в примере на ДВИ 2.

Некорректно (если речь об UML).

2. Правильно ли я понимаю, что в ВИ уровня "Пользовательский" (по Коберну) описываются только Бизнес ДЛ? Т.е. Системные ДЛ не описываются?

Неправильно.
Будет лучше, если понимание к Вам придёт при помощи диаграмм ВИ из учебников или стандарта. На этих много прочего шума, помимо ошибок по интересующим Вас вопросам.

185

Варианты Использования (Use Case) / Re: Схема ВИ для фильтра сообщений

« : 19 Августа 2018, 11:26:22 »

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

186

О Сайте и Форуме / Re: Просмотр форума на мобильных устройствах

« : 19 Августа 2018, 10:48:23 »

Ссылка работает лучше.

187

Методологии / Re: По методологии DDD температура воздуха и метеоэлемент чем является сущностью?

« : 07 Августа 2018, 21:28:27 »

Гм. Можно зайти с другой стороны. "Сводка" -- это объединение нескольких значений различных параметров погоды, заносимых одновременно. Значение относится к моменту времени и географической точке. Значение либо замеренное, либо прогнозируемое. У значения есть число, единица измерения и параметр погоды, который был замерен или предсказан. Если набор параметров фиксирован, то получается набор классов по 1 на каждый: ТемператураВоздуха, АтмосферноеДавление, Влажность, ... . Если набор не фиксирован, то можно обойтись 1 классом. Вывод "сводки" -- поиск подходящего объекта среди значений нужных параметров погоды.

 

188

Методологии / Re: По методологии DDD температура воздуха и метеоэлемент чем является сущностью?

« : 07 Августа 2018, 00:05:07 »

Здравствуйте.
Предыдущее моё сообщение лучше читать в том смысле, что предлагая диаграммы как сырьё для построения ответа на Ваш вопрос, Вы скорее всего получите мало полезные Вам комменты о том, что исходных данных маловато. Затруднительно найти ошибки (или способы улучшения) диаграммы, используя её саму как единственный источник сведений о разрабатываемой модели.
DDD говорит о классе для объектов-сущностей и классе для объектов-значений как о разных типах классов. К Вашим вопросам о том, какие данные в одном классе, какие в другом, сколько и каких классов нужно, это DDD-рассмотрение напрямую не относится. Например, в книжке Эванса "Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем" (вероятно, Вы используете её) на рис. 5.6 Customer -- "сущность", Address -- "значение". Это два разных класса и две (как минимум, в рамках обычных стратегий ORM)  разные таблицы.
В связи с этим, хочется ясности, какой вопрос стоит перед Вами? 1) "Построить модель которая максимально была бы приближена к будущей БД" или 2) Разобрать на примере отличия между "сущностями" и "значениями"?
В Вашем ответе появились пояснения. Они немного приподымают занавес над тем, что такое "хранить полученные данные" и "показать какая сегодня погода". Но немного. Для того, чтобы судить о "лишнем обновлении данных всех таблиц" нужен глоссарий ПрО, нужны сценарии. Например, глоссарий (пояснение терминов ПрО и их взаимосвязей) дали бы понять в каком смысле "метеоэлемент" является частью "погоды".
Кажется странным с самого начала озаботиться эффективностью обновлений и схожестью модели классов со схемой будущей БД. Обычно в начале строят простой эскиз, кроющий базовую функциональность, а потом перерабатывают его с учётом вопросов хранения и эффективности.
Дополнительный туман сгущается из-за использования Вами нотации. Ромбики были (и не разрешали двум Погодам иметь общий Метеоэлемент см. "метеоэлементы совпадают"). Теперь ромбиков нету. И надо решать, почему "Метеоэлемент не является отдельным классом" (т. е. в моём прочтении, почему объекты-метеоэлементы у разных погод не могут совпадать).

Вижу, что моё подключение скорее запутывает, а раз так, то спешу улететь.
Кажется, что есть набор "сводок", упорядоченных по дате/времени. У "сводки" есть флажок, является ли она наблюдённым фактом или же прогнозом (замечу, что ожидаемо в прогнозе видеть не точное значение, а диапазон). У "сводки" есть перечень составляющих: t воздуха, t воды, давление, влажность ... . Любой составляющей может не быть. Выводимые сведения о погоде  на дату/время дд.мм чч.мм берутся из последней "сводки" из тех, что не позже дд.мм чч.мм, если в ней не все нужные составляющие, то их ищут в предшествующей "сводке" и идут по перечню в сторону против хода времени, пока не соберут все составляющие. Что-то ещё делают со "сводками-прогнозами". Вероятно, когда хотят видеть сведения о погоде, то указывают, что нужно: факт или прогноз.

Такой вот прогноз по увиденному сквозь туман.

189

Методологии / Re: По методологии DDD температура воздуха и метеоэлемент чем является сущностью?

« : 01 Августа 2018, 22:17:26 »

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

Формально, если верить Вашим композициям (анализ по смыслу я не провожу), то Температура не может быть сущностью, т. к. не расшаривается. Аналогично, Метеоэлемент. Поясню. Если в разных экземплярах Метеоэлемента одна и та же температура "Fahrenheit 451", то в Вашей модели это должны быть два разных экземпляра Температуры, равенство которых Вы установите не по тому, что соединения от обоих экземпляров Метеоэлемента идут в одно и то же место. Если бы на диаграмме была надпись {readOnly} перед атрибутом Температуры, это бы ещё больше  убеждало, что перед нами объект-значение.

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

190

Теория моделирования и нотации / 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) элементы коллекции не повторяются (каждый входит в коллекцию однократно).
Замечание о глубоком копании, сделанное выше, справедливо и здесь.

191

Примеры / Re: Диаграмма деятельности. Выбор по событию

« : 29 Июня 2018, 14:59:52 »

Если есть другие примеры - дайте, пожалуйста, ссылки.

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

192

Примеры / Re: Диаграмма деятельности. Выбор по событию

« : 23 Июня 2018, 22:57:18 »

Может мы слегка запутались.

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

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

193

Примеры / Re: Диаграмма деятельности. Выбор по событию

« : 20 Июня 2018, 11:26:57 »

Диаграмма во вложении эквивалентна диаграмме слайдов?

Угу.

194

Примеры / Re: Диаграмма деятельности. Выбор по событию

« : 20 Июня 2018, 11:25:55 »

Роли равны - ЛЮБОЙ из двух может прервать другого.

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

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

ДД -- не мой конёк.
В стандарте сказано, что "молния" прерывает, а обычное ребро -- нет. Т. е. не всякое ребро через границу прерывающее. Также там есть Figure 15.73.
Есть подозрение, что на Ваши последние варианты надо добавить "руну Соул".

195

Примеры / Re: Диаграмма деятельности. Выбор по событию

« : 19 Июня 2018, 17:10:28 »

Введение буфера загромождает модель, как мне кажется, и заставляет действие1 порождать объектный токен.
Прерываемый регион не согласуется с "равнозначностью". Один из двух прерывает другого. Роли не равны.
Прерываемый регион, из которого нет "молнии", сомнителен по стилю. Стандарт в своих ocl-ях зачем-то допускает прерываемые регионы без "молний" и "молнии" без прерываемых регионов. На моей планете не могут взять в толк -- зачем.