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

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - [прилетело НЛО и...]

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »
256
Диаграмма составной структуры позволяет явно указать, является ли объект-часть вложенным в объект-целое.
Связь помещения с домом не тождественна композиции. Композиция может обладать стационарностью ({frozen}), а может нет .

257
Композиция не тождественна связям металлов в составе сплава.
Можно представить, что Группа -- это часть Рисунка, а частью Группы является (другой) Рисунок. Композиция/агрегация не накладывает ограничения на сами классы и связи между ними. Накладываются ограничения на соединения между экземплярами классов, связанных композицией/агрегацией. Правда, мощности всё же надо указывать верно, чтобы не возникало противоречий.

258
Григорий вешал рекламу недавно.

259
Быстрее так, ВИ класса Продажа описывают поведение его экземпляров и экземпляров его частей (Единиц и проч.) при обработке запросов, пришедших извне. Например, со стороны класса Клиент.
Речь не о том, чтобы всю систему описывать до мельчайших винтиков. Джекобсон/Якобсон смог зашить в стандарт изобретённое им (а не авторами методик по работе с требованиями через ВИ) понимание того, что такое ВИ. 

260
Смешная диаграмма про воинов продолжает работать в рекламе курса.
Уважуха. ОО-анализ на языке, похожем на UML, отчего бы нет.

261
Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?
По стандарту вариант использования может быть соединён связью с классификатором "сабджектом", которым может быть класс. Т. е. у класса могут быть "свои" варианты использования, описывающие способы взаимодействия с его экземплярами. Связь варианта использования с "сабджектом" изображается размещением ВИ внутри рамок его "сабджекта" (например, класса).
[Улечу, пока не пришли линчеватели из веток о том, чем является и чем не является ВИ.]
P. S. VP позволяет довольно много вольностей в соединении ВИ c классами связями разных типов. Попробуйте, будете удивлены. [Почти все, кроме допускаемой стандартом.]

262
Спустя 7 лет VP позволяет двуромбовые композиции. Полёт нормальный.)

263
Цитировать
композиция - связь несимметричная, это означает...
... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
В общем случае, ошибки, на которую указано, нет. Экземпляр B может быть целым для экземпляра ConcreteData. Этот экземпляр ConcreteData может быть целым для другого экземпляра В. В общем случае между классами A и B можно нарисовать две композиции: у одной ромб рядом с A, у другой -- рядом с B. 

264
[Кручу-верчу, запутать хочу.]

Многие ко многим может быть часть-целое, если это агрегация. Например, Группа◇-0..2---2..7-Работник. То, что две группы могут расшаривать между собой работника (работников) агрегация допускает.

265
[Раз пошла такая тема]
Является ли объект-часть вложенным в объект-целое или нет, зависит от "многих гитик". Композиция так таковая (без рассмотрения её мощностей) в плане существования частей накладывает ограничение лишь на то, что все части целого, какие не успели отцепиться в момент удаления целого, также удаляются.

266
Реализация / Re: Композиция, Агрегация
« : 14 Сентября 2017, 22:00:11 »
Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?

[Трёпа ради прилечу.]
Если композиция такова, что объект-целое обязателен, и объект-часть обязателен, и объект-часть не может существовать сам по себе, например, Здание◆-1---1..*-Этаж, то обязательный этаж здания должен создаваться в конструкторе здания. Любой строитель подтвердит. (Экзотику, когда берут этаж от одного здания и передают в другое, не рассматриваем.)
Если композиция такова, что объект-целое необязателен, , а объект-часть обязателен, и объект часть может существовать сам по себе, например, Авто◆-0..1---3..8-Колесо, то три обязательных колёса можно создавать раньше авто и передавать ему при вызове конструктора.
Т. е. исходный вопрос не про композицию/агрегацию, а про композицию со специфическими мощностями.

267
Небольшой довесок.
Цитата: Wiegers 'Software Requirements 3rd Edition'
One author of a book on use cases told me that extend and include are best discussed by friends over beer.
Или в переводе
Цитировать
Один автор книг о вариантах использования сказал мне, что такие связи между ВИ лучше всего обсуждать с друзьями за бокалом пива.

268
Как возможные промежуточные итоги:
Описание метамодели UML и метамодели OCL можно рассматривать как источник для установления прагматики некоторых конструкций UML.
В стандарте UML есть ошибки.
Утверждение, что инвариант истинен всегда следует принимать без фанатизма. Если в модели есть динамика, то в ней обычно допустимы короткие отрезки времени, в течение которых целостности нет.

269
Почему связь Service - - -> Department, Workshop.  Ведь в классе Service есть метод который обращается к интерфейсу Subdivision. А уже непосредственно из интерфейса к классам реализующих его.
В коде в описаниях метода Service::main упоминаются классы Department и Workshop как типы локальных переменных. Этого достаточно для зависимостей. Если стоит цель сделать Service независимым от Department и Workshop, то workshop1 и department1 должны иметь тип Subdivision, а их создание следует поручить какой-нибудь фабрике (которая будет знать про Department и Workshop и зависеть от них). Фабрика позволит другим классам получать экземпляры классов, реализующих интерфейс, не зная имён этих классов и не завися от них.

Таким образом хотелось показать "полиморфизм".
Полиморфизм есть в Service::getFoodCost, но зависимость от классов, реализующих интерфейс, сохраняется из-за main.

Примеры тут.

270
Статья [у меня] не открывается.
В текущей версии метамодели include и extend подвешены подклассами к DirectedRelationship как прямые наследники. При этом не сказано явно про disjoint. Следовательно, либо авторы метамодели не перешли на новые дефолтные свойства обобщений, либо они полагают, что какой-то include может быть также extend'ом. Во втором случае возникает пикантность при обсуждении различий между видами связей ВИ.
По синтаксису [предлагаемому Коберном] include напоминает гиперссылку. Никакой inline подстановки (как и копи-пасты описаний ВИ) не происходит. Тем более, компиляции. Неясно, что имели в виду авторы реплик.
По прагматике include близок в вызову процедуры, а extend -- к обработке исключения.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 »