Naf...какие критерии выделения "слева или справа" или даже у обоих?...

тут фигня такая.
если слушать дождь - то можно услышать мелодию баха или бетховена...

если о матрёшках.
а можете привести пример циклической связи из жизни?

ну например.
кошка пьёт молоко. молоко как воздействует на кошку???
или по другому. молоко должнО знать о кошке?

Чиссо моё имхо.
Цикличность - есть трабл архитектуры. И смотреть на задачу с позиции механики(когда и где нужно выделять парэнта, для того что бы убрать зацикленность), с позиции инструментария - мягко говоря не правильно.


с уважением
(круглый)

Naf...Учитель сообщает ученику задание (учитель знает об ученике), ученик решает задание и говорит его ни кому нибудь, а именно своему учителю (ученик знает, кому надо сообщить)

ок.
учитель должен владеть ситуацией, ученик=сложность задания.
а вот ученик вряд ли может выбрать контролёра на свою задачу :)
так что от ученика нужно(даже это под вопросом) натификация только. об учителе он знать не обязан. он делает (задание), он сообщает(или не сообщает а чиссто по времени и отвалил). он может вообще положить тетрадочку воооон туда апосля. более того, если он у доски работает - то судьи кто? прально - другие ученики. Т.е. имеем ещё одну сущность - задание, как минимум. через которую собственно и взаимодействуют ученик+учитель. Но ещё раз повторю - учитель владеет ситуацией процесса. а вот ученик - вряд ли, иначе он аля учитель получается. что противоречит бизнес модели всегда.

так что на мой взгляд - тут связь не равнозначная.

(круглый)

Naf...именно это и отражает переход от схемы слева к схеме справа на рисунке в начале темы

ну, Вам виднее...

(круглый)

neoddd...Если это школа молодых талантов и учителя бывшие звезды эстрады, то и учитель выбирает ученика и ученик выбирает учителя. И общаться они будут tet-a-tet.

Вы правы. Но заметьте: появилось слово если ! Это что значит? Что мы начали говорить о коне в вакууме. А не о конкретной задаче. Посему я и спросил - нарисуйте задачу. А гипотетически можно всё что хошь нахфантазировать. И почти всё будет иметь место, лишь потому, что это придумано человеком!!!

Только идё от задачи - мы никогда (заметьте!!!) не будем делать лишнюю работу. Т.е. если клиент говорит вот так и так по задаче. Что это значит? Это значит что время жизни этих сущностей ну оооооочень велико по отношению к проекту. Понимаете? Т.е. могут рушаться стены, меняться цвет стен, а вот найденные от жизни сущности = const!!!

это один из(не единственный естественно) самых главных плюсов данной методологии - уменьшения затрат на переделку, допиливание, подгонку под клиента. Её просто НЕТ!!!


удачи вам
(круглый)
ЗЫ
Я не говорю что это просто, кстати. До конца понять и прочуствовать можно только пройдя весь путь по бучу. Т.е. сущности, роли, состояния, взаимодействия, карточки, рисунки на доске и мнооооого обсуждения. без этого увы - никак в кол-ве (подчеркну обязательное применение) разработчиков. И это необходимо организовывать. Стихийно нифига не будет само. Но это уже управление людьми

neoddd...осознали потребность в супер нужной...

Вы внимательно прочитайте что Вы написали!!!
"осознали потребность в супер нужной" - т.е. речь идёт не о том, что бизнес поменялся!!! не о том, что раньше разводили кроликов а сейчас будем учитывать паровозы!!!

надеюсь намёк поняли?


расшифровываю.
ООА и ООП есть ваше спасение. как не странно звучит - это ЕДИНСТВЕННАЯ технология которая даёт СТАТИЧЕСКУЮ модель на ВСЕЙ протяжённости жизни ПРОЭКТА!!! т.е. не только на стадии программирования. понимаете? т.е. Гради Буч что толкует? Слушать клиента, и опираясь на ЕГО представление о сущностях(ИЗ ЖИЗНИ!!!) строить классы, связи и прочую шнягу... Это есть = CONST ВСЕГДА!!!! Это и есть ответ на вашу жалобу. Консерватория у вас дохлая...

т.е. это не он лох... это вам нужно ПРИМЕНЯТЬ РАБОЧУЮ МЕТОДИКУ!

Другое дело - почему вы это не делаете. - хз...

удачи вам
(круглый)