UMLを使った既存システムの分析

UMLで表現する

分析のためのモデリング

　今回紹介する表現方法は、分析の手法として活用するものです。つまり「調べる⇒分析する⇒結果を記述する」という流れではなく、「調べる⇒記述する⇒分析する」というサイクルを前提にしています。限られたアイコンを使い、パターンに従って記述することが分析につながります。個々の要素をつなげる、分類するという行為を繰り返すことが、対象を深く知ることになるのです。ポイントは、間違っていてもいいので、とにかく記述することです。間違いは気づいたときに直せばいいのです。

　以下に表現方法を紹介しますが、結果を整理するのではなく「書きながら考える」ということを意識しながら使ってください。そうすると、少数の記号と決まったパターンで表現することの価値を実感できると思います。

表現方法

　システムの地図は6種類のデータと2つのモデルで表現します。

• 誰に：　　「アクター」、「外部システム」
• 何を行い：　「画面・帳票」、「外部システムとの入出力」、「機能」、「データ」
• 何のために：「ステートマシン図」、用語集、（「概念モデル」、「ドメインモデル」）

　「何を行い」の部分を7種類のアイコン（図1）で表現します。これらを組み合わせてシステム全体を表します。進め方は第2話の図3にもとづいて行います。

図1　使用するアイコン

　最初は「材料を集める」ことから始めます。入出力情報となる画面、帳票、イベント、イベントデータとデータ（RDB、ファイル）を調べ、その結果をUMLツールに登録します。

　注意が必要なのは名前の付け方です。第1話の図4で、洗い出す情報は実体につなげるという説明をしました。実体というのはそのシステムで管理されている単位を指し、後でドキュメントやプログラムを調べるときの入口になるものです。画面・帳票、イベント、イベントデータ、データにつける名前はその管理されている名前を付けます。その名前が体系だった番号（K123123...）などで管理されている場合は分かりやすい名前を一緒に付けることも大事です。

　画面と帳票、イベントデータはクラスアイコンで表現し、各々の項目を洗い出したときはクラスの属性として表現します。

　イベントアイコンは外部のシステムとの入出力を表現するために使い、システムアイコンは関係する外部のシステムを表しています。イベントを外部システムとつなげることでイベントの帰属がわかります。

　データはクラスアイコンで表現し、テーブルのカラムはクラスの属性として表現します。ファイルはデータの入出力などに使用するものを表し、一時ファイルは対象外とします。この限られたアイコンで表現することでシステムの様々な実現手段に惑わされることなくシステムを表現できるようになります。

アイコンのつなぎ方を決める

　システムを表現するためにアイコンのつなぎ方をパターン化（図2）します。業務系のシステムは入出力がデータを介して相互に関係（第2話の図1参照）を持ちます。システムの地図はその相互の関係を示したものです。

　基本は入出力（画面・帳票、イベント、イベントデータ）とデータを、機能を介してつなげます。画面・帳票、イベント、データは洗い出したものをそのままアイコンとして記述します、実際のモデリングの作業は、それらの入出力とデータを機能でつなぐ作業が中心になります。この時の機能は論理的なものでプログラムではありません。あくまでもシステムの入出力となる画面・帳票、イベントとデータを論理的な機能でつなぐことで整理された形にまとめ上げます。

　画面の処理を例にとると画面のイベントが機能を呼び出し、データを操作します。同様に外部システムとのイベントも機能につながりデータを操作します。データを中心に機能、入出力とつなげて関係性を把握することで、システムの全体像が見えてきます。

　画面と機能の間にイベントを置くのは、システムの入出力をイベントとして統一的に扱うためです。

　通常画面や外部システムとのやりとりには相互に関係があり、その関係を整理することで、システムで管理する業務上の手続きが見えてきます。それを整理したものが手続きのルールになります。その記述方法としてステートマシン図（図3）を使います。

図3　構造と手続きのルール

　「定周期イベント」というのは特定の時間に起動するようなイベントを表します。起動タイミングが時間に起因するものは全て定周期イベントとして扱います。

　機能をプログラムと対応させないのが、今回紹介している手法の特徴です。対象となるプログラムは混沌としており、そのままでは有益な情報になりません。そこで「現実とつながりながら現実の混沌に影響されずに整理する」（第1話で説明）ことが重要になります。入出力とデータは実際のシステムの情報を使いながら、機能は論理的に抽出し、整理された物として表現します。実際のプログラムと切り離して、本来の機能を洗い出すことで、システムを分かりやすく表現できるようになります。

図2　記述パターン

ビジネスルールの表現

　上記の作業でシステムの全体像は見えてきましたが、システムを支配しているルールは見えていません。システムが扱う情報構造や振る舞いはビジネスルールとして扱い、第2話で説明したように3種類に分けて整理します。

手続きにともなうルール

　仕事を進めるために現場の人は状態を認識しています。例えばある受注に対して「在庫引き当て待ち」「出荷待ち」など受注の状態を管理しています。これらの状態の遷移をルール化したものが手続きに伴うルール化です。表現方法としてUMLのステートマシン図を使います。

　業務上の状態は現場担当者が使っている言葉や画面上の項目などに現れます。担当者が関心を寄せていることに着目すると状態が見えてきます。画面上「XXX中」のような表示があれば状態を識別している可能性があります。画面・帳票の調査やヒアリングの中で状態として認識できるものが出てきたときはステートマシン図に記述し整理します。

　次にイベントを状態変化の遷移に結びつけます。状態を変えるのはイベントが起点になると考えるからです（第2話の図5参照）。

　ビジネス上で認識されている状態と入出力をつなげることで、ビジネスと各画面や外部システムとの関わりを理解でき、システムの動きを把握できるようになります。同時に遷移に対応するイベントがない場合は、調査が足りていないことがわかります。

構造にともなうルール

　データの構造を調べると自ずと構造に起因する制約が見えてきます。RDBの場合について説明します。まずはテーブルの主キーを調べることで、どの単位でデータがユニークになるかを把握できます。

　次に、テーブル間の関係を整理します。テーブルAを外部参照するテーブルBがある場合はテーブルAとBは1対1もしくは1対多の可能性があります。多重度はスキーマ情報だけでは判断できませんが、重要なテーブルであれば保守担当者にヒアリングすることで1対1か1対多かを知ることができます。主にデータ間の多重度に焦点を当てて構造的な制約を整理します。データ間の制約を元に画面上で対象データの扱いを調べることで、制約がそのままルールになるか否かを判断出来ます。

　手続きのルールで洗い出した状態はデータの関係もしくは値として実現されると考えます。この考えを手がかりに状態とデータの関係を調べることで、システムの振る舞いに応じたデータの使われ方が見えてきます。このように入出力とデータの関係を、状態を使って整理することで、データの変化を分析できます。

条件付けられるルール

　表形式や用語としてまとめられるのがこのルールです。これらのルールは図的な表現ではなく、表形計算ツールを使い一覧形式で管理します。