196

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

« : 05 Сентября 2018, 21:09:37 »

Чисто теоретически, плясать можно от печки, т. е. от стандарта (ISO 15288 или его российский аналог, если есть).
На моей планете принято искать материалы и опыт в местах с высочайшей репутацией. Например, в Марсианском институте технологии (MIT). Правда, марсианские жизненные циклы не похожи на земные. Год длиннее и всё такое. При всём сказанном Томск и Архангельск не выглядят российскими кузницами создателей ИС, на мой взгляд профана.

197

Для всех / Re: Интеграция с другой системой в Use case диаграмме

« : 02 Сентября 2018, 20:50:45 »

С этим можно согласиться в том плане, что включаемые ВИ и расширяющие ВИ разрешено не соединять ассоциациями с ДЛ, связанными с включающим или расширяемым ВИ.   
Правомерность инклюдов / экстендов мне кажется разумным проверять по описаниям ВИ. Если от сценария "Создать отчёт" можно проложить дорожку к "Импортировать задачи", то так тому и быть.
Абстрактный ВИ описывает некую общую схему, которая сама по себе не реализуется (её экземпляр не может быть порождён), а лишь используется для удобства описания других ВИ -- своих наследников. В стандарте не проведена граница между абстрактным/конкретным ВИ и полностью описанным (=полным)/ не полностью описанным (=неполным) ВИ. Это ведёт к недопониманию вроде такого.
ВИ с включениями по стандарту неполный, т. к. его описание содержит ссылки на включаемые ВИ. Но он может быть конкретным или абстрактным. Включаемый ВИ по стандарту полный, так как его описание не ссылается на включающие его ВИ (допустим, что других связей нет). Он также может быть конкретным или абстрактным.
ВИ с расширением по стандарту полный, т. к. его описание  не зависит от описаний расширяющих ВИ. Он может быть конкретным или абстрактным. Расширяющий ВИ неполный, т. к. в его описании обязательны ссылки на точки расширения, т. е. на другие описания. Он может быть конкретным или абстрактным.
Представляется, что у абстрактного включаемого ВИ и у абстрактного расширяющего ВИ должны быть конкретные наследники, возможно, не прямые.
Стандарт проводит параллель между включением ВИ и композицией. Напрасно, на мой взгляд. Инклюды и экстенды не зря рисуются как пунктирные стрелки, намекая на зависимость описаний. Ассоциации (композиции) между ВИ стандарт не запрещает (если это ВИ из разных сабжектов), но и не описывает, каков их смысл.

198

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

« : 02 Сентября 2018, 19:48:42 »

У Советова в информ технологиях как раз указано, что ИС в ИТ - это программные, технические и организационные средства, так что вот вполне

... математические, алгоритмические, ...

Такая уж дисциплина досталась. Мой ксенолонгвист советует добавить в список ещё и языковые.)
Если смотреть гуглируемые программы дисциплины, то как результаты освоения указывается изученное ПО, а не, скажем, инструменты прокладки лвс. Гугль-критерий не работает, но всё же. 

199

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

« : 02 Сентября 2018, 03:18:15 »

Я кстати не нашел внятного определения "Инструментальное средство ИС"

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

200

Для всех / Re: Интеграция с другой системой в Use case диаграмме

« : 02 Сентября 2018, 02:50:09 »

Когда ВИ описывает взаимодействие системы со второстепенным ДЛ, стартующее по триггеру (событию времени), тогда на диаграмме заводят фиктивное действующее лицо Время, инициирующее взаимодействие. Например, так рекомендует поступать Скотт Амблер.

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

Но если Вы -- хардкорный разработчик требований, то вместо этого Вы должны ржать и интересоваться тем, что в голове у Скотта Амблера (и не только у него). ХРТ убеждён, что ВИ на диаграмме ВИ рисуют только одного уровня и это уровень "уровня моря". Вообразить пользователя, цель которого "Импорт задач", и которого зовут Время, проблематично.  Несовсем ясно, зачем это делать, но ХРТ видит какой-то повод для этого (ржаки и проч.).
 

201

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

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

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

202

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

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

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

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

203

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

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

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

204

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

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

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

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

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

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

205

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

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

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

206

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

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

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

207

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

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

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

 

208

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

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

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

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

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

209

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

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

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

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

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

210

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