361

Обучение / Re: Подскажите начинающему ассистенту преподавателя

« : 06 Сентября 2016, 18:14:31 »

Что Вы показываете на диаграмме, зависит от того, с какой целью Вы её рисовали. Вы не привели никаких описаний, поэтому диаграммы можно оценивать лишь как есть -- т. е. по соответствию/несоответствию правилам UML. Операции представляют в модели ответственности объектов класса, они же являются обработчиками принятых объектами сообщений. Но в модели, которую Вы представили, это не так.

362

Обучение / Re: Подскажите начинающему ассистенту преподавателя

« : 06 Сентября 2016, 11:32:20 »

Коммуникационная диаграмма перепутана с диаграммой последовательности.
На диаграмме классов есть Заказ, но из диаграммы вариантов использования не следует, что какие-либо действия с заказом совершаются.
Сигнатуры атрибутов ещё куда ни шло (действительно ли нужно указывать типы латиницей?), но у операций -- нет слов. В дополнение к этому замечанию укажу, что ни одно сообщение с диаграмм взаимодействия нельзя связать ни с одной операцией. Поясняю, если объект-сотрудник посылает сообщение "наклеивает номера" объекту-отправлению, это значит, что у отправления есть операция "наклеивает номера" и это оно -- отправление -- их наклеивает.
Диаграмма состояний бессмысленна. Entry и exit -- это действия по входу и выходу, а не события, вызывающие смену состояний. Таковые события следует указывать на переходах.

Подсказать в такой ситуации можно следующее: на русском языке есть достаточное количество учебников (обычно, переводных) с учебными примерами по UML. Там бывают ошибки, но более мелкие, чем те, что указаны выше. Используйте примеры из проверенных источников.

363

Примеры / Re: На сколько правильный пример диаграммы?

« : 31 Августа 2016, 14:44:43 »

11ая глава стандарта UML2.5. Только тут есть отступления от стандартной нотации. Кроме того, в стандарте, как обычно, накручено так, что OCL я бы применил с большей уверенностью.

364

Примеры / Re: На сколько правильный пример диаграммы?

« : 30 Августа 2016, 19:07:49 »

Модель как эскиз, модель как иллюстрация, модель как промежуточное звено в цепочке трансформаций моделей, модель как предшественница сгенерированного по ней кода, модель как результат обратной инженерии кода...

365

Примеры / Re: На сколько правильный пример диаграммы?

« : 30 Августа 2016, 11:16:50 »

Мне нравится, как у Амблера написано про годные гибкие модели: http://agilemodeling.com/essays/whenIsAModelAgile.htm Что у модели есть цель и аудитория, что она достаточно подробна, достаточно точна  и достаточно непротиворечива. В этом смысле любую модель можно критиковать, определяя свою цель, свой уровень подробности, точности, непротиворечивости.
Пример, похожий на [1] даётся далее в главе 6

поэтому тут можно усмотреть чисто методические причины.
[2] Когда было проще с проходом в здания, такое практиковалось и, насколько мне известно, официально не запрещено.
[3] Может. У нас физику читали преподы с другого факультета (физфака). А наши преподы мучили студентов-геологов.
[4] Имеет смысл отделить описание курса от прочтения курса, если мы хотим идти дальше учебного эскиза. 

366

Примеры / Re: На сколько правильный пример диаграммы?

« : 30 Августа 2016, 10:16:43 »

Если верить этому переводу...

Это перевод первой редакции книги (про "первый" UML). Вот мы и раскрыли тайны "кухни". При подготовке перевода второй редакции поленились снова перевести диаграмму, взяли готовую из предыдущего перевода, не обратив внимание на то, что у неё в разных редакциях разные версии.

367

Примеры / Re: На сколько правильный пример диаграммы?

« : 30 Августа 2016, 08:35:16 »

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

368

Примеры / Re: На сколько правильный пример диаграммы?

« : 29 Августа 2016, 12:47:03 »

Привет.
История такая. Картинку взяли из 1-го издания, где она имела номер 5-10 и в сопроводительном тексте ничего не было сказано о мощностях ассоциации Курс -- Факультет. Но текст взяли из второго издания, где картинка исправлена и выглядит так:

Итог. Ошибка у тех, кто готовил к изданию перевод на русский язык. 

369

Задачи студентов / Re: Лабораторные работы по UML. Насколько правильно задание?

« : 25 Августа 2016, 12:34:33 »

Это диаграмма из RUP'а, т. е. учебный пример от Rational.

370

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 22 Августа 2016, 14:03:44 »

Я лишь пытаюсь уточнить свою мысль. Переходить от "ограничений на связанные с экземпляром классификаторы" на другие ограничения в мои планы пока не входит.
Ещё в стандарте есть параграф 9.9.9.6. Именно к нему относится сказанное мной об отсутствии ограничений в стандартной метамодели UML.
Подход "запишем через запятую и всё" не плох, что и говорить.) 

371

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 22 Августа 2016, 12:10:53 »

Ограничения есть

P. S. В метамодели UML ассоциация между классификатором и экземпляром ничем не ограничена. Вообще. Нет даже сакраментального "Cannot be expressed in OCL".

372

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 22 Августа 2016, 12:03:46 »

Берётся, но не достигает.

Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных. Наоборот применяется растушёвка: вершины стабильные и нестабильные; звенья/переходы/составные переходы.

373

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 22 Августа 2016, 11:53:06 »

Ограничения есть, конфигурация классов должна быть допустимой, но это на совести автора диаграммы объектов - как определять допустимые конфигурации по модели классов даже у Оливе нет.

Эти ограничения настолько слабы (после overlapping'а по умолчанию), что их как бы и нет. Единственное, что явно сказано про недопустимые конфигурации в стандарте -- disjoint'ы. Нет их, нет и ограничений.

Путь с обязательным заведением класса-наследника неприемлем.

Это путь от кода. Но ему есть хоть какое-то объяснение. Что например мешает двум никак не связанным классам расшарить экземпляр? По [молчащему на этот счёт] стандарту -- ничто. По этому пути -- хотите шарить -- заводите общий подкласс, т. е. сначала свяжите классы хотя бы опосредованно.

374

UML SysML и пр. / Re: Диаграмма состояний: choice vs junction

« : 22 Августа 2016, 01:23:22 »

Проблема стандарта в том, что эти вершины-псевдосостояния и звенья-псевдопереходы для авторов стандарта как бы заслонили тот факт, то [настоящая] диаграмма состояний описывает табличку [настоящих] переходов между [настоящими] состояниями.  В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам. Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.

375

Примеры / Re: Структура обобщений более сложна, чем иерархия - как диаграммировать

« : 20 Августа 2016, 12:44:50 »

Перечёл у Рамбо обсуждение обобщений. Выглядит странно на фоне стандарта 2.5.  Стандарт говорит о том, что классификаторы могут расшаривать экземпляры при {overlapping}, но не уточняет, что для этого надо.   Ну, то есть, как на диаграмме объектов нарисовать этот самый расшаренный экземпляр? Стандартная метамодель UML разобраться нисколько не помогает. По ней -- связывай экземпляр с любыми классификаторами и всё. Никаких тебе ограничений.
По [моему пониманию] Рамбо ограничения {overlapping/disjoint} говорят о том, какие обобщения можно проводить между подклассами и их наследниками. Если мы хотим запретить "склеивать" ветки в поддереве наследования, то пишем {disjoint}, иначе ничего не пишем и получаем по умоланию {overlapping}. Разница между написанным в стандарте и этой трактовкой в том, что экземпляры не могут просто так шариться. Сначала придётся завести класс-наследник у двух подклассов, а затем только экземпляры этого класса (его наследников и других, таких же как он) могут быть расшарены. Пока такого класса нет, нет и реальной возможности использовать расшаренный экземпляр, а декларируемая стандартном возможность  остаётся только теоретической.
Неясно как в свете UML 2.5 выглядят примеры Рамбо в параграфе 4.6.3. Он словно ломится в открытую дверь усложняя модель.