UMLで表現しきれない“動き”を、ペトリネットで可視化する
Back to Top
# UMLだけじゃダメ?ペトリネットを知れば、もっと深くシステムが理解できる
#この記事の目的
#もともとUML Format2.5.1をひも解いた結果を記事にするつもりだったが、ひも解く上でペトリネットの考え方が必要になり
ペトリネットのことを学習した。せっかくなのでその学習した結果を共有しようと思い、今回記事にした。
UMLは強力なモデリングツールだが、システムの複雑な動作や状態の遷移を表現するには限界がある場合もある。
そこでこの記事ではUMLを補完し、より深くシステムを理解するための「ペトリネット」というモデリング手法を紹介する。
この記事を読むことで、次のような効果が期待できる。
- モデルの書き方を理由としたレビューでの指摘を減らし、成果物の質を向上させることができる
- 要求分析などでモデルを作成するときに、自分の作るモデルが何を意味するのか正しく理解できるようになる
- モデルが何を意味するか理解することで、お客様にモデルの説明をしやすくなる
UML Formatではペトリネットの考え方がたびたび出てくるため、今回はペトリネットに焦点を当て、UMLとの違いやペトリネットの活用方法を解説する。
ペトリネットとは?UMLとの違い
#ペトリネットは、1962年にカール・アダム・ペトリが発表した、離散分散システムを数学的に記述するために発明された方法である。
(離散分散システム:スマートホームシステムのように、リビングの照明の調整、エアコンの調整といった、並行した個々で分散した動作をつなぎ合わせて一つのシステムを実現しているもののこと)
UMLとペトリネット、どちらもシステムの振る舞いをモデル化するためのツールだが、得意とする点が異なる。
- UML: システム全体の構造や、オブジェクト間の関係などを表現するのに優れている。
- ペトリネット: システム内の状態変化や、並行処理、時間的な流れなどを明確に表現するのに優れている。
例えば、UMLのActivity図でシステムの振る舞いをモデリングした場合、システムがどんな処理を行うのかは理解できるが、イベント間(アクション間)での状態変化を表現するのは難しく、時間軸的な振る舞いを表現しづらいという弱点がある。
お客様から「システムの内部で、何がどういう順番で起こるのか」といった、より詳細な説明を求められた場合、ペトリネットを使うことで、より正確に、分かりやすく説明・表現できる可能性がある。
ペトリネットの基本
#ペトリネットを書くために必要な要素は以下のとおり。
ペトリネットは、プレース(状態)とトランジション(遷移(事象))、これらを接続する線(入力線、出力線)、トークンで構成されている。
- プレース: 状態を表す円形のノード
- トランジション: 状態の変化を表す四角形のノード
- 入力線: 前状態からトランジションに接続される、トランジションが発火するために必要な場所を表す線
- 出力線: トランジションから後状態に接続される、トランジションが発火した結果、次の状態に遷移するために使用される場所を表す線
- トークン: プレースの内部に配置される黒丸で、システムの局所的状態、つまり今どのプレースにリソースが存在するのかを示す
これはペトリネットの基本となる単純ペトリネットを構成する要素である。 単純ペトリネットは並列処理のモデリングに有用で、複数のプロセスがそれぞれ独立していて実行される といった状況をモデリングするのに最適である。 注意点として、単純ペトリネットは比較的単純な問題しかモデリングすることができない。 しかし、拡張されたペトリネット(Colored Petri NetsやTimed Petri Netsなど)を使うことで複雑なシステムもモデル化可能である。
この単純ペトリネットのモデリング例を表すと以下になる。
これを踏まえてオールドファッションを作る工程を例としてペトリネットで表現してみる。
まず、オールドファッションを作るにはドーナツとそれをコーティングするチョコが必要なので
原料として、まだ揚げていないドーナツと、チョコソースに加工する前のチョコがプレースとして存在する。
もちろんこの状態ではトークンはドーナツ、チョコ両方とも一番左のプレースに存在する。
ここでドーナツを揚げると、トランジション「ドーナツを揚げる」が発火してトークンが前状態から後状態に移る。
さらにチョコをコーティング用にチョコソースに加工するとトランジション「チョコをソースに加工する」が発火して、
トークンが前状態から後状態に移る。
最後に仕上げとしてチョコソースをドーナツにコーティングするとトランジション「ドーナツをチョコにコーティングする」が発火して
二つのトークンが2つの前状態から後状態へ移る。
ペトリネットの規則
#ペトリネットでは、トークンについては特に制約があるためここではその説明をする。
状態表現
#- プレースはそこに入るトークンの個数によりシステムの局所的状態を表現する
- 1つのトークンは1つの資源に対応する。任意のプレースにトークンがk個置かれていればk個の資源がそのプレースに存在することを示す
- 同じプレース内に複数のトークンがあった場合、それらは区別されない
つまり、トークンはそのプレースにその時間軸で資源がいくつあるのかを示すのであって何のトークン(資源)が存在するかといったことは考慮しない。
状態遷移規則
#- トランジションは、各入力プレースに対応するアークの重み以上のトークンが存在する場合に発火可能である。
※アークの重みは、1本の矢印に数値を付与することで表現します(例:重み3なら、トークンが3個必要) - トランジションが発火すると、各入力プレースから入力アークの重み(矢印の本数)だけのトークンが失われ、出力プレース(後状態)に出力アークの重み(矢印の本数)だけのトークンが加えられる
つまり、ペトリネット全体でトークンの数は変化することはなく、矢印の本数より多いトークンの移動はない。
最後にトランジション発火前後のトークンの移動イメージは以下のとおり。
終わりに
#私もUML Formatを読み解くのを機にペトリネットのことを知ったが、UMLより原始的でありながらも直観的にわかりやすい表現技法だと思った。
UMLはシステムの構造を理解するのに役立つが、ペトリネットを組み合わせることで、システムの動的な側面をより深く理解することができる。
- UMLには慣れているが、システムの動作をうまく表現できない…
- お客様にシステムの動きを具体的に説明したい…
そんな悩みを抱えている方は、ぜひペトリネットの活用を検討してみてはいかがだろうか。
UMLとペトリネット、それぞれの強みを理解し、適切に使い分けることで、より効果的なシステム設計・開発が可能になるはず。