71

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-кирпичик, выдающий при его запуске единицу.

72

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

« Последний ответ от [прилетело НЛО и...] 15 Июня 2022, 00:49:03 »

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

73

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

« Последний ответ от [прилетело НЛО и...] 15 Июня 2022, 00:43:23 »

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

74

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

« Последний ответ от Vadim 14 Июня 2022, 16:21:51 »

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

75

Для всех / 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 по части того, как должно рисовать тройки, соединённые экземпляром тернарной ассоциации). В книгах авторы просто повторяют то, что на диаграмме классов, полагая, что если экземпляр бинарной ассоциации выглядит также, как она сама, то это справедливо и для тернарной.

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

76

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

« Последний ответ от [прилетело НЛО и...] 07 Июня 2022, 16:43:35 »

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

77

Бизнес-анализ и Целеполагание / buy virtual number receive sms

« Последний ответ от Anastasiyaflolf 03 Марта 2022, 17:58:12 »

Сегодня серфил контент инета, вдруг к своему восторгу обнаружил четкий ресурс. Вот посмотрите: бесплатные номера для смс . Для меня этот вебсайт произвел незабываемое впечатление. Хорошего дня!

78

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

« Последний ответ от [прилетело НЛО и...] 04 Февраля 2022, 18:56:42 »

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

79

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

« Последний ответ от [прилетело НЛО и...] 04 Февраля 2022, 18:37:02 »

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

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

80

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

« Последний ответ от Vadim 03 Февраля 2022, 15:54:16 »

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

Если смотреть "машинным" взглядом, то ситуация становится ещё "жэстачайшэ" - машине надо объяснить, где информационное свойство является избыточным (может/должно быть выведено - derived), а где только ограничение (constraint).
Я расцениваю 14-33 как желание отобразить:
1. 2 класса связаны ассоциацией
2. оба класса имеют одинаковый набор подклассов
3. ассоциироваться могут только одноименные подклассы
4. мощность "подчиненных" ассоциаций - такая же, как у "обобщающей" ассоциации
Пусть хотя бы с одной стороны мощность ассоциации такова, что становится обязательной (1..1 или 1..*). Тогда, например если model имеет мощность 1..1 или 1..*, то разбиение Symbol на OrderSymbol и CustomerSymbol становится выводимым из разбиения Subject на Order и Customer.
Если же с обеих сторон мощность необязательна (0..1 или 0..*), то имеем дело с ограничением.