Какие диаграммы UML могут мне понадобиться для концептуализации фоновых настольных приложений?

Я пытаюсь разработать веб-приложение и некоторые настольные приложения, все эти приложения взаимодействуют через базу данных или сокет tcp. Эти настольные приложения работают в фоновом режиме, поэтому варианты использования отсутствуют, а веб-приложение используется только удаленными пользователями.

И эти настольные приложения взаимодействуют с веб-приложением через БД и наоборот.

Какие диаграммы UML могут помочь мне концептуализировать работу настольных приложений?

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

Большое спасибо!


conceptual uml
person user3508865    schedule 26.04.2014    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

В этом случае, поскольку ваше приложение работает в фоновом режиме, оно должно быть чем-то запущено: человеком или планировщиком заданий (= системой). Это означает, что запуск осуществляется актором, поскольку актором может быть человек или другая программная система.

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

person Rolf Schorpion    schedule 26.04.2014
comment
Да, вы правы, в моем случае это вызвано системой, так что это второй актер. Но на диаграмме последовательности мне нужно имитировать этого актера как контроллера или что? - person user3508865; 26.04.2014
comment
Вы можете оставить актера в качестве актера на диаграмме последовательности. Ваш фоновый процесс можно рассматривать как контроллер. - person Rolf Schorpion; 26.04.2014
comment
Но я не могу получить информацию или опросить актера (как getStream()..)? - person user3508865; 27.04.2014
comment
Фоновое приложение — это не актер, а контроллер. Ваша система или планировщик, который запускает приложение, является действующим лицом. Вы получаете информацию от контроллера, а не от актера. - person Rolf Schorpion; 27.04.2014
comment
Хорошо, тогда мне нужно нарисовать систему, которая запускает настольное приложение при его запуске? - person user3508865; 27.04.2014
comment
Ну, очевидно, люди не всегда рисуют актера на диаграмме последовательности, а только стрелку, которая запускает ваше настольное приложение. Так что решать вам :) - person Rolf Schorpion; 27.04.2014

arrow_upward
0
arrow_downward

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

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

Обязательно:

  1. Схема компонентов — показывает структурную организацию вашей системы и их зависимости (настольное приложение, веб-приложение, БД являются компонентами).
  2. Диаграмма развертывания – показывает сетевую организацию, серверы и то, как ранее определенные компоненты фактически развертываются на узлах серверов.
  3. Схема(ы) последовательности – показаны важные сценарии связи между компонентами. Вы упоминаете TCP, поэтому его можно уточнить и отобразить с помощью одной или нескольких диаграмм последовательности. При наличии стандартного шаблона связи может быть достаточно одной последовательности. В противном случае можно использовать несколько последовательностей, чтобы охватить все значимые сценарии коммуникации.

Необязательно:

  1. Схемы классов — для указания структуры внутренних компонентов — дизайна (проект исходного кода). Я рекомендую этот, только если в каждом компоненте есть сложный дизайн, который стоит затраченных усилий. В противном случае синхронизация модели с фактическим кодом может быть дорогостоящей.
  2. Диаграммы состояний — если класс компонентов демонстрирует поведение, которое можно смоделировать как набор дискретных состояний (например, ВКЛ, ВЫКЛ, В РЕМОНТЕ, НЕ В СОСТОЯНИИ), эта диаграмма очень эффективна и настоятельно рекомендуется.
  3. Диаграмма действий. Если у вас есть интересные нетривиальные алгоритмы или вы просто хотите показать общую логику системы с точки зрения последовательностей задач, используйте диаграммы действий.

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

Если у вас есть дополнительные вопросы или сомнения, просто спросите.

person Aleks    schedule 26.04.2014
comment
диаграмма компонентов не является обязательной? - person user3508865; 27.04.2014
comment
в чем разница между диаграммой компонентов и диаграммой развертывания? - person user3508865; 27.04.2014
comment
Каждая диаграмма необязательна, вы можете кодировать вообще без моделирования. Если вы хотите смоделировать и сделать это правильно, на мой взгляд и в этом случае, я бы сначала смоделировал компоненты. Зафиксировать структуру системы, ее модули и зависимости. На диаграмме развертывания также показаны компоненты, но кроме того, она также показывает лежащую в основе аппаратную структуру и то, как компоненты распределяются по аппаратным узлам. Компоненты фокусируются на зависимостях между модулями, развертывание фокусируется на распределении модулей на аппаратном обеспечении. Ваши системы явно распределены, так что депл. является обязательным. - person Aleks; 27.04.2014