2015-02-03 3 views
1

Допустим, у меня есть приложение для Android, которое общается с программой на рабочем столе через разъемы Bluetooth.Представлять/иллюстрировать связь между двумя отдельными программами в UML?

псевдо-код:

На Android

class sendToDesktop{ 
sendMsg(String msg){ 
    socket.send(uuid, msg) 
} 
} 

На рабочем столе:

class Read{ 
getMsg(){ 
    return socket.read(uuid, msg) 
} 
} 

Так как я представляю отношения между этими отдельными программами в UML? Могу ли я использовать диаграммы компонентов или это единственное, что можно проиллюстрировать отдельными компонентами одной программы?

ответ

2

Как указывает @Gangnus, существует множество вариантов, и никто не является единственным и единственным.

Например, этот websequencediagrams.com script изображает ваш сценарий:

enter image description here

Необходимый уровень детализации (промежуточные классы, имена методов, списки аргументов ...) зависит, кто будет читать его и почему.

Например, это websequencediagrams.com script показывает также дополнительные внутренние классы рабочих:

enter image description here

Смотрите также:

2

Это зависит от уровня абстракции. Вы можете использовать:

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

Постарайтесь начать снизу и продолжить движение до уровня, где у вас будет одна диаграмма формата А4.

+0

@ThomasKilian 1. Также они могут быть полезны для этих этапов планирования продукта, когда вы проверяете возможности балансировки некоторых потоков. 2. Смешивание различных диаграмм UML могло бы быть очень полезным, но это должно быть строго запрещено для стартеров. Сначала они должны изучать силы и недостатки диаграмм отдельно, они должны начать думать в своих терминах. Если нет, то наступает худшая ошибка UML-анализа - псевдодиаграммирование - создание чего-то, что похоже на диаграмму, а просто путаница некоторых мыслей. – Gangnus

+0

@ThomasKilian ad. 2. Вы продвигаете сочетание диаграмм последовательности и синхронизации. Я говорю, что смешивание диаграмм очень опасно для стартеров. – Gangnus

+0

@ThomasKilian Константа синхронизации и постоянная времени не могут помочь при планировании многопоточности с помощью замков. И это единственные временные особенности SD. – Gangnus

2

Если использование UML является обязательным, вы можете рассмотреть возможность использования схемы связи, как показано на рисунке here. Хотя диаграмма связи идеально подходит для элементов одного приложения, вы можете адаптировать диаграмму для отображения связи из одного приложения в другое.

Если вы не привязаны к UML, я обнаружил, что диаграммы потоков данных очень полезны для демонстрации информации, поступающей от одного источника информации/потребителя к другому (через посреднический процесс - в вашем случае посредник процесс может быть вашим методом, который содержит логику Bluetooth).

+0

Какая схема последовательности операций вы сочтете полезной? – xmojmr

+1

DeMarco, Yourdon, et al. Моя организация использует DFD совсем немного; в первую очередь, для потоков диаграммной информации в бизнес-процессах, но я также использовал упрощенную версию их для обмена информацией с заинтересованными сторонами. – tonyapolis

1

В ответ на первоначальный вопрос: нет, компонент диаграммы не ограничиваются частями одной программы, так что да, вы могут использовать их.

UML-диаграммы не приспособлены ни к какому-либо конкретному уровню абстракции или объема работ. Если ваша «рассматриваемая система» содержит две программы, то это то, что вы должны показать на диаграмме.