241

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

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

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

242

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

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

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

243

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

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

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

244

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

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

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

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

245

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

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

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

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

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

246

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

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

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

247

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

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

[deleted]

248

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

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

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

249

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

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

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

250

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

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

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

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

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

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

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

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

251

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

« : 14 Декабря 2017, 19:08:00 »

На диаграмме чего-то странное с закрашенными ромбиками творится. Так что я -- тоже новичок и тоже пока ничего не понимаю. На языке стандартного UML прочесть её нельзя.

252

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

« : 13 Декабря 2017, 18:54:24 »

При некоторой вольности прочтения такая диаграмма и для зоопарка сгодится.

253

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 23 Ноября 2017, 19:53:10 »

Если что, мне розовая диаграмма кажется симпатичнее чем серая. Только бы редефайнов навставлять и наследование как-нибудь позамысловатее -- начинать от линий ассоциации.) На серой рука тянется объявить, что наследование подчиняется "принципу Рамбо" и считать, что наследники наследуют от класса ассоциации только классовую часть.
А решение с одним классом ассоциацией, у которого опциональные поля и составные части, рассматривалось?

254

Примеры / Re: Как обозначить атрибут, значение которого вычисляется в момент создания объекта

« : 20 Ноября 2017, 23:20:19 »

Дайте, пожалуйста, ссылку.

https://www.uml-diagrams.org/derived-property.html

Derived property is property which value (or values) is produced or computed from other information...

Избирательному цитированию научилось от местных старожилов, если что.
Так вот, если мы согласимся, что значение параметра сеттера в момент его последнего вызова -- это "other information", то можем смело метить атрибут этого сеттера выводимым.)))

255

ПО Аналитика / Re: MagicDraw класс-ассоциация наследование

« : 20 Ноября 2017, 23:14:15 »

Верим, поэтому конечно "подкласс класса ассоциации -- не просто класс, но и [класс] ассоциация", но это необязательно обозначать на диаграмме, если у этой ассоциации нет ничего нового, по сравнению с исходной.

Если читать стандарт UML 2.5 буквально, то в 11.5.4 (стр. 200) описано как должен изображаться класс ассоциации. И там ничего не говорится о том, что наследование делает какие-то элементы нотации класса ассоциации необязательными. Интересно, что класс ассоциации единый элемент модели, но изображается сразу тремя графическими конструкциями: линией ассоциации (или "ромбиком с лучами", если она n-арная) + пунктирчиком + "висюлькой" класса. И обобщение, по идее, можно рисовать, стартуя от любой части, и финишируя в любой части.

Кстати "Лизковой" - это здорово, сразу видно, что речь идет о женщине, а то некоторые об этом забывают (а то и не знали никогда)

Может быть тут правильнее "принцип Лисковы" (полагая, что Liskov -- Лискова).
А вот Рамбо не верит в LSP. И нам не велит.) [Upd: Перепутало Рамбо с Бертраном Мейером. Да и тот, не то, чтобы не верит в LSP, просто не считает его чем-то значительным и связанным именно с Лисков.] Какой-то зловред вроде него включил в стандарт "isSubstitutable"-свойство обобщения (9.2.3.2), указывающее подчиняется ли наследник LSP или нет.

А вот здесь есть новое, поэтому изображение ассоциации на диаграмме оправдано (но это выбор не инструмента, а пользователя, который, правда ошибся - 0..4 не может наследовать 0..2)

Тут, кстати, интересно разобрать. Экземпляром ассоциации является линк (соединение) у которого нет мощности. LSP оперирует экземплярами.

Так они могут захотеть чтобы я и остальные наследуемые свойства указывал - какая тогда выгода от такого изображения наследования

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

В наследнике доопределяется только то, что связано с его "классовой" сутью, поэтому на диаграмме отображается только класс (отображая и ассоциацию, что можно при ней указать - или ничего, или повторить то, что на родительской)

Здесь снова (как, может помните, на диаграммах состояний) сталкиваемся с желанием сделать каждый визуальный элемент отдельным элементом модели. А стандарт не велит [пока].