226

Реализация / Re: Композиция, Агрегация

« : 01 Марта 2018, 09:33:47 »

"... которое обеспечивает выполнение этого структурного ограничения.

Или не обеспечивает.)

227

Реализация / Re: Композиция, Агрегация

« : 01 Марта 2018, 01:00:34 »

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

228

Примеры / Re: Диаграмма ВИ. Работа с выборками

« : 18 Февраля 2018, 15:30:24 »

Однако для меня только лучше, если кто-то, особенно с другой планеты, скажет где и что я делаю не так (:

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

Если Ваша аудитория готова мириться с тем, что описания ВИ большие и структурированные на потоки, подпотоки, подподпотоки, ... если Вы готовы мириться с частичным дублированием описаний разных ВИ, то структурированная ДВИ со связями между ВИ не нужна. В таком случае описание главного ВИ объемлет всё. Включения и расширения не имеют собственных отдельных описаний и существуют как части описания главного ВИ.

SALar "развинчивает" Вашу диаграмму не с точки зрения нотации, а с аналитической, со смысловой. Скорее всего, для практических задач это важнее.

Galogen даёт советы, исходя из обоих точек зрения.

229

Примеры / Re: Диаграмма ВИ. Работа с выборками

« : 15 Февраля 2018, 16:42:17 »

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

230

Для всех / Re: Помогите с диаграммой классов для описания предметной области

« : 08 Февраля 2018, 20:09:13 »

В текущей версии комплекс -- не товар (значит, не имеет стоимости, не может быть включён в заказ).
Единственная операция на диаграмме кажется странной. Что, куда предполагается добавить?
Минимальные мощности 1 не всюду уместны. Например, водку (добавку) можно добавить в томатный сок (напиток), но не обязательно её ещё и в борщ (еда) плескать или в пельмени из шприца заряжать (еда). Опять же водку можно и в виноградный сок добавить (ну хорошо-хорошо, пусть будет чай+сахар, кофе+сахар).
Начать было удобно с внятного текстового описания ПО, которую предстоит визуально моделировать.

231

Работа / Re: Чего хотят от аналитиков работодатели

« : 08 Февраля 2018, 19:54:54 »

Мой ксенолингвист подсказывает, что скармливание "analyst" находит ещё N-ное количество составителей объяв из HR, зачем-то хотящих UML.
Скармливание гуглю "проф. стандарт" и "языки визуального моделирования" тоже даёт результат столь же интересный. Приводящий чуть ли не в одну из соседних тем. Авторы проекта стандарта БА (пользуясь случаем шлю им своей уважухи) уверены, что ЯВМ необходимо знать. Какие, в каком объёме -- им неважно. Для других навыков/знаний устаканивается требуемый их объем: либо "необходимый для целей Бизнес-анализа" (знать/уметь больше чем необходимо -- вредно?), либо "достаточный для решения задач Бизнес-анализа" (клёво сформулировано, предположительно весь текст стандарта можно свести к паре предложений, используя процитированный словесный оборот).
Примечательно, что знание ЯВМ ценно само по себе. Знаешь какие-нибудь "шашлычные" диаграммы --> получаешь плюсик в табличную ячейку --> двигаешься дальше к корочкам "профи". На фоне этого HR-щик, пишущий о "профессиональном владении UML" олдскульно скучен.  И столь же скучно буду выглядеть я, если поинтересуюсь, необходимо ли БА знать языки невизуального моделирования по мнению авторов проекта профстандарта? В смысле, не английский.

232

UML SysML и пр. / Re: Как отобразить в диаграмме классов разные типы Generalization Set

« : 23 Января 2018, 17:03:57 »

Интересный ресурс -- столько разных диаграммок.
Спасибо, Vadim! [Без шуток.]

233

Реализация / Re: Композиция, Агрегация

« : 21 Января 2018, 04:12:04 »

"Don’t worry about the diamonds" -- наставляет Скот Амблер в своём "The Elements of UML 2.0 Style". При этом на его диаграмму из сопроводиловки лучше не смотреть, чтобы не терзаться популярным на здешней планете вопросом: "А что у Вас, ребята, в головах?"

234

UML SysML и пр. / Re: Как отобразить в диаграмме классов разные типы Generalization Set

« : 21 Января 2018, 04:01:32 »

Это тоже вариант. У него свои недостатки

Цитировалась та картинка, что нашлась в сети.
На "нормальной" старшинство по отношению к "хвосту" было бы размечено композицией / агрегацией.

235

UML SysML и пр. / Re: Как отобразить в диаграмме классов разные типы Generalization Set

« : 20 Января 2018, 15:59:00 »

UML, на моей планете), предпочитает не касаться вопроса о том, может ли менять свой тип экземпляр класса. С него достаточно, что он позволяет через запятую указать несколько не конфликтующих (текущих) типов экземпляра (в этом месте у многих кодеров может взорваться мозг). Но это _имеющиеся_ у экземпляра типы. Может ли объект менять тип -- это свойство ОО-среды реализации, например, OO-языка программирования. Многие UML-модели делаются так, как-будто типы экземпляров статичны (с единственной поблажной имени Барбары Лисковы). Например, в классическом RUP-овом примере от Rational используется делегирование, чтобы показать, что студенты бывают разных типов и могут менять свой тип:

Смена типа студента состоит в том, что один "хвост" ему отрезают, а другой -- пришивают.

Мне нравится, как легко "развинчивается" UML. Достаточно взять примитивы языка и соединить в таком сочетании, которое авторы языка / стандарта / книг на публике не использовали. И вуаля.
Если требуется комментарий к решению с powertype, то он есть в книжке Milicev "MDD with xUML". В таком ключе: powertype придумали бизнес-аналитики, пусть они им и пользуются.

236

Для всех / Re: Правильно ли так использовать Include и Extend

« : 02 Января 2018, 02:42:45 »

1) "Include" и "extend" не стереотипы.
2) Авторы большинства подобных тем не предоставляют достаточных сведений, чтобы была возможность ответить на их вопрос.
3) Беглого знакомства с книжкой Коберна обычно достаточно, чтобы самому себе дать адекватный ответ на подобный вопрос.

237

Реализация / Re: Композиция, Агрегация

« : 22 Декабря 2017, 16:27:34 »

[deleted]

238

Задачи студентов / Re: Перевод с UML на русский язык

« : 15 Декабря 2017, 17:25:35 »

Композиция и агрегация (а также ассоциация) определяют тип для описания однородных соединений между экземплярами. И накладывают ограничения на соединения между экземплярами. И это всё несмотря на то, что это связи между классами.
Меня такие картинки заставляют задумываться, что уместнее писать 1 или 0..1, ну и про всякие там фигурные скобочки и их внутренности. И про OCLи, которые к таким картинкам прилагаются как обязательная их часть.
Всё вышесказанное относится к контексту моей планеты, а не здешней. Любые совпадения/расхождения случайны.

239

Задачи студентов / Re: Перевод с UML на русский язык

« : 15 Декабря 2017, 00:20:22 »

На моей планете ДНК и РНК не слипаются по общей "нуклеотиде". А если и слипаются, то не делают вид, что общая "нуклеотида" не общая, а частная -- в монопольном владении каждого хозяина. Опять же стандарт UML с моей планеты такое делать не велит.

240

Для всех / Re: Решения задач UML

« : 14 Декабря 2017, 19:27:50 »

Вот я поспорю. В зоопарке антураж совсем не тот, что в сказке.

Диаграмма классов может подойти если зайти со стороны классификации сказок. Вроде:
Сказка
AA
| |
| L__ ЛитературнаяСказка
L_ФольклорнаяСказка

ФольклорнаяСказка
AAA
| | |
| | L__ ВолшебнаяСказка
| L__ ...
L_СказкаOЖивотных

СказкаOЖивотных
AAA
| | |
| | L__ ...
| L__ ...
L_СказкаПроЛису

И вот наконец наша сказка -- экземпляр класса СказкаПроЛису

Если моделировать сказочный сюжет, то вместо животного в сказке Персонаж и т. п.