16

Для всех / Re: Поиск удобной нотации для отображения зависимостей объектов

« : 15 Июня 2022, 15:45:15 »

OCL вроде не поддерживает навигацию по тернарным ассоциациям.

Поддерживает, но кривую. Другими словами, не поддерживает _должным_ образом_, на мой взгляд.
ОК. Дефект исправляем. Превращаем тернарную ассоциацию в класс тернарной ассоциации. Для него есть allInstances() и доступ ко всем концам.
Нашёлся ещё такой файлик, проясняющий по N-арным ассоциациям и OCL.
https://www.eclipse.org/forums/index.php?t=getfile&id=25690
(у меня скачался по VPN)
Там же дан другой рефакторинг решения -- материализация связи.

17

UML SysML и пр. / Re: UML 2: Activity diagram: Отличие элементов действий

« : 15 Июня 2022, 03:14:16 »

Тема -- жир для некрокопателей.
Behavior -- это глыба, про которую у нас может быть повод нарисовать диаграмму деятельности / диаграмму состояний / диаграмму взаимодействия, чтобы прояснить, что там внутри.
Opaque Behavior -- это глыба, устройство которой мы не хотим описывать визуально на UML (это так в стандарте сформулировано). Её описание мы составим на _текстуальном_ языке, не являющимся UML (вероятно, авторы стандарта считают, что UML может быть текстуальным, невизуальным).
Action -- это кирпичик, строительный материал при описании глыб -- Behavior-ов. Кирпичик проще глыбы, настолько, что для него собственная диаграмма не нужна.
Opaque Action -- это кирпичик с пояснением/телом на текстуальном языке, не являющимся UML. Эти Action-ы используются чаще всего. Авторы стандарта даже считают, что при рисовании диаграмм деятельности (или диаграмм состояний) рисовальщик сначала кладёт Opaque-кирпичик, кумекает, и потом заменяет на что-нибудь более приличное (вспоминаем Рамбо: "В ставке Гитлера все...").
Add Feature Value Action -- это кирпичик не требующий пояснения, т. к. про него всё поясняет UMLьный стандарт. У него есть входной пин. На пин приходит значение. Когда кипричик запущен, он присваивает это значение в поле объекта (иногда затирая старое, если оно было).
Call Behavior Action -- это кирпичик (не требующий пояснения и т. д.). Он запускает чего-то сложное, то есть глыбу-Behavior, для которой может быть нарисована своя UML-диаграмма. Запуск может быть синхронным или асинхронным. Если запускаемое поведение является деятельностью, то на кирпичике ставят визуальный значок-"рубильник". На практике, если диаграмма деятельности получается большой, то бьём её на части и на основном осколке ставим Call Behavior(Activity) Action-ы как ссылки на осколки-продолжения.
Call Operation Action -- это кирпичик (не требующий пояснения и т. д.). У него есть входной пин. На пин приходит объект. Когда кирпичик запущен, он посылает этому объекту сообщение, вызывающее определённую операцию этого объекта.
Create Object Action -- это кирпичик (не требующий пояснения и т. д.). У него есть выходной пин. На пин выдаётся экземпляр класса, создаваемого, когда кирпичик запущен. Это голенький экземпляр объекта, у которого нет никаких значений, ссылок. Примечательность этого кирпичика в том, что он служит не только на диаграммах. С его помощью стандарт UML объясняет жизненный цикл экземпляров объектов.
Value Specification Action -- это кирпичик (не требующий пояснения и т. д.). У него есть выходной пин с именем result. На него выдаётся значение, которое является результатом вычисления спецификации значения (например, выражения). Само вычисление стартует, когда кирпичик запущен. Пример: пишем выражение "1". Получаем Value Specification Action-кирпичик, выдающий при его запуске единицу.

18

Для всех / Re: Алгоритмизация

« : 15 Июня 2022, 00:49:03 »

ДМК-Пресс выдало на гора перевод HtDP на русский.
https://dmkpress.com/catalog/computer/programming/978-5-93700-926-3/
https://htdp.org/

19

Для всех / Re: Поиск удобной нотации для отображения зависимостей объектов

« : 15 Июня 2022, 00:43:23 »

OCLь нам в помощь.)

20

Для всех / Re: Поиск удобной нотации для отображения зависимостей объектов

« : 13 Июня 2022, 23:49:08 »

Некрокопания псто.
Группы изображаем как классы: Material, Method, Tool.
Соединяем их классом тернарной ассоциации Matches
Material-0..*---┓
Method-0..*---⃟-- -- --Matches
Tool-0..*-------┛
Чтобы были тройки вместо NULL заводим объекты-плейсходлеры undefined-material:Material, undefined-tool:Tool, undefined-method:Method.
Конкретные тройки связанных экземпляров рисуем на диаграмме объектов (есть лакуна в стандарте UML по части того, как должно рисовать тройки, соединённые экземпляром тернарной ассоциации). В книгах авторы просто повторяют то, что на диаграмме классов, полагая, что если экземпляр бинарной ассоциации выглядит также, как она сама, то это справедливо и для тернарной.

Нормальной онлайн-рисовалки, как выяснилось, нет.

21

RUP EUP AUP OpenUP / Re: Практика использования RUP. Или бег на месте...

« : 07 Июня 2022, 16:43:35 »

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

22

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 04 Февраля 2022, 18:56:42 »

В продолжение про вложенное / владеемое.
В стандарте 2.5.1 есть иллюстрация 11.48. Там не класс, а компонент, но можно видеть, что полоска с внутренней структурой и полоска со вложенными определениями классов нарисованы отдельно.
И можно осознать, что компонент не связан композициями со своими частями из внутренней структуры. А класс, выходит, связан. Но это вытекает не из картинки (т. к. они визуально схожи), а из свойств класса. То есть это положение выводимое, а не определяющее. Ну и всё такое.

23

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 04 Февраля 2022, 18:37:02 »

Не могу попробовать VP. ...
Подозреваю, что VP работает так же.

Да, верно. Мы видим, как конкретный синтаксис, осязаемый руками/курсором, начинает превалировать над абстрактным.
Можно припомнить, что даже бинарная ассоциация может быть нарисована с ромбиком по середине. И задуматься, сколько обобщений нужно проводить -- к каждому полюсу или к ромбику?
VP ещё позволяет мощности указывать с обеих сторон хвоста, растущего из ромбика в сторону класса. У кого-то читало, как это можно осмысленно использовать при арности N>2.

24

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 03 Февраля 2022, 00:39:11 »

Гуру UML-стандартов Kirill Fakhroutdinov завёл отдельное описание "вложенных классов": https://www.uml-diagrams.org/nested-classifier.html
Пишу об этом, т. к., например, вложенные пакеты в другом пакете UML позволяет рисовать внутри рамок этого пакета. То же справедливо для владеемых пакетом элементов (т. е. классов, типов и проч. описанных в самом пакете). К слову вложенные пакеты не являются владеемыми. Понятия вложения и владения в UML 2.x начали расходиться по смыслу. В UML 1.x это были синонимы. Метамодель UML разрешает классу вложенные классификаторы, но не объясняет, как их изображать. Fakhroutdinov даёт возможную версию с явной линией, заканчивающейся позитроном. VP разрешает так рисовать, но также он разрешает вложенный класс помещать внутрь рамок класса на диаграмме составной структуры (рисуя при этом предупреждающий знак, но съедая нарисованное). В обоих случаях в дереве модели вложенный класс появляется как дочерняя вершина класса, в который он вкладывается.
Учитывая написанное, можно полагать, что визуально вложенные в рамки класса другие классы являются вложенными, в смысле UML (их описание действует внутри пространства имён объемлющего класса).
VP позволяет рисовать к вложенному классу ассоциацию от объемлющего класса. Так что изначальная диаграмма может иметь место, если классы вложенные и если к ним провести таки композиции. 

25

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 02 Февраля 2022, 22:38:15 »

Офтопик. Интересно VP работает наследование между тернарными ассоциациями. Вдруг, оказывается, что обобщение соединяет в таком случае не ассоциации, а их отдельные хвосты. Ещё VP позволяет соединять обобщениями ассоциации без учёта их арности. Тернарная может стать наследницей бинарной. Ну, то есть, в этой части VP -- всё ещё рисовалка по большей мере.

26

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 02 Февраля 2022, 22:08:20 »

Фигасе, VP тоже научилось наследованиям между ассоциациями. Спасибо за пинок в верном направлении.
Мы смотрим на 14-33 немашинным взглядом. Если делать модель в расчёте на скармливание какой-нибудь софтине, то и не такое рисуется (иногда даже не рисуется, так как модель не содержит диаграмм, являясь лишь деревцем в проводнике.

27

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 02 Февраля 2022, 13:36:31 »

Изначально цитата, понятно, взята из "В бой идут одни старики". Произносит её механик Макарыч (Алексей Смирнов). Что-то близкое по смыслу Рамбо сказал Бьянкуцци и Уордену, а они записали в своей книге "Пионеры программирования" https://vk.com/wall-54530371_793 в главе об UML. Двое других из "троих друзей" были настроены не так воинственно.
14-33 мне тоже нравится, в частности, тем, что мне неизвестна UML-среда (а не графическая рисовалка), позволяющая это нарисовать. В реальной среде возможны либо redefines-ы на полюсах, либо подвески классов ассоциаций и обобщения между ними.
Допущения в первоначально составленной модели прояснились. Не думаю, что хоть чего-то стоят мои уточнения к ней. Было приятно потрындеть, спасибо.

28

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 01 Февраля 2022, 23:55:02 »

С тех пор прошло много времени и Рамбо сказал своё знаменитое "В ставке Гитлера (т. е. в IBM) все сумасшедшие", давая интервью о том, почему UML3 не будет.
В нынешнем стандарте истребили следы того, что рамка пакета или компонента и рамка класса или кооперации вели себя схожим образом. Внутри рамки класса не может быть другого класса или типа. Внутри компонента может.
2 оконечные точки или одна зависит от того верим ли мы в LSP, строя модель. Почему-то кажется, что традиционный способ за-redefine-ть периоды, входящие в состав "без промежутков", указав, что у них точка становится выводимой.
Попутно замечу траблы (14-31) одного из трёх друзей относительно мощностей при полюсах тернарной ассоциации. Быть может, опечатались.

29

Задачи студентов / Re: UseCase, описывающий процесс авторизации пользователя на сайте

« : 31 Января 2022, 15:54:08 »

Некротрединга псто.
Название ВИ должно отражать то, что в нём происходит. Кажется, что Ваши ВИ "Upload file" и "Download file" в переводе на русский не должны содержать в названии "Получить доступ", т. к. цель в обоих случаях другая (чтобы пачки данных переместились).
Само по себе получение доступа, после того как юзер залогинился, представляет собой один шаг системы ("чекнуть права учётной записи, от имени которой пришёл запрос".
Сценарий upload-а, как и сценарий download-а скорее всего имеет альтернативный поток, хотя бы один.
Постусловие не может быть дополнительным шагом, который доделывается после того, как выполнение ВИ завершилось. В самом сценарии должны быть шаги обеспечивающие истинность постусловия. Мы видим довольно сомнительное описание ВИ Download в котором шаг 3 описан примерно так: User осуществляет download. Это какая-то дурная рекурсия. Сам сценарий составлялся ради того, чтобы по шагам раздробить download, а не для того, чтобы констатировать, что этого сделать нельзя и что download есть download.

30

UML SysML и пр. / Re: Нотация структурированного классификатора для изображения композитной агрегации

« : 31 Января 2022, 15:39:02 »

Пример интересный, поэтому лезу в раскоп.
По идее (если ориентироваться на картинки из стандарта), внутри должны быть роли (и/или части), которые не являются классами. То есть класс Период должен лежать снаружи, а его имя должно использоваться как тип у роли/части.
То, что названо типом периода, на мой взгляд, больше похоже на последовательность периодов, т. е. на некоторый контейнер.
Вероятно, у периода всегда есть обе оконечные точки, и если периоды входят в состав некоторого контейнера, то одна из точек является выводимой.
Вероятно, периоды не тянут на классы, а являются структурированными типами (<<datatype>>). Например, в примере дубли одного и того же периода, входящие в состав разных контейнеров должны быть различными экземплярами или одним и тем же экземпляром?