Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 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 »
181
Реализация / Re: Композиция, Агрегация
« : 01 Марта 2018, 01:00:34 »
Я, в свою очередь, предлагаю голосовать. Или разыскать стандарт и прочесть.
Между "часть не может существовать без целого" и "при уничтожении целого уничтожаются также и части в его составе" есть некоторая разница.

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

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

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

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

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

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

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

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

187
Реализация / Re: Композиция, Агрегация
« : 21 Января 2018, 04:12:04 »
"Don’t worry about the diamonds" -- наставляет Скот Амблер в своём "The Elements of UML 2.0 Style". При этом на его диаграмму из сопроводиловки лучше не смотреть, чтобы не терзаться популярным на здешней планете вопросом: "А что у Вас, ребята, в головах?"

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

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

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

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

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

191
Реализация / Re: Композиция, Агрегация
« : 22 Декабря 2017, 16:27:34 »
[deleted]

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

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

194
Для всех / Re: Решения задач UML
« : 14 Декабря 2017, 19:27:50 »
Вот я поспорю. В зоопарке антураж совсем не тот, что в сказке.

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

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

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

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

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

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

Страницы: « 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 »