概要

アプリ開発の工夫として、
私はPlantUMLを使用して設計を図示することが多かったです。
簡単なCRUD処理などシンプルな場合は、
そもそも図示する必要はないため効率が悪いです。
重たいバッチ処理のようなどうしても処理が複雑になってしまうような場面では、
実装や不具合調査の際にはかなり重宝していました。

具体的にどのような場合に、どのような図を作成するのか記載します。

アクティビティ図

例えば下記の設計って頭の中で組み立てるの難しくないでしょうか？
(存在しない処理を頑張って書いたつもりです。)

毎週月曜日午前2時にバッチ起動
ユーザテーブルから有効ユーザ全件取得
有効ユーザに紐づく先週の購入履歴を取得
購入履歴が存在しない場合2~4週間前の購入履歴を取得
過去4週間購入履歴が存在しない場合各ユーザにセール情報をメールで送信する
有効ユーザ1000件毎に並列処理を行う※4並列
1. 購入金額の合計が閾値を超えるかチェックする
2. 閾値を超える場合
  1. ゴールド会員の場合処理不要
  2. シルバー会員の場合ゴールド会員に昇格する
  3. ブロンズ会員の場合シルバー会員に昇格する
3. 閾値を超えない場合もしくは1週間の購入履歴が存在しない場合
  1. ゴールド会員の場合シルバー会員に降格する
  2. シルバー会員の場合ブロンズ会員に降格する
  3. ブロンズ会員の場合処理不要
後続処理を実行する

PlantUMLのアクティビティ図を作成します。

どうですかね。
例えで出した設計が微妙なせいで、
効果を伝えきれていない気がします。

不具合調査の例も出しておきます。

会員のランクが更新されていないユーザがいる
→1000件単位でリカバリをしなければならない可能性が高いとすぐわかる
※トランザクションの実装にもよりますが
会員ランクは更新されているがメールが送信されていない
→下記2点の調査から即開始できる
先週の購入履歴が存在しないユーザーは存在いるか
過去2~4週間の購入履歴が存在しないユーザは存在いるか

まとめ

今いる案件では自分の頭の中を整理する時や、
他の実装者との認識共有のために使用することが多いです。
あくまで内部資料として外には出さないため、
そこまできっちり作ったことはないですが、
処理の複雑さによっては作成必須にしても良いのではと思っています。
新規参入者が多いプロジェクトでは効率良く把握できるはず。

最期にソースを載せておきます。

@startuml
:毎週月曜日午前2時にバッチ起動;
:ユーザテーブルから有効ユーザ全件取得;
:有効ユーザに紐づく先週の購入履歴を取得;
if (購入履歴) then (存在しない)
  :2~4週間前の購入履歴を取得;
    if (過去4週間の購入履歴) then (存在する)
    else (存在しない)
      :各ユーザにセール情報をメールで送信する;  
    endif  
endif

repeat
    :1000ユーザ毎に並列処理を行う※4並列;
      if (購入金額の合計) then (閾値以上)
        :ゴールド会員の場合処理不要
        シルバー会員の場合ゴールド会員に昇格する
        ブロンズ会員の場合シルバー会員に昇格する;
      else (閾値未満)
        :ゴールド会員の場合シルバー会員に降格する
        シルバー会員の場合ブロンズ会員に降格する
        ブロンズ会員の場合処理不要;
      endif
repeat while (有効ユーザを全件処理するまで繰り返し)
:後続処理を実行する;
@enduml