121

Примеры / Рефакторинг диаграммы состояний

« : 08 Ноября 2016, 17:40:01 »

Есть исходная диаграмма (вложение 1).
Поскольку из ВСЕХ подсостояний состояния "забирание" есть переходы по событию "сохранить" с очень схожими свойствами, хочется повысить выразительность диаграммы (графически подчеркнуть наличие перехода по событию "сохранить" из любого подсостояния и схожесть результатов такого перехода).
Для подсостояний "ОК" и "ошибка" решение простое: объединяем их композитным состоянием "нет" и переход "сохранить" делаем от этого композитного состояния (вложение 2).
Для подсостояний "ОК" и "есть" тоже есть вариант: объединяем их композитным состоянием с псевдосостоянием истории и переход делаем от этого композитного состояния к псевдосостоянию истории (вложение 3).
Для всех подсостояний получилось как-то "некрасиво" (вложение 4).
Может есть идеи?

122

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 12 Октября 2016, 15:22:30 »

В общем случае может быть использование B в нескольких квалификаторах. Чтобы зависимость была одна, она должна быть от C.

123

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 10 Октября 2016, 17:37:40 »

Заметил ошибку в диаграмме: квалификатор не с той стороны. Исправление во вложении 1. Там же отображена зависимость (в соответствии с

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

).

Привычнее видеть, что у класса есть атрибут перечислимого типа и проведена зависимость от класса к типу. Привычка идёт от увиденного в книгах и т. п. В стандарт не лазило. Как по мне, data type и enumeration недоклассификаторы, в том смысле, что их "экземпляры" не соединяются с экземплярами классов, а являются значениями их слотов.

Все три диаграммы во вложении 2 эквивалентны. И неважно, является B классом или enumeration.

124

UML SysML и пр. / Re: Внутренний переход параллельного композитного состояния

« : 09 Октября 2016, 11:54:09 »

Сомнительным кажется соединение класса с перечислимым типом с помощью ассоциации (SimpleState-*--*-TypeStateBehaviour).

Что вызывает сомнение - то, что перечислимый тип может участвовать в ассоциации?

М. б. соединить SimpleState со  StateBehaviour, а TypeStateBehaviour сделать типом квалификатора при этой связи?

Для меня это эквивалентное преобразование: класс-ассоциацию (многие ко многим) всегда можно заменить на ассоциацию от одного из ассоциируемых с квалификатором по другому из ассоциируемых (картинка во вложении).

Стандарт против внутренних переходов по завершению. А, собственно, почему?

Можно предположить, что дело в "звучании" терминов - "ФИНАЛЬНОЕ состояние", "переход по ЗАВЕРШЕНИЮ". Явно звучит "Конец", "Финиш", "Уже всё". И тут внутренний переход, что явно предполагает продолжение - непорядок!.

125

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

« : 31 Августа 2016, 17:13:02 »

Не подскажете, где можно почитать про такой стиль построения диаграмм классов?

https://www.utdallas.edu/~chung/Fujitsu/UML_2.0/Rumbaugh--UML_2.0_Reference_CD.pdf рис.14-84

126

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

« : 30 Августа 2016, 18:16:22 »

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

В реальности приходилось сталкиваться только с 2 целями:

• оценка объема работы - тогда достаточно определить состав классов и состав ассоциаций
• собственно разработка: от UI до тестирования - тогда подробно, полно и непротиворечиво

Понимаю, что может быть и по-другому и хочу узнать - как именно.

127

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

« : 30 Августа 2016, 18:03:53 »

Ну коли уж пошла такая пьянка... А как подобные условия отображаются на диаграммах? Есть ли примеры?

Практически любое ограничение можно выразить в виде комментариев или на OCL.
Диаграмно тоже можно.
[1] в предыдущем сообщении.
[1], [2] и [3] вместе - во вложении.

128

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

« : 30 Августа 2016, 10:37:38 »

Не совсем в тему.
По моим представлениям диаграмма (для определённости возьмём исправленную - из второго англоязычного издания) представляет собой незаконченный артефакт (даже как просто диаграмма). По ней возникают вопросы:

• Преподаватель может быть деканом факультета, на котором не работает?
• Студент может посещать курс, факультет которого не входит в ВУЗ, в котором студент обучается?
• Преподаватель может читать курс, если не работает на факультете курса?
• Студент посещает курс или чтение этого курса преподавателем? Это происходит в рамках ВУЗа?

Определение подобных вопросов по уже полученной информации (диаграммирование очень помогает!) - существенная часть работы аналитика. Или я ошибаюсь?

129

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

« : 22 Августа 2016, 16:24:54 »

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

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

130

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

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

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

Кроме overlapping/disjoint есть ещё complete/uncomplete, а также абстрактность класса. Абстрактность требует(?), чтобы все/хоть одна(?) SetGeneralization этого класса была complete.

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

В стандарте "9.8.3 Semantics" есть абзац "It is important to keep in mind that InstanceSpecification is a model element and should not be confused with the
instance that it is modeling. As an InstanceSpecification may only partially determine the properties of an instance,
there may actually be multiple instances in the modeled system that satisfy the requirements of the
InstanceSpecification. On the other hand, an InstanceSpecification may model a situation which is not actually
supposed to occur in the modeled system, in which case no instance meeting the requirements of the
InstanceSpecification may ever actually occur in the system."
Я понял это так: идёт речь не об экземпляре, а об элементе диаграммы, который, строго говоря, может и не быть полноценным экземпляром.

Ну, то есть, как на диаграмме объектов нарисовать этот самый расшаренный экземпляр?

9.8.4. в первом абзаце говорит о нескольких классификаторах через запятую.

131

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

« : 22 Августа 2016, 10:33:25 »

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

По-моему так и надо, если:

• граф получается наглядным
• есть хорошие правила, которым граф должен соответствовать (синтаксис)
• есть хорошие правила получения автомата из графа (семантика)

Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.

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

132

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

« : 22 Августа 2016, 10:06:20 »

Ну, то есть, как на диаграмме объектов нарисовать этот самый расшаренный экземпляр?

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

По ней -- связывай экземпляр с любыми классификаторами и всё. Никаких тебе ограничений.

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

Разница между написанным в стандарте и этой трактовкой в том, что экземпляры не могут просто так шариться. Сначала придётся завести класс-наследник у двух подклассов, а затем только экземпляры этого класса (его наследников и других, таких же как он) могут быть расшарены. Пока такого класса нет, нет и реальной возможности использовать расшаренный экземпляр, а декларируемая стандартном возможность  остаётся только теоретической.

Путь с обязательным заведением класса-наследника неприемлем. Кстати у Рамбо-Блаха рис.4.15. неточен - нет гарантии, что все Employee, которые одновременно FullTimeEmployee и IndividualContributor попадут в FullTimeIndividualContributor.

Неясно как в свете UML 2.5 выглядят примеры Рамбо в параграфе 4.6.3. Он словно ломится в открытую дверь усложняя модель.

В параграфе 4.6.3. "Обходные маневры" делается попытка обойтись без множественного наследования и множественной классификации. По мне это даже вредно - модель должна соответствовать предметной области, а не используемому инструменту (язык программирования).

133

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

« : 21 Августа 2016, 13:02:20 »

трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей

Класс! Я только чувствовал, что так должно быть, а теперь получил и обоснование.
К сторожам можно добавить триггеры и действия на переходе (более удобной записи переходов: триггеров, сторожей и действий). Триггер не более, чем 1 на всей цепочке переходов через junction, выходящей из состояния (для остальных цепочек триггеров не может быть).
Цепочки переходов через junction не могут быть циклами (через choice могут!).

134

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

« : 18 Августа 2016, 19:27:28 »

Условия переходов из choice проверяются на момент входа в него, переменная А к этому моменту имеет значение 1.
Условия переходов из junction проверяются на момент выхода из настоящего (не псевдо) состояния, переменная А к этому моменту имеет значение 0.
Строго по этим правилам в диаграмме 3 произойдет переход в State3. Но это как-то неестественно (подряд два перехода с одним и тем же условием, но по одному идём, а по другому - нет).

135

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

« : 17 Августа 2016, 20:26:01 »

На диаграмме 1 из State1 по событию b произойдет переход в State2.
На диаграмме 2 из State1 по событию b произойдет переход в State3.
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?