286

Задачи студентов / Re: Отношение между классами

« : 16 Сентября 2017, 12:53:22 »

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

287

ПО Аналитика / Re: Управление изменениями требований

« : 16 Сентября 2017, 12:48:01 »

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

288

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 16 Сентября 2017, 12:46:10 »

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

289

ПО Аналитика / Re: Управление изменениями требований

« : 15 Сентября 2017, 01:13:19 »

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

290

Теория моделирования и нотации / Re: Явная связь класса с прецедентом - бред?

« : 14 Сентября 2017, 23:02:15 »

Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?

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

291

Sparx / Re: Агрегация против агрегированной ассоциации

« : 14 Сентября 2017, 22:34:36 »

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

292

Задачи студентов / Re: Отношение между классами

« : 14 Сентября 2017, 22:30:05 »

композиция - связь несимметричная, это означает...

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

293

Примеры / Re: Вопрос к гуру по диаграмме классов

« : 14 Сентября 2017, 22:22:33 »

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

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

294

Реализация / Re: Реализация отношений между классами

« : 14 Сентября 2017, 22:16:54 »

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

295

Реализация / Re: Композиция, Агрегация

« : 14 Сентября 2017, 22:00:11 »

Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?

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

296

Обсуждение статей / Re: Включение вариантов использования

« : 14 Августа 2017, 16:49:48 »

Небольшой довесок.

One author of a book on use cases told me that extend and include are best discussed by friends over beer.

Или в переводе

Один автор книг о вариантах использования сказал мне, что такие связи между ВИ лучше всего обсуждать с друзьями за бокалом пива.

297

Примеры / Re: Как обозначить атрибут, значение которого вычисляется в момент создания объекта

« : 28 Июля 2017, 02:19:37 »

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

298

UML SysML и пр. / Re: Правильно ли я отобразил отношения между классами описанных на коде?

« : 26 Июня 2017, 14:17:24 »

Почему связь Service - - -> Department, Workshop.  Ведь в классе Service есть метод который обращается к интерфейсу Subdivision. А уже непосредственно из интерфейса к классам реализующих его.

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

Таким образом хотелось показать "полиморфизм".

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

Примеры тут.

299

Обсуждение статей / Re: Включение вариантов использования

« : 25 Июня 2017, 09:46:42 »

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

300

UML SysML и пр. / Re: Правильно ли я отобразил отношения между классами описанных на коде?

« : 24 Июня 2017, 17:08:45 »

Подскажите пожалуйста правильно ли я отобразил отношения между классами описанных в коде? А именно между service и интерфейсом Subdivision?

Связь с классом, описывающим тип параметра операции (как и тип локальной переменной в теле метода) -- это зависимость, а не ассоциация. Обоснование просто. Такие переменные "живут" лишь в течение вызова, в отличие от атрибута, который "живёт" время, сравнимое с временем жизни связанного объекта.
Рекомендации:
Убрать ассоциацию Service -----> Subdivision.
Добавить зависимость Service - - -> Subdivision.
Добавить зависимость Service - - -> Workshop.
Добавить зависимость Service - - -> Department.

P. S. И разбирать примеры в подфоруме про примеры.