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

×


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

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


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

Страницы: « 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 »
271
[Раз пошла такая тема]
Является ли объект-часть вложенным в объект-целое или нет, зависит от "многих гитик". Композиция так таковая (без рассмотрения её мощностей) в плане существования частей накладывает ограничение лишь на то, что все части целого, какие не успели отцепиться в момент удаления целого, также удаляются.

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

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

273
Небольшой довесок.
Цитата: 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.
Или в переводе
Цитировать
Один автор книг о вариантах использования сказал мне, что такие связи между ВИ лучше всего обсуждать с друзьями за бокалом пива.

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

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

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

Примеры тут.

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

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

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

278
Благодарю, внес изменения.
Шлю свой поклон.

279
Примеры
Здесь обсуждаются любые примеры моделей, составленных в любых нотациях.

Нововведения
Все новое в сферах бизнес- и системной аналитики, а также IT-индустрии.

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

Теория моделирования и нотации
Теоретические основы моделирования, системного анализа. Обсуждения нотаций моделирования и нововведений в них.

280
На других планетах мои замечания о содержании подфорумов считают самодеятельным модерированием и пресекают.)

281
Спасибо, а не хотите стать модератором?
Нет. Если бы хотело, то выбрало бы себе ник "UML Metamodel Наци".)
Кстати, а кто самодеятельно модерирует?
Моё замечание о "рокировках" можно счесть самодеятельностью такого рода.

282
Отчего бы лишний раз не похвалить книгу Рамбо и Блахи. Как у руководства по диаграммам классов и диаграммам состояний у неё мало соперниц. И как у сборника задач по UML. Другое дело, что перевод условий задач таков, что "методичку"-решебник, выпущенную для преподов издательством Pearson, использовать вместе с переведённой книгой затруднительно. К перетолмаченным формулировкам условий авторские решения часто не подходят. 

283
Идея по улучшению форума:
На заглавной странице есть описания разделов. Предлагаю из описаний разделов "Примеры" и "Нововведения" убрать упоминание UML. Может быть, это поспособствует тому, что смена ГОСТов не будет казаться umlьным нововведением, а приглашение проверить IDEF-пример -- обсуждением нотации. Добавлю, что, на мой вкус, некоторые темы про нотации, оказавшиеся в "Примерах", неплохо бы "рокирнуть" с темами про задачи из "Теории моделирования и нотаций".
P. S. + Внести в правила пункт о запрете попыток самодеятельного модерирования со стороны рядовых участников.))

284
На практике в RUP-проекте 4 контрольные точки. Продвижение между ними -- это и есть RUP-этапы, т. е. фазы. Поскольку между некоторыми контрольными точками "расстояние" велико, фазы можно/нужно делить на итерации. Каждая итерация -- "каскад в миниатюре", похожий на описанное Вами. Отличие в том, что ЖЦ -- не просто повторение итераций, завершающееся релизом продукта. По RUPу полно публикаций, в том числе на русском, где всё это изложено. Коротко и по существу можно видеть здесь: http://panda.ispras.ru/~kuliamin/lectures-sdt/sdt-book-2006.pdf  стр.:35-44.

285
Множественность длины [0..1], поэтому тип длины такой, что включает и null-значение.
При такой мощности мне придраться не к чему.

Все равно не уловил.
Там указывается, что null можно использовать не только как пустое значение, но и как неопределённое значение. Если в Client::email положили null (например, конструктором/init'ом), то это может явно указывать, что емэйл неизвестен. Из  того, что авторы стандарта OCL пишут "may, for example, be assigned to an attribute", можно сделать вывод, что null не возникает сам по себе как неопределённое значение атрибута. Авторы метамодели UML полагают, что возникает, но не оговаривают это в своём стандарте.

хотелось обойтись без конструкторов
Попадались попытки расширения языка в сторону темпоральности, но я внимательно в эту сторону не смотрело.


Страницы: « 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 »