Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Например, можно ли (и нужно ли?) связать элемент "class" Сlass-диаграммы, с элементом "use-case" Use-Case-диаграммы (с помощью чего-то, типа прямой ссылки)?По стандарту вариант использования может быть соединён связью с классификатором "сабджектом", которым может быть класс. Т. е. у класса могут быть "свои" варианты использования, описывающие способы взаимодействия с его экземплярами. Связь варианта использования с "сабджектом" изображается размещением ВИ внутри рамок его "сабджекта" (например, класса).
композиция - связь несимметричная, это означает...... это означает, что нельзя нарисовать ромбики на обоих концах одной композиции.
Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?
One author of a book on use cases told me that extend and include are best discussed by friends over beer.Или в переводе
Один автор книг о вариантах использования сказал мне, что такие связи между ВИ лучше всего обсуждать с друзьями за бокалом пива.
Почему связь Service - - -> Department, Workshop. Ведь в классе Service есть метод который обращается к интерфейсу Subdivision. А уже непосредственно из интерфейса к классам реализующих его.В коде в описаниях метода Service::main упоминаются классы Department и Workshop как типы локальных переменных. Этого достаточно для зависимостей. Если стоит цель сделать Service независимым от Department и Workshop, то workshop1 и department1 должны иметь тип Subdivision, а их создание следует поручить какой-нибудь фабрике (которая будет знать про Department и Workshop и зависеть от них). Фабрика позволит другим классам получать экземпляры классов, реализующих интерфейс, не зная имён этих классов и не завися от них.
Таким образом хотелось показать "полиморфизм".Полиморфизм есть в Service::getFoodCost, но зависимость от классов, реализующих интерфейс, сохраняется из-за main.
