UMLの概念モデルで法律を理解するアイデア

UMLのモデルで法律を理解するアイデアをメモ。

【参考】
UMLモデリングレッスン - サポートページ

第1回 編集者ガチンコバトル、お勧めモデリング本！ | Think IT（シンクイット）

【1】「UMLモデリングレッスン」のレッスン50に、刑法の犯罪要件について、UMLのクラス図で概念モデルを描いている事例がある。
このクラス図を見ながら、刑法の条文を読むと、ああなるほど、と何となく腑に落ちた。

犯罪要件の成立のクラス図 from akipii Oga

【1－1】上記では、「刑罰法規が犯罪構成要件を規定する」「～という行為が犯罪構成要件に該当する」という文言がそのままクラスとその関連名に当てはまる。
犯罪になる行為として、「違法行為」「非違法行為」の2種類があり、非違法行為になる条件として「違法性阻却事由」を持つことが当てはまる。

つまり、刑法の条文はとても冗長な文章であるが、その本質となる文章をそのままクラスと関連名に当てはめれば、概念モデルになりうる。
これは面白い。
おそらく理系の人は、こういう法律の文章はとても苦手だと思うので、こういうやり方で理解する方法もあるのかもしれない。

【1-2】上記の概念モデルをER図としてRDBに落とし込んだ場合、どのようなテーブル構成になるか？
僕の勝手な憶測では、下記のようになるだろう。
IDEF1Xで書けば、「●---」の向きで外部キーによる参照制約、「△---」の向きで派生関係を表す。

刑罰法規マスタ●---犯罪構成要件マスタ
行為トランザクション---●犯罪構成要件マスタ
(※但し、行為テーブルには、複数個の犯罪構成要件マスタを外部キーとして持てる)

行為トランザクション△---違法行為トランザクション、非違法行為トランザクション
非違法行為トランザクション---●違法性除却理由マスタ

UIとしては、行為データを登録・検索する画面と各マスタ保守画面がいるかな。
帳票としては、ある期間の行為データを印刷する帳票がいるかな。

【1－3】また、「UMLモデリングレッスン」を読んで興味深い部分は、上記のようなモデリング技法が、ソフトウェア開発で使われる場面が意外にあることだ。

例えば、上記のような概念モデルを用いて、政府や裁判所の要請に基づき、犯罪履歴や事例を検索したり保守するシステムを作る案件はもちろんありうる。

似たような例として、電力・ガス・電話などの事業会社やクレジットカード・保険会社の契約条文をビジネスルールとしてソフトウェアシステムに実装する場合がある。
これらの会社では、ビジネスの基本的な約束事は約款として定められており、そのビジネスルールがシステムの要件や制約に反映されるからだ。

例えば、クレジットカード会社や携帯電話会社では、カードやスマフォの契約時に、違法性がないか、ビジネスルールを課しており、そのルールを満たす人だけが契約できる。
そしてその契約情報は記録され、後から検索したり、契約延長や契約破棄などの保守ができるように、システムを作る必要がある。

そう考えると、携帯電話会社や銀行・カード会社と契約を結んだ時に約款として渡される大量の資料の背後には、彼らの会社の基幹システムにはビジネスルールとして実装されているのだろうと推測できる。

【2】この発想を推し進めれば、例えば、日本の特許庁のシステムリプレースでも、こういう概念モデルが必要だったのだろうと勝手に推測する。
実際のニュースを見ると、破綻した理由は他にもあるみたいだが。

News ＆ Trend - 2012年の特許庁システム開発中止、開発費全額返納のなぜ：ITpro

【ITブラック】特許庁システムにまつわる黒い話が色々ヤバイ - NAVER まとめ

UMLのモデリング技法を用いて、ビジネスルールを概念モデルで表してみる手法は今後考えてみたい。