У меня возник вопрос в связи с концепциями проектирования по ICONIX.

В частности при реализации вариантов использования ICONIX предлагает создание диаграммы робастности (устойчивости, пригодности, надежности) по сути представляющая собой диаграмму классов, участвующих в реализации ВИ и классифицирующихся на: граничный класс (форма или интерфейс взаимодействия), управляющий класс (обычно имеющий название варианта использования) и классов-сущностей. В целом классический MVC.

Далее реализация ICONIX в EA имеет возможность автоматической генерации диаграммы последовательности из диаграммы робастности. При это в рекомендация встретилась интересная фраза:

Boundary and entity classes on a robustness diagram will generally become object instances on a sequence diagram, while controllers will become messages.
Т.е. граничные и сущностные классы становятся объектами-экземплярами на диаграмме последовательности в то время, как управляющие классы становятся сообщениями.

Сначала я думал, что мой перевод не точен и надо читать эту фразу как: управляющие классы организуют обмен сообщениями между граничными и сущностными.

Однако когда я попробывал сгенерировать диаграмму последовательности из диаграммы робастности, то с удивлением увидел полную реализацию той фразы, т.е. диаграмма последовательности содержала только объект граничного класса и объект сущностного класса, а управляющий класс не отображался.

Это мне показалось не совсем понятным, может кто-то может прояснить мне эту ситуацию?

А что тут не понятного?!
Управляющий Класс - это тот класс с помощью которого происходит управление, т.е. взаимодействие м\у граничным и сущностным классом

Саша, я понимаю назначение управляющего класса, но ты не внимательно читаешь текст.
Когда формируется диаграмма последовательности - управляющего класса там как раз и нет, ты говоришь что сообщениями управляет управляющий класс, как же это видно, если на ДП между граничным и сущностным классом исчезает управляющий (или он должен подразумеваться?), если да, так как по-твоему это должно выглядеть на на диаграмме классов - реализующией ВИ

В частности при реализации вариантов использования ICONIX предлагает создание диаграммы робастности (устойчивости, пригодности, надежности) по сути представляющая собой диаграмму классов, участвующих в реализации ВИ и классифицирующихся на: граничный класс (форма или интерфейс взаимодействия), управляющий класс (обычно имеющий название варианта использования) и классов-сущностей. В целом классический MVC.

Эдуард, robustness diagram в ICOMIX это то же самое что analysis diagram в RUP. Может стоит называть ее диаграмма "грубости", например. Потому, что ИМХО она показывает как раз грубые, аналитические классы и не имеет отношения к устойчивости, пригодности, надежности.

Вот интересная книжка по ICONIX. Может найдете что-нибудь полезное.

Фраза из книги

Control objects (controllers) embody much of the application logic. They serve as the connecting tissue between the users and the stored data. This is where you capture your frequently changing business rules and policies, with the idea that you can localize changes to these objects without disrupting your user interface or your database schema down the line. Once in a while (perhaps 20 percent of the time), controllers are “real objects” in a design, but most of the time, controllers serve as placeholders to make sure that you don’t forget any functionality and system behavior required by your use cases.

Виталий, спасибо. Возможно, Ваш перевод логичен, но неточен. Почему они назвали диаграмму таким словом мне не очень понятно.
Но не в этом суть.

За книгу спасибо, но прежде того, как начну скачивать - вопрос, у Вас это какая книга? Розенберг и Скотт(98) или Розенберг и Стевенс(07)?

Вот что написано в книге ООП с UML: Теория и практика. Часть 5
2. Objects on Your Robustness Diagram Will “Morph” into the Detailed Design
Boundary and entity classes on a robustness diagram will generally become object instances
on a sequence diagram, while controllers will become messages. It’s also advisable to create
test cases for the controllers.
Keep in mind that both boundary objects and entity objects are nouns, and that controllers
are verbs (i.e., an action performed on an object). As such, it makes sense that the
controllers (the actions) will become methods on the boundary and entity classes.

Не намного увеличился текст, но однозначно указывается что контролер - методы граничного и сущностного классов
Я попытался так бегло показать что получается автоматом в ЕА с использованием плагина от ICONIX

А где мессаджи на сиквенс?

Это ты спроси у плагина, он их не проставил

Причем надо сказать что месаги на 2 диаграмме это моя вольность

Интенсивное чтение Розенберга привело меня к такой вот мысли:
1. берем описание варианта использование
2. строим человечк(ов)
3. рисуем граничный класс (или несколько)
4. рисуем сущностный класс (или несколько) - все согласно описанию
5. разбираем каждое предложение, извлекаем от туда глагольные фразы, смотрим на что и куда они направлены, каждую такую глагольную фразу(шаг, операцию, функцию) превращаем в управляющий класс
6. соединяем все это хозяйство по правилу noun-verb-noun или verb-verb
далее строим секвенцию
1. рисуем актера
2. рисуем формы(граничные объекты)
3. рисуем сущности
4. класс контроллер который мы определеи на диаграмме анализа превращается в сообщение в данном случае от одного класса к другому и соотвественно становится методом класса на который направлен

вот такую вещь я вычитал и книжки

2. строим человечк(ов)
3. рисуем граничный класс (или несколько)
4. рисуем сущностный класс (или несколько) - все согласно описанию
5. разбираем каждое предложение, извлекаем от туда глагольные фразы, смотрим на что и куда они направлены, каждую такую глагольную фразу(шаг, операцию, функцию) превращаем в управляющий класс
6. соединяем все это хозяйство по правилу noun-verb-noun или verb-verb
далее строим секвенцию
1. рисуем актера
2. рисуем формы(граничные объекты)
3. рисуем сущности
4. класс контроллер который мы определеи на диаграмме анализа превращается в сообщение в данном случае от одного класса к другому и соотвественно становится методом класса на который направлен
вот такую вещь я вычитал и книжки

Странно. У меня было совсем другое представление данного процесса.
Мы создаем диаграммы деятельности для ВИ (черный ящик), далее анализируем и получаем классы анализа (диаграмма классов). Затем действия из ДД преносим на диаграмму последовательности в виде методов. В результате получаем ВИ->ДК+ДД->ДП
На примере RSA (не знаю как в EA) могу сказать, что из collaboration получается sequience одним шелчком мыши (и наоборот). Причем, если взять вашу картинку, то мне на сиквенсе RSA нарисовал бы актора, баундари, контрол и энтити и все сообщения, передаваемые от класса к классу.
По схеме Розенберга получается, что все операции (методы) будут принадлежать либо сущностям, либо граничным классам.
Тогда как же быть, например, с Session и Entity Bean из EJB (Java)? На сколько я понимаю, в данном случае JSP (servlets) / Session Bean / Entity Bean образуют самый настоящий MVC (вернее V/ C / M).

За книгу спасибо, но прежде того, как начну скачивать - вопрос, у Вас это какая книга? Розенберг и Скотт(98) или Розенберг и Стевенс(07)?

Эдуард, книжка следующая
Addison Wesley -2001- Applying Use Case Driven Object Modeling With Uml – Rosenberg\Scott

PS Эдуард, если Вам не сложно, может выслать мне книгу Розенберга, Стивенса за 2007. Или дать ссылку на источник откуда ее можно скачать.

А лучше всего добавить в наш архив

Странно. У меня было совсем другое представление данного процесса.
Мы создаем диаграммы деятельности для ВИ (черный ящик), далее анализируем и получаем классы анализа (диаграмма классов). Затем действия из ДД преносим на диаграмму последовательности в виде методов. В результате получаем ВИ->ДК+ДД->ДП
На примере RSA (не знаю как в EA) могу сказать, что из collaboration получается sequience одним шелчком мыши (и наоборот). Причем, если взять вашу картинку, то мне на сиквенсе RSA нарисовал бы актора, баундари, контрол и энтити и все сообщения, передаваемые от класса к классу.
По схеме Розенберга получается, что все операции (методы) будут принадлежать либо сущностям, либо граничным классам.
Тогда как же быть, например, с Session и Entity Bean из EJB (Java)? На сколько я понимаю, в данном случае JSP (servlets) / Session Bean / Entity Bean образуют самый настоящий MVC (вернее V/ C / M).

О чем я и толкую, у меня такое же было представление до этого момента. А вот ICONIX дает несколько иное представление. Все управляющие классы безусловно и в ICONIX, но уже на более поздних этапах, что крайне удивительно.
Про книгу я Вам написал по почте, но брал я с pdfchm.com