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

×


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

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


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

Страницы: « 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 32 33 34 35 »
301
Примеры
Здесь обсуждаются любые примеры моделей, составленных в любых нотациях.

Нововведения
Все новое в сферах бизнес- и системной аналитики, а также IT-индустрии.

Поделюсь впечатлением, что новостные ленты с заглавной страницы отчасти дублируют этот раздел. Отчасти, так как новости появляются там, а возможность обсудить (другие) новости даётся здесь. На других планетах видело приём, когда в форуме заводится раздел с обсуждениями записей из новостных лент. Например, под записью про ГОСТ Р 57100-2016 могла бы быть кнопка "Обсудить на форуме". Как только заводится первая реплика к новостной записи -- на форуме появляется тема, куда она и последующие реплики складываются. Скорее всего, не все записи имеет смысл обсуждать (например, выжимки из форума лучше оставить без обсуждений).

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

302
На других планетах мои замечания о содержании подфорумов считают самодеятельным модерированием и пресекают.)

303
Спасибо, а не хотите стать модератором?
Нет. Если бы хотело, то выбрало бы себе ник "UML Metamodel Наци".)
Кстати, а кто самодеятельно модерирует?
Моё замечание о "рокировках" можно счесть самодеятельностью такого рода.

304
Отчего бы лишний раз не похвалить книгу Рамбо и Блахи. Как у руководства по диаграммам классов и диаграммам состояний у неё мало соперниц. И как у сборника задач по UML. Другое дело, что перевод условий задач таков, что "методичку"-решебник, выпущенную для преподов издательством Pearson, использовать вместе с переведённой книгой затруднительно. К перетолмаченным формулировкам условий авторские решения часто не подходят. 

305
Идея по улучшению форума:
На заглавной странице есть описания разделов. Предлагаю из описаний разделов "Примеры" и "Нововведения" убрать упоминание UML. Может быть, это поспособствует тому, что смена ГОСТов не будет казаться umlьным нововведением, а приглашение проверить IDEF-пример -- обсуждением нотации. Добавлю, что, на мой вкус, некоторые темы про нотации, оказавшиеся в "Примерах", неплохо бы "рокирнуть" с темами про задачи из "Теории моделирования и нотаций".
P. S. + Внести в правила пункт о запрете попыток самодеятельного модерирования со стороны рядовых участников.))

306
На практике в RUP-проекте 4 контрольные точки. Продвижение между ними -- это и есть RUP-этапы, т. е. фазы. Поскольку между некоторыми контрольными точками "расстояние" велико, фазы можно/нужно делить на итерации. Каждая итерация -- "каскад в миниатюре", похожий на описанное Вами. Отличие в том, что ЖЦ -- не просто повторение итераций, завершающееся релизом продукта. По RUPу полно публикаций, в том числе на русском, где всё это изложено. Коротко и по существу можно видеть здесь: http://panda.ispras.ru/~kuliamin/lectures-sdt/sdt-book-2006.pdf  стр.:35-44.

307
Множественность длины [0..1], поэтому тип длины такой, что включает и null-значение.
При такой мощности мне придраться не к чему.

Все равно не уловил.
Там указывается, что null можно использовать не только как пустое значение, но и как неопределённое значение. Если в Client::email положили null (например, конструктором/init'ом), то это может явно указывать, что емэйл неизвестен. Из  того, что авторы стандарта OCL пишут "may, for example, be assigned to an attribute", можно сделать вывод, что null не возникает сам по себе как неопределённое значение атрибута. Авторы метамодели UML полагают, что возникает, но не оговаривают это в своём стандарте.

хотелось обойтись без конструкторов
Попадались попытки расширения языка в сторону темпоральности, но я внимательно в эту сторону не смотрело.


308
Эти авторы когда-то впечатлили меня фразой: "существуют три уровня понимания обучающимся нового предмета, которые характеризуются следующими признаками: 1. Возникает приятное чувство понимания; 2. Может повторить своими словами; 3. Видит ошибки.
Навеяло. У Коберна 4 уровня понимания: http://alistair.cockburn.us/Shu+Ha+Ri+Kokoro

309
Строго говоря, не инициализированный слот не получает никакого значения.
Имелось в виду, что не получает никакого значения при инициализации экземпляра.) По стандарту при мощности 1..1 значение быть должно. Можно предположить, что перед инициализацией, т. е. при создании "голого" экземпляра в атрибуты кладутся какие-то значения, как того требуют мощности. Но что это за значения, можно лишь гадать (и сравнивать с null, как это делают авторы метамодели:)).

310
В 11.7.1 Collection (OCL) есть:
Note: null->isEmpty() returns 'true' in virtue of the implicit casting from null to Bag{}
Я, наверно, ошибаюсь, считая, что тип длины определяется статически по её описанию, а не динамически по её значению.

Авторы OCL чаще используют oclIsUndefined(), но в одном месте (11.5.4) - null.
oclIsUndefined() лучше тем, что сработает при неправильно вычисленной длине (например, полученной делением на 0).

Для меня это слишком: отдельно null, отдельно "никакое значение". Можно ссылку на намёк?
A.2.1.1 Пример с email'ами.

А про это что-нибудь: ...
Угу. Полагаю, что общую часть можно описать один раз через def, а затем использовать в предусловиях разных конструкторов.

311
Если изменится правило вычисления выводимого атрибута или начальное значение того, из чего выводится выводимый атрибут, то возможно изменится и выписанное начальное значение - автору надо не забыть исправить.
Ну, да.

длина->isEmpty() or ширина->isEmpty()
меняем на длина=null or ширина=null
или лучше на длина.oclIsUndefined() or ширина.oclIsUndefined()

Подразумевается, что при инициализации длина и ширина получают "пустое" значение.
Смешно, нигде явно не сказано, что писать в oclьке, чтобы проверить, есть ли значение в слоте (атрибуте). Сами авторы стандарта UML при описании метамодели сравнивают с null в таких случаях. Дурной пример заразителен, так что я думаю, надо идти след в след за ними. Строго говоря, не инициализированный слот не получает никакого значения. Чтобы по умолчанию был null надо явно его указывать, как дефолтное значение [намёк на это есть в стандарте OCL]. Так что речь нужно вести не о том, что лежит в слоте, если туда ничего не положили и не указали дефолтное значение, а о том, как выглядит ocl-проверка.
 
Это единственное - Property::isComposite?
Да. Искало без фанатизма, но, кажется, больше такого нет.

312
Что привносит возможность одновременно задать и derive, и init?
Да. Я по-прежнему думаю, что автор модели может потрафить читателю и явно выписать начальное значение выводимого атрибута (правда, затратив дополнительные усилия, чтобы они соответствовали друг другу). Например, площадь "хитрого" прямоугольника может быть единичной при неопределённом значении длины и/или ширины, а при заданных размерах равняться их произведению. Derive-правило в этом случает будет немного длинной oclькой, зато единицу можно указать не только в нём, но и явно на ДК.
 
Поэтому возможность одновременного указания derive и init считаю лишней - "For each property there should be at most one initialization OR derivation constraint." (если что-то не так с английским - простите).
Можно ей не пользоваться, но вдруг кем-то [авторами метамодели UML в одном единственном месте] востребовано.)

По-моему между "все время" и "когда затребовано" нет никакой разницы: даже про значение обыкновенного (не выводимого) атрибута известно только в тот момент, когда "затребовано" (ну и получено) это значение.
Можно вообразить себе, что какая-то модель запрещает реализацию с "ленивыми" сеттерами атрибутов. Т. е. не допускает стратегию, при которой изменения только обещаются к выполнению и откладываются до самого последнего момента, когда затребовано изменённое значение. В такой "неленивой" модели следует потребовать выполнимости "всё время". В "ленивой" модели достаточно ограничения "когда затребовано".
OCLьщики не ленивы. UMLьщики -- лентяи.))

Упоминается это мелкое замечание: " Note, however, that ...?
Да, оно.

313
Пролетая мимо, интересно заметить, что в подразделе форума, посвящённому UML-нотации, размещена тема, в которой по большей части обсуждаются не ошибки с точки зрения нотации, а ошибки use-case моделирования (назовём это так), за которые некоторые участники обсуждения выдают любые отклонения от привычных им практик. Всё это довольно близко к подходу, в рамках которого UML пытаются рассматривать и критиковать не как язык, а как метод (назовём это так).

314
Ситуация из 9. чревата тогда, когда правило начального значения и правило производного значения приводят к разным результатам. Init это только на момент инициализации, а derive - и на момент инициализации, и на всю последующую жизнь! (readonly только на оставшуюся жизнь, но не на момент инициализации)
...
Производный атрибут может использоваться в invariant-ограничениях, а там неактуальным не место!
С Вами согласны авторы стандарта OCL 2.4 (см. 7.3.3, 7.3.7, 12.6, 12.9). Я спорить не буду, лишь замечу, что обороты вроде "всё время" употребимы для деклараций/спецификаций. С точки зрения реализации может быть достаточно [а может-- и нет], чтобы выводимый атрибут имел корректное значение всякий раз, когда оно затребовано. Такой ситуации отвечает описание ограничения как тела операции, а не как правила вывода. Быть может, то, что авторы UML 2.5 в метамодели UML описывают body, указывает на это обстоятельство. В этом можно увидеть различие между umlьным derive и oclьным (про oclьный явно сказано в тексте его стандарта, что он "всё время"). Забавно, что umlьные инварианты соблюдаются не всегда, если верить мелкому замечанию внутри 6.3.3. (мол, между вызовами операций объекта всё должно быть чики-пуки, а во время выполнения метода на инварианты смотрят сквозь пальцы).

У тех же Новикова и Иванова про derive:... Если убрать зависимый элемент и заменить все его использования на его derive-определение, ничего измениться не должно. А это возможно, если зависимый элемент постоянно будет актуальным.
Авторы "UML3" переводят пояснение, данное в стандарте к стереотипу <<derive>> из стандартного профиля, который можно применять к связям реализации и манифестации. Полагаю, что к этому случаю написанное и относится.

315
readonly и derived - это свойства "раз и навсегда", frozen (unfrozen) - только на время.
Согласно. Выше, говоря о связке readOnly с frozen, имело в виду, что readOnly=frozenForever.

Кроме того, если атрибут readonly, то делать его frozen (unfrozen) не имеет смысла - от этого ничего не изменится. И еще, если атрибут derived, то какой смысл давать ему defaultValue, разве что считать это дополнительным ограничением на те атрибуты, по которым вычисляется этот атрибут.
Речь шла не о совместном применении readOnly и frozen, а об общности их смыслов.
Меня озарило, что авторы стандарта дали кучу примеров использования обсуждаемых нами тегов и слэшей. Они даны на диаграммах (и OCLях) описывающих метамодель UML. На 9.5.2 есть такое: Property::/isComposite:Boolean=false (также в 9.9.17.5). Авторы демонстрируют свой приём моделирования. Для каждого выводимого атрибута (полюса ассоциации) ими заводится одноимённая операция, возвращающая выведенное значение. Если OCL позволяет, то операции даётся тело (удивительно, что не derive!). См. Property::isComposite() в 9.9.17.7. Если убрать начальное значение в этом примере, смысл сохранится. Есть подозрение, что явное выписывание начального значения тут -- подсказка читателю диаграммы, чтобы ему не пришлось искать тело и в уме делать вывод. В схожей ситуации 12.3.2 (12.4.1.4, 12.4.1.6), Extension::/isRequired:Boolean вместо =false указано {readOnly}. Налицо "эффект дрожжей". Есть ещё одно подозрение, что завихрения относительно readOnly + derived рождались у авторов стандарта и обкатывались на метамодели UML. Т. е. это их реализаторская точка зрения, в которой они путают "не может меняться извне" с "не может меняться после инициализации". По каким-то причинам авторам эта путаница удобна. О том, как быть остальным, они не заботились. Щепотка "дрожжей" нашлась в описании Message::/messageKind {readOnly}. Для выводимого атрибута задана операция, тело которой состоит из возврата значения взятого у самого атрибута.
 
Например описание атрибутов "длина, ширина, /площадь=6 {derive: длина*ширина}" означает: "Сразу после инициализации длина и ширина могут быть любыми числами, но их произведение должно равняться 6. Потом на длину и ширину не накладывается никаких ограничений, но площадь всегда будет равна их произведению.".
Я бы такое описание прочло так: Длина и ширина не имеют значений по умолчанию. Площадь по умолчанию равна 6. В какие-то моменты времени значение площади вычисляется как произведение длины на ширину. Чтобы описать, в какие именно моменты, следует дать диаграмму состояний и/или дать реализации операций класса Прямоугольник.

Эти авторы когда-то впечатлили меня фразой: "существуют три уровня понимания обучающимся нового предмета, которые характеризуются следующими признаками: 1. Возникает приятное чувство понимания; 2. Может повторить своими словами; 3. Видит ошибки. Данная книга написана на третьем уровне и адресована обучающимся, ориентированным на третий уровень" - взято отсюда. Про derived ничего не говорят, только про derive.
Авторы захаживали/захаживают на эту планету, так что я остановлюсь на первом предложенном ими уровне.

Склеиваем и получаем: как получилось расчетное значение сразу после инициализации, так дальше и не меняется, хотя все время пересчитывается.
Я полагаю, что слэш не устанавливает явной директивы, что нужно всё время пересчитывать. Стандарт на этот счёт лишь замечает, что изменение значения nonReadOnly выводимого свойства должно подчиняться derive-ограничению.

Рассмотрим класс "меняющийся прямоугольник" с атрибутами: длина, ширина, площадь, первоначальная площадь. Правильным описанием двух последних атрибутов будет: /площадь {derive: длина*ширина}, первоначальная площадь=площадь {readonly} (если считать, что "=defaultValue" отражает постусловие конструктора). Делать первоначальную площадь derive нельзя - тогда надо указывать правило вычисления. Или считать, что для атрибута с derived наличие "=defaultValue" (может в сочетании с readonly) служит правилом вычисления.
С точки зрения написанного мной выше этот пример может быть разобран так:
Значение первоначальной площади зависит от других значений, значит этот атрибут можно пометить как выводимый.
Указание начального значения у первоначальной площади, которая является {readOnly}, играет ту же роль, что и правило вычисления. При инициализации объекта будет вычислено то, что справа от равенства, результат будет положен в  первоначальную площадь, далее он меняться не будет.

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