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

×


Последние сообщения

Страницы: « 1 2 3 4 5 6 7 8 9 10 »
81
Офтопик. Интересно VP работает наследование между тернарными ассоциациями. Вдруг, оказывается, что обобщение соединяет в таком случае не ассоциации, а их отдельные хвосты. Ещё VP позволяет соединять обобщениями ассоциации без учёта их арности. Тернарная может стать наследницей бинарной. Ну, то есть, в этой части VP -- всё ещё рисовалка по большей мере.
Не могу попробовать VP. Но в MagicDraw работает так:
1.   Тернарная (и выше) ассоциация имеет отдельный знак – «ромбик».
2.   Чтобы нарисовать «хвосты» используются бинарные ассоциации между «ромбиком» и классами.
3.   Эти бинарные ассоциации и другие «обычные» бинарные ассоциации являются объектами для соединения с помощью обобщения. Можно даже сделать, что один «хвост» обобщает другой. Единственное ограничение – обобщения не могут зацикливаться.
4.   Нельзя делать обобщения между «ромбиками».
Подозреваю, что VP работает так же.
82
Гуру UML-стандартов Kirill Fakhroutdinov завёл отдельное описание "вложенных классов": https://www.uml-diagrams.org/nested-classifier.html
Пишу об этом, т. к., например, вложенные пакеты в другом пакете UML позволяет рисовать внутри рамок этого пакета. То же справедливо для владеемых пакетом элементов (т. е. классов, типов и проч. описанных в самом пакете). К слову вложенные пакеты не являются владеемыми. Понятия вложения и владения в UML 2.x начали расходиться по смыслу. В UML 1.x это были синонимы. Метамодель UML разрешает классу вложенные классификаторы, но не объясняет, как их изображать. Fakhroutdinov даёт возможную версию с явной линией, заканчивающейся позитроном. VP разрешает так рисовать, но также он разрешает вложенный класс помещать внутрь рамок класса на диаграмме составной структуры (рисуя при этом предупреждающий знак, но съедая нарисованное). В обоих случаях в дереве модели вложенный класс появляется как дочерняя вершина класса, в который он вкладывается.
Учитывая написанное, можно полагать, что визуально вложенные в рамки класса другие классы являются вложенными, в смысле UML (их описание действует внутри пространства имён объемлющего класса).
VP позволяет рисовать к вложенному классу ассоциацию от объемлющего класса. Так что изначальная диаграмма может иметь место, если классы вложенные и если к ним провести таки композиции. 
83
Офтопик. Интересно VP работает наследование между тернарными ассоциациями. Вдруг, оказывается, что обобщение соединяет в таком случае не ассоциации, а их отдельные хвосты. Ещё VP позволяет соединять обобщениями ассоциации без учёта их арности. Тернарная может стать наследницей бинарной. Ну, то есть, в этой части VP -- всё ещё рисовалка по большей мере.
84
Фигасе, VP тоже научилось наследованиям между ассоциациями. Спасибо за пинок в верном направлении.
Мы смотрим на 14-33 немашинным взглядом. Если делать модель в расчёте на скармливание какой-нибудь софтине, то и не такое рисуется (иногда даже не рисуется, так как модель не содержит диаграмм, являясь лишь деревцем в проводнике.
85
Изначально цитата, понятно, взята из "В бой идут одни старики". Произносит её механик Макарыч (Алексей Смирнов). Что-то близкое по смыслу Рамбо сказал Бьянкуцци и Уордену, а они записали в своей книге "Пионеры программирования" https://vk.com/wall-54530371_793 в главе об UML. Двое других из "троих друзей" были настроены не так воинственно.
Спасибо, книга "Пионеры программирования" вроде есть, перечитаю.
14-33 мне тоже нравится, в частности, тем, что мне неизвестна UML-среда (а не графическая рисовалка), позволяющая это нарисовать. В реальной среде возможны либо redefines-ы на полюсах, либо подвески классов ассоциаций и обобщения между ними.
1. Мне 14-33 НЕ нравится для указанной ситуации - Период связан ровно с одним ТипПериода, который имеет подтипы, значит Период тоже имеет тот же набор подтипов, причем специализация по этим подтипам является вычислимой. Это не должно требовать такого "громоздского" представления на диаграмме, как 14-33.
2. В MagicDraw 16.6 мне удалось сделать обобщение между ассоциациями.
86
Изначально цитата, понятно, взята из "В бой идут одни старики". Произносит её механик Макарыч (Алексей Смирнов). Что-то близкое по смыслу Рамбо сказал Бьянкуцци и Уордену, а они записали в своей книге "Пионеры программирования" https://vk.com/wall-54530371_793 в главе об UML. Двое других из "троих друзей" были настроены не так воинственно.
14-33 мне тоже нравится, в частности, тем, что мне неизвестна UML-среда (а не графическая рисовалка), позволяющая это нарисовать. В реальной среде возможны либо redefines-ы на полюсах, либо подвески классов ассоциаций и обобщения между ними.
Допущения в первоначально составленной модели прояснились. Не думаю, что хоть чего-то стоят мои уточнения к ней. Было приятно потрындеть, спасибо.
87
С тех пор прошло много времени и Рамбо сказал своё знаменитое "В ставке Гитлера (т. е. в IBM) все сумасшедшие", давая интервью о том, почему UML3 не будет.
Можно ссылочку и цитату?
Внутри рамки класса не может быть другого класса или типа. Внутри компонента может.
Возможные варианты отражения ситуации на диаграмме при строгом следовании стандарту:
   1. цитата: То есть класс Период должен лежать снаружи, а его имя должно использоваться как тип у роли/части.
   2. что-то похожее на рис.14-33 из того же источника 
2 оконечные точки или одна зависит от того верим ли мы в LSP, строя модель. Почему-то кажется, что традиционный способ за-redefine-ть периоды, входящие в состав "без промежутков", указав, что у них точка становится выводимой.
В Liskov substitution principle мы верим всегда. Не выходя за рамки этой веры можно:
   1. Не указывать производные (derived) элементы вообще - как и сделано
   2. Указать, что Период имеет атрибут "Конец:Дата", который для Периода типа "Без промежутков" является производным (ну тогда уж и как вычисляется)
В реальной жизни я бы скорее использовал 2., но для обозначения ситуации 1. попроще.
Попутно замечу траблы (14-31) одного из трёх друзей относительно мощностей при полюсах тернарной ассоциации. Быть может, опечатались.
Для меня мощности при полюсах n-арной ассоциации, отличные от 0..* и 1..*, всегда что-то "не то".
88
С тех пор прошло много времени и Рамбо сказал своё знаменитое "В ставке Гитлера (т. е. в IBM) все сумасшедшие", давая интервью о том, почему UML3 не будет.
В нынешнем стандарте истребили следы того, что рамка пакета или компонента и рамка класса или кооперации вели себя схожим образом. Внутри рамки класса не может быть другого класса или типа. Внутри компонента может.
2 оконечные точки или одна зависит от того верим ли мы в LSP, строя модель. Почему-то кажется, что традиционный способ за-redefine-ть периоды, входящие в состав "без промежутков", указав, что у них точка становится выводимой.
Попутно замечу траблы (14-31) одного из трёх друзей относительно мощностей при полюсах тернарной ассоциации. Быть может, опечатались.
89
По идее (если ориентироваться на картинки из стандарта), внутри должны быть роли (и/или части), которые не являются классами. То есть класс Период должен лежать снаружи, а его имя должно использоваться как тип у роли/части.
Можно и как в стандарте - не класс, а роль, но:
   1. с указанием класса
   2. с именем роли как у полюса ассоциации
   3. с множественностью роли как у полюса ассоциации
А если посмотреть https://www.utdallas.edu/~chung/Fujitsu/UML_2.0/Rumbaugh--UML_2.0_Reference_CD.pdf рис.14-84, то ...
То, что названо типом периода, на мой взгляд, больше похоже на последовательность периодов, т. е. на некоторый контейнер.
Контейнер, кроме объединения периодов, имеет собственные информационные свойства, например Наименование. 
Вероятно, у периода всегда есть обе оконечные точки, и если периоды входят в состав некоторого контейнера, то одна из точек является выводимой.
У периодов, связанных с типом периода с промежутками обе оконечные точки задаются, у периодов, связанных с типом периода без промежутков задается только точка конца, а точка начала является выводимой.
Вероятно, периоды не тянут на классы, а являются структурированными типами (<<datatype>>). Например, в примере дубли одного и того же периода, входящие в состав разных контейнеров должны быть различными экземплярами или одним и тем же экземпляром?
Тянут, в составе разных контейнеров (типов периода) дубли одного и того же периода должны быть различными экземплярами.
90
Некротрединга псто.
Название ВИ должно отражать то, что в нём происходит. Кажется, что Ваши ВИ "Upload file" и "Download file" в переводе на русский не должны содержать в названии "Получить доступ", т. к. цель в обоих случаях другая (чтобы пачки данных переместились).
Само по себе получение доступа, после того как юзер залогинился, представляет собой один шаг системы ("чекнуть права учётной записи, от имени которой пришёл запрос".
Сценарий upload-а, как и сценарий download-а скорее всего имеет альтернативный поток, хотя бы один.
Постусловие не может быть дополнительным шагом, который доделывается после того, как выполнение ВИ завершилось. В самом сценарии должны быть шаги обеспечивающие истинность постусловия. Мы видим довольно сомнительное описание ВИ Download в котором шаг 3 описан примерно так: User осуществляет download. Это какая-то дурная рекурсия. Сам сценарий составлялся ради того, чтобы по шагам раздробить download, а не для того, чтобы констатировать, что этого сделать нельзя и что download есть download.
Страницы: « 1 2 3 4 5 6 7 8 9 10 »