Форум Сообщества Аналитиков
Общий раздел => ПО Аналитика => Sparx => Тема начата: varg от 29 Апреля 2010, 15:02:35
-
подскажите как сделать параметризованную Кооперацию?
-
В ЕА? А что такое параметризованная Кооперация?
-
Посмотрите здесь (http://ooad.asf.ru/standarts/UML/spr/Pattern.aspx) к примеру
-
А лучше тут (http://uml3.ru/index.php?option=com_content&view=article&id=38:design-pattern-description&catid=2:usage-uml) прочитай
-
Может быть так?
-
Не совсем.
В кооперации объявляются РОЛИ, которым ты сопоставляешь КЛАССЫ, а не ОБЪЕКТЫ
-
А лучше тут (http://uml3.ru/index.php?option=com_content&view=article&id=38:design-pattern-description&catid=2:usage-uml) прочитай
Да, как тут, параметризованная кооперация с шаблоном ( овал с квадратиком) как в ЕА изобразить?
А вообще эти кооперации при изучении просто взрывают мозг.
-
А вообще эти кооперации при изучении просто взрывают мозг.
Кооперация - это просто структура (диаграмма классов) + поведение (обычно диаграмма последовательности). Больше ничего.
-
Не совсем.
В кооперации объявляются РОЛИ, которым ты сопоставляешь КЛАССЫ, а не ОБЪЕКТЫ
Просто я не знал как это изобразить, как изображается роль в UML?
-
Постарался ответить тут (http://blog.it-konsulting.spb.ru/?p=419)
-
Постарался ответить тут (http://blog.it-konsulting.spb.ru/?p=419)
Спасибо, сложность в использовании некоторых продуктов, что нельзя одновременно показать на диаграмма два одинаковых классов (что кажется очевидным). В используемом мною примере подразумевалось, то что ты предлагаешь. Так как исходный пример из учебника имел в именах подчеркивание, я и создал объекты, но понятно что роль пишется на зависимости
-
В используемом мною примере подразумевалось, то что ты предлагаешь.
Не я, а стандарт:)
-
Денис и Эдуард, подскажите, вопрос скорей не нотационный, а семантический: можно ли ролям прописывать операции?
Вроде бы это логично, мы сперва выделяем прецеденты, определяем кооперации, участвующие в них роли, определяем операции, которые присущи этим ролям, а уже потом определяем классы, которые будут реализовывать эти операции.
-
Можно конечно.
-
Тогда, сразу второй вопрос, а как это сделать в SparxЕА?
-
Подскажите как указать имя роли при связывании класса и кооперации (ну не ручками же)?
-
Подскажите как указать имя роли при связывании класса и кооперации (ну не ручками же)?
Думаю только ручками. Идем в справку ищем Composite Structure Diagram, Role Binding, Collaboration Occurrence
-
решили попробовать RSA, там этот момент проработан, (роли можно выбрать из имеющихся и.т.п). Правда, тяжеловато идет освоение, может есть спецы, кто подсобит?
-
Если жирно некротредить, то можно сказать следующее.
Текущий стандарт UML (который возможно отличается от стандарта из 2010 года) говорит, что кооперация -- это пачка взаимодействующих экземпляров. Если рисуется диаграмма составной структуры, показывающая "кишки" кооперации вроде:
(https://www.uml-diagrams.org/examples/composite-structure-example-observer.png)
, то роли там можно соединять только коннекторами (но не ассоциациями/агрегациями/композициями, не обобщениями, не реализациями). Так что некоторые картинки, нарисованные по ссылке, которая протухла, невозможны по текущему стандарту. Надо сказать, что и диаграмма с www.uml-diagrams.org, которую я использую, тоже нарушает стандарт. Т. к. внутренности ролей на ней не ролевые, как положено по стандарту, а интерфейсные как по стандарту не положено. Стандартные внутренности ролей -- это вложенные в роли части (parts) и/или свойства (properties). Так что по стандарту кооперация Observer должна рисоваться иначе (тут другая одноимённая кооперация, но смысл тот, что ни атрибутов, ни операций у ролей не должно быть):
(https://www.oreilly.com/library/view/uml-20-in/0596007957/httpatomoreillycomsourceoreillyimages187413.png)
Между тем, в стандарте делается некоторый финт. Говорится, что якобы есть альтернативная нотация:
(https://www.uml-diagrams.org/examples/composite-structure-example-observer-composite.png)
"Альтернативная нотация" соединяет классы (ну, или интерфейсы) и кооперацию какими-то связями. Что это за связи, стандарт не может объяснить. Попытки проводить аналогии с классами, у которых можно по диаграмме составной структуры нарисовать диаграмму классов, где кишки (parts) класса вынуты наружу и нарисованы как классы, к которым проведены ассоциации. Соединяет ли кооперацию с классом (ну, или интерфейсом) ассоциация? Гм. По мне, сомнительно это. Из-за того, что экземпляр класса поучаствовал во взаимодействии, описанном при помощи кооперации, проводить ассоциацию? Ну уж нет.
Как бы там ни было, стандарт не разрешает рисовать подобные картинки:
(https://present5.com/presentation/22297477_177252425/image-7.jpg)
Далее...
Если используется кооперация, т. е. создаётся CollaborationUse, то с экземплярами, подставляемыми на роли, она по стандарту соединяется зависимостями. Важное слово тут -- экземпляры. Стандарт не позволяет подставлять классы на роли.
(https://www.uml-diagrams.org/collaboration-diagrams/collaboration-use-overview.png)
Моделирование паттернов проектирования как параметризованных коопераций в связи со сказанным сопряжено такими моментами:
1) Параметрами (а не ролями!) кооперации, моделирующей паттерн, должны быть участники (participants) паттерна. У Observer это Subject, Observer и ConcreteObserver.
2) Роли в кооперации задают имена, с которыми экземпляры участников паттерна будут фигурировать на диаграммах взаимодействия.
3) Использование паттерна (т. е. увязка классов друг с другом по его рецепту) -- это конкретизация параметризованной кооперации. По параметризованной кооперации, моделирующей паттерн, создаётся другая кооперация -- её конкретизация. Они соединяются зависимостью связывания, в которой прописываются bind-инги. То есть использование паттерна -- это не использование кооперации, которая его моделирует.
-
Можно решить, что кооперация -- плохой способ моделировать паттерн [весь]. Что же делать? Можно вспомнить что в UMLе есть штуковина, внутри которой классы чувствуют себя вполне нормально, внутри которой можно рисовать и ассоциации, и обобщения, и реализации, и зависимости. Это пакет:
(https://www.uml-diagrams.org/examples/java-7-concurrent-executors-uml-class-diagram-example.png)
И есть в UMLе изобретение авторов языка Ада (того самого) -- параметризованный пакет:
(https://www.uml-diagrams.org/package-diagrams/package-template-overview.png)
Только вот зависимость связывания, согласно последним веяниям, должна рисоваться как зависимость, не как реализация.
Итак, паттерн можно моделировать пакетом. Участники паттерна и связи между ними становятся элементами пакета. Структура описывается диаграммой, вроде той, что выше. Для описания поведения в состав пакета можно включить кооперацию и внутри неё смоделировать взаимодействие экземпляров участников. Использование паттерна описывается как конкретизация пакета [см. на диаграмме выше].
P. S. У предложенного способа есть недостаток. Связи между классами, соединёнными по рецепту паттерна оказываются отдельно от этих классов. Они лежат в пакете -- конкретизации параметризованного пакета. Где лежат сами эти классы [мне] неясно.
-
Интересно, но даже плюсик поставить негде. Совсем форум по швам расползается:(
-
Интересно, но даже плюсик поставить негде. Совсем форум по швам расползается:(
Хотя нет, нашел!
-
Хотя нет, нашел!
Спасибо, Galogen!