Это сообщение я написал до того, как получил два последних ответа в топике, которые практически уже содержат ответы по некоторым моментам данного. Что-то теперь следовало бы в нем изменить, но опасаюсь, что пока буду исправлять, это тоже успеет устареть. Очень боюсь истощить Ваше терпение, но один этот разговор думаю стоит недель, если не месяцев самоварения. Мне кажется, он может помочь и другим новичкам, так как вряд-ли мои вопросы и сомнения уникальны. А на теперь уже предыдущие два ответа, я напишу отдельно.
Если честно, все равно не могу просечь в чем проблема?
Проблема в том, что проковырявшись уже достаточно долго в книгах, факах и хелпах, познакомившись с большим количеством сущностей UML и вооружившись Sparx, я так и не сумел составить какой-либо вразумительный общий образ использования дисциплины (не теории, а практики). Я опасаюсь, что разговор переходит в оффтопик, но ответ на ваш настойчивый вопрос лежит именнно в этом. Одновременно, большое спасибо за Ваши следующие вопросы, надеюсь они помогут мне задавать свои более вразумительно.
Что же вы все-таки хотите? Показать некую связь некоего ВИ с неким классом? Так Вам уже много способов дали. Причем denis-itk дал Вам чисто классический способ через кооперации (во многих местах можно почитать).
Можете не верить, но видимо я в эти места не попадал… Однако прочтя советы denis-itk, я тут же отправился в Sparx с намерением ими воспользоваться. На данном, очень низком этапе своего развития, слова о кооперации классов в контексте какого либо ВИ в моем представлении приобрели образ некоего объекта Collaboration в качестве контейнера в виде рамки на диаграмме, в который следует поместить некие классы, и связать уже эту рамку с ВИ. Но, как оказалось, в диаграмме классов, в ее наборе, нет элемента типа Collaboration … Ладно, зато такой элемент есть в диаграмме ВИ. Попробовал здесь создать Collaboration, и в него из дерева модели перетащить … что? Речь ведь идет об объединении классов … Ну, перетащил в него класс. – На Collaboration возникла пупырышка с название Port (…?). Я понял, что опять делаю что-то не то …
Не нравятся кооперации, используйте трассировки, не нравятся трассировки, изобразите реализации. Не нравятся реализации - сделайте просто гиперссылку одного объекта на другой. Ну что еще посоветовать, можно добавить теги, связать эти теги и как-то прослеживать связность...
Я думаю, что первая проблема новичка не в том, что он не знает всех кнопок (меня уже очень давно не волнуют подобные проблемы), а в том, что иногда долго не удается уловить самой базовой логики данной области знаний (при том, что уже начитался и о достаточно специальных ее деталях). Я думаю дело в том, что авторы-источники знаний, просто упускают излагать информацию, представляющуюся им тривиальной, но которая на самом деле и составляет базовый контекст, в котором только и становится понятно то, что они излагать находят нужным и интересным… Это явление повсеместно. Каждый знает это по себе: берешь книгу в руки в первый раз – все совершенно непонятно, как на китайском языке. Открываешь ту же книгу через пару лет – и диву даешься, что там могло быть непонятным с самого начала … А все дело именно в знании контекста, – объективно – это самое элементарное, а дается - с наибольшей кровью, потому что доступные источники, как правило, это опускают. Вот что мне надо (по очень большому секрету). Извините, что получается так длинно, но это мой первый топик здесь и я (опять же!) еще не знаком с контекстом данного форума (как форума, а не UML), и лишь честно пытаюсь исчерпывающе отвечать на вопросы.
Теперь о диаграммах - это вообще что? Что это за ВИ "Свободные остатки"?
Я хотел отобразить ключевой объект, который автоматически формируется в процессе выполнения функций одними пользователями, и от которого зависят возможности других пользователей при исполнении ими их функций.
Что это за зависимости "создание"?
Прецедент, который "создается", автоматически инициируется в транзакции выполнения родительского прецедента. Но затем с ним работает (редактирует) другой пользователь.
И что это за компот из "создания", "include" и "invokes".
Думаю что "компот" – это следствие незнания того самого базового контекста, о котором и пытаюсь получить, прямо или косвенно, любые сведения. Например, я четко знаю что такое "эклектика", но только благодаря тому, что я знаю соответствующий контекст эстетики. А вот что такое "компот" приминительно к UML – очень хотел бы узнать.
Кстати а почему include в императиве, а invokes в 3 лице?
Потому что Вы первый, кто сказал мне, что это плохо
Создание ТТН непременно включает Отгрузку со склада ГП?
Да. ТТН это только контейнер с собственными товарно-транспортными реквизитами. Пользователь вручную, из списка допустимых Отгрузок, выполненных ранее кладовщиками на разных складах ГП, включает некоторые из них в данную ТТН в качестве оснований для Приложений к этой ТТН (собственно детальных списков продукции)
А что такое за атрибут Размер(Заказ)? Отличается Размер как атрибут от Размера как класс?
Из-за этого Размера весь сыр-бор. Не очень понимаю вопрос. Предполагаю (но это еще не точно), что должен быть создан класс "Размер_Заказ", который позволит где необходимо в прочих классах, создавать ссылочные аттрибуты на него, дающие доступ к значениям аттрибутов Заказчик, Длина, Ширина и пр. класса "Размер_Заказ". (дело в том, что существавшее до сих пор производство – чисто конвеерное многосерийное производство (стеклопосуда и хрусталь), не предполагавшее на этапе производства (более 100 лет существования) никакого специфицирования по потребителям, а здесь вдруг возникло производство картона (и упаковок из него, но это отдельная песня), включающее еще и его нарезку в любом формате в качестве дополнительного потребительского сервиса…).
Явная связь класса с прецедентом - бред?