Диаграмма классов UML: как смоделировать отношения о вызове метода или запуске действия или службы

Я создаю свое первое приложение для Android. Я избегал помечать связи с взаимодействием пользователя или системы (например, я помечал начало вместо startsWhenClick; я помечал начало вместо startsWhenDetection). ). Однако после прочтения это, я подумываю изменить ассоциации starts на зависимости ‹‹ create >>. Я запутался!

Приложение работает следующим образом. Когда приложение запустится, LauncherActivity вызовет методы BaseActivity, чтобы запустить действие, отмеченное в SettingsActivity (это может быть и SettingsActivity). LauncherActivity также запустит обе службы. Это диаграмма:

полная диаграмма классов

Примечание: этот вопрос является продолжением этот вопрос.


android object-oriented-analysis class-design uml class-diagram
person chelder    schedule 10.02.2014    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Это не настоящая диаграмма классов.

  • Старты и звонки относятся к заметкам, или если вы уверены, что хотите их видеть на соединениях, делайте стереотипы на ЗАВИСИМОСТИ, а не ассоциации.
  • У вас по-прежнему нет ассоциаций, а они составляют основную часть диаграммы классов. Посмотрите здесь о том, как с ними работать. Сначала вы должны создать ассоциации. Только после этого покажите зависимости. (Это не общепринятое правило, но вы должны сделать это для лучшего понимания)
  • Что касается действий, которые вы пытаетесь показать здесь, сделайте для них диаграмму конечного автомата, а затем, возможно, диаграмму последовательности или активности. Не используйте обзорную диаграмму взаимодействия, вы потеряетесь в ней.

Но перестаньте помещать так много действий на диаграмму классов

ИМХО, т.к. Activities не имеет или почти не имеет структурных зависимостей, соответствующая диаграмма классов будет очень скудной — простые блоки без ассоциаций. И зависимости по всему полю... Итак, диаграмма классов бесполезна на этом уровне. Кажется, я уже говорил вам, что диаграммы классов предназначены для классов, которые находятся в одном и том же намерении Android — один или несколько для намерения.

Что касается диаграммы связи, думаю, это не ваш случай. Это более распространено, ближе к пользователю, чем диаграммы последовательности или деятельности. Это на тот случай, когда у вас очень много разных сообщений и вы планируете их маршруты. Например, для планирования Camel. Но увы - в нем не реализованы шаблоны сообщений. Так что остается только очень общее планирование систем с массовым обменом сообщениями. Ваши "сообщения" стартуют, инициируют компоненты и так далее. Вы не можете показать это с этой диаграммой.

Вы можете попробовать Диаграмму объектов или Диаграмму составной структуры. Если вы хотите показать функциональность на диаграмме классов, вы не можете этого сделать, но можете перейти к этим.

person Gangnus    schedule 11.02.2014
comment
Итак, если я правильно понял, это будет (мы должны использовать пунктирные линии, верно?): 1) PowerButtonPushedDetectorService<··· <<call>> ···LauncherActivity. Могу ли я использовать стереотип ‹‹start››, даже если он не здесь? 2) LauncherActivity··· <<use>> ··· settingsAtrribute···>SettingsActivity и LauncherActivity <··· <<call>> ···SettingsActivity. Можно ли пометить ‹‹usesMenu›› вместо ‹‹use››? - person chelder; 11.02.2014
comment
Зависимости @chelder перечеркнуты, а не пунктирными линиями. а- - - -›б - person Gangnus; 11.02.2014
comment
@chelder Нет, пожалуйста! Сначала вы должны создать ассоциации. Только после этого покажите зависимости. Что касается действий, которые вы пытаетесь показать здесь, сделайте для них диаграмму конечного автомата, а затем, возможно, диаграмму последовательности или активности. Не используйте обзорную диаграмму взаимодействия, вы потеряетесь в ней. *Но перестаньте размещать действия на диаграмме классов* - person Gangnus; 11.02.2014
comment
Может на примере пойму. Так, например, какая может быть связь между PowerButtonPushedDetectorService и LauncherActivity? Связанный код LauncherActivity: Intent service2start = new Intent(getBaseContext(), PowerButtonPushedDetectorService.class); startService(service2start); - person chelder; 11.02.2014
comment
@chelder Разделите классы на объекты/экземпляры. Они не одинаковы в Java. Как я вижу из кода, PowerButtonPushedDetectorService — это объект. Боюсь, многие вещи, о которых вы говорите, на самом деле являются объектами. Посмотрите на диаграмму объектов, там вы можете использовать порты на классах. Каждый порт предоставляет некоторые услуги другим классам или объектам, подключенным к нему. Это кажется более подходящим для вашей проблемы. - person Gangnus; 11.02.2014
comment
@chelder Если мы находимся на диаграммах классов, то существует однонаправленная навигационная ассоциация от LauncherActivity к Intent Instance с service2start в качестве имен экземпляров и атрибутов. И из этого экземпляра намерения другая навигационная ассоциация с PowerButtonPushedDetectorService. Что касается имени атрибута, загляните в код конструктора Intent, где ставится второй параметр. - person Gangnus; 11.02.2014
comment
@chelder Здесь проблема - диаграммы классов плохо показывают такие зависимости. Например, анонимный тип в UML — это катастрофа. На диаграмме классов. В последовательности один все в порядке. - person Gangnus; 11.02.2014
comment
Я понимаю, что объект Java (согласно JLS) является экземпляром ссылки тип. Есть экземпляры других типов: int, char... Диаграмма объектов полезно показать различные значения объектов в течение жизненного цикла. Мне это кажется неуместным. Может быть, вы имеете в виду схему компонентов? - person chelder; 11.02.2014
comment
@chelder Нет. Я имею в виду диаграмму объекта или ... Хорошо, диаграмма составной структуры. Если вы хотите показать функциональность на диаграмме классов, вы не можете этого сделать, но можете перейти к этим. Кстати, спасибо, вы подтолкнули меня увидеть больше проблем на диаграмме классов из стандарта UML, чем я знал раньше. Определенно +1 за это. - person Gangnus; 11.02.2014
comment
Хорошо, думаю, я понял. Почти все классы здесь вызываются классом Intent. Таким образом, это будет действительно беспорядочная диаграмма классов. Вместо этого я мог бы использовать диаграмму компонентов (чтобы не включать в нее класс Intent). Это? - person chelder; 11.02.2014
comment
@chelder Я думаю, поскольку у Activity нет или почти нет структурных зависимостей, соответствующая диаграмма классов будет очень плохой - простые блоки без ассоциаций. И зависимости по всему полю... Итак, диаграмма классов бесполезна на этом уровне. Кажется, я уже говорил вам, что диаграммы классов предназначены для классов, которые находятся в одном и том же намерении Android — один или руда для намерения. - person Gangnus; 11.02.2014
comment
@chelder Вы также можете использовать диаграммы состояния и последовательности - мне кажется, они могут быть очень полезны, поскольку они устанавливают зависимости состояний / действий и последовательности действий. - person Gangnus; 11.02.2014
comment
Я сделал диаграмму действий для понимания и объяснения рабочего процесса. Затем я привык без проблем создавать диаграмму классов. Благодаря Android и вам, Gangnus, я обнаружил много новых диаграмм UML. Я нашел два типа составных структурных диаграмм. Первый вариант кажется более интуитивно понятным, но я думаю, что вы имеете в виду второй. - person chelder; 11.02.2014
comment
А как насчет диаграммы связи UML? :) - person chelder; 12.02.2014
comment
@chelder 1. да, я имею в виду этот второй CSD. 2. Насчет общения она, думаю, это не ваш случай. Это более распространено, ближе к пользователю, чем диаграммы последовательности или деятельности. Это на тот случай, когда у вас очень много разных сообщений и вы планируете их маршруты. Например, для планирования Camel. Но увы - в нем не реализованы шаблоны сообщений. Так что остается только очень общее планирование систем с массовым обменом сообщениями. Ваши сообщения запускаются, инициируют компоненты и так далее. Вы не можете показать это с этой диаграммой. - person Gangnus; 12.02.2014
comment
@chelder И, пожалуйста, обратите внимание, что благодарность здесь, на SO, выражается в основном голосованием и проверенными ответами :-) - person Gangnus; 12.02.2014
comment
Во-первых, спасибо за вопрос с настойчивостью. Я думал о том, чтобы голосовать только за основные комментарии, чтобы облегчить человеку, который его читает, следить за разговором. Но ты прав: это единственный способ сказать спасибо, и я очень благодарен. Кроме того, мы всегда можем отредактировать ваш ответ, включив в него самые важные моменты беседы. - person chelder; 12.02.2014
comment
С другой стороны, ясно только то, что информация UML об этих диаграммах очень запутана: я читал, что Схемы составной структуры используются для отображения внутренней структуры класса. В любом случае, я думаю, что для этой цели лучше всего подходит диаграмма составной структуры. Я думаю, что мы также могли бы использовать диаграмму компонентов, но каждый класс был бы компонентом (и мы знаем, что это странно для этих диаграмм). Не могли бы вы обновить свой ответ? (Я мог бы сделать это для вас, если хотите). - person chelder; 12.02.2014
comment
Да, это прекрасно. Спасибо @Gangnus! :) - person chelder; 12.02.2014