連載
【改訂版】初歩のUML

第9回
UMLベース開発プロセスの流れ

萩本順三　株式会社豆蔵
2003/8/19

　今回は、エンタープライズ・システム開発の中でUMLをどのように活用しているのかについて、概要を説明していきます。説明の中では、順平君という架空のエンジニアの経験を通して、単純だった昔のソフトウェア開発の時代から、近代的なエンタープライズ・システム開発の時代まで、エンジニアとして経験していく道のりをたどりながら、その中でUMLモデルがどのような局面で効果的な活用がなされるのか説明していきます。

順平君の開発体験記

◇ステップ1：プログラムする前に設計が必要だと気付く

　プログラムが単純だった古き良き時代には、順平君は、気が付いたアイデアからいきなりプログラムを書くことがほとんどでした。順平君が作ったプログラムを説明する資料などは1つも作らず、とにかく試行錯誤の中からプログラムを作成していました。

　あるとき、上司が順平君の仕事を見ていて、「おいおい君、プログラムはしっかり設計してから書くものだよ」と説教されてしまいました。その瞬間、「自分で作ったプログラムさえ分からなくなるという悩みは、設計を覚えることで、解決できるのでは？」と考えたのです。そして順平君は、「設計」というカッコイイ言葉にもあこがれつつ、設計を学んでいくことを決意します。

　順平君は設計を学んでいく間に、設計には「外部設計」と「内部設計」があることを知ります。外部設計とは、画面、帳票などユーザー（プログラムを利用する人）から見える仕様を明らかにすることです。内部設計とは、プログラムの構造を明らかにすることです。順平君は、外部設計についてはユーザーインターフェイス設計と考え、ユーザーマニュアルを書くレベルの丁重さでドキュメントを書くコツを覚えました。しかし内部設計については、いくら構造化手法などのソフトウェア工学を学んでも困難に思えました。なぜなら最終的に出来上がるプログラムは機能とデータが混在する構造となっており、機能中心・データ中心で行った設計からプログラムを起こし、プログラムを解説するために機能中心・データ中心で作成した内部設計書があまり役立つことはありませんでした。

コラム：システム設計におけるUMLの効果

順平君が体験した時代の主役は構造化手法でした。構造化手法の欠点は、細かな機能やデータに着目し、ソフトウェアの中に必然的に存在する概念に着目しなかったことです。ソフトウェアの中の概念とは、ソフトウェアで実現すべき課題を達成するための「オブジェクト（もの）」のことです。オブジェクトは人間が理解しやすいようにとオブジェクト指向に採用されたソフトウェア構造を識別する単位となります。 　オブジェクト指向開発では、このオブジェクトという単位の導入により、内部設計を適切に表現できるようになっています。内部設計はUMLによって表されます。具体的には、クラス図を中心として、オブジェクト図、シーケンス図などが使われます。UMLベースの開発では、内部設計が役立たないといったことはありません。内部設計こそUMLによって最大限の効果をあげられるのです。最近では、開発者がさまざまな地域に分散することも珍しくありません。。中には、外国の開発者と共同開発をすることもあるでしょう。このようなときこそ、プログラム構造（注）をどう作るのかといった内部仕様をUMLで記述することは非常に効果的です。 　しかし、残念なことにJ2EEや.NETにおける近代的な開発を行っている企業が、従来どおり外部設計だけで内部設計をおろそかにした、旧来型の開発方法を取っています。外部設計だけ固め、あとは（内部設計）パートナーに開発させているのが現状です。これはオープン系の開発では、極めて危険です。なぜなら、オープン系の開発では、さまざまなOS、ミドルウェア、コンポーネントを寄せ集めて作りますので、設計と実装に多大なリスクが潜んでいるのです。これをどのように解決するかを内部設計として表す・試す必要があります。もしパートナーも内部設計をやらなかった場合、出来上がったソフトウェアは悲惨なものとなります。 　内部設計をきっちりできないソフトウェア企業、それは廃れゆく企業にほかなりません。また、外部設計におけるUMLの出番はほとんどありません。モデリングは具体的な様相やアイデアを表すのには不向きだからです。UMLを書いたからといって外部設計をおろそかにしてはいけません。 　UMLが、内部仕様を記述するのに非常に役立つのは理由があります。それは、細かな機能という単位でモデル表現をしないからです。UMLはオブジェクトの関係、オブジェクト構造としての属性リストと操作リスト、オブジェクト間のメッセージの流れに着目することで、対象システムのもっとも重要な概念を中心にモデル化を進めていく手法を持ち、それが、実装段階においてプログラム構造を的確に表す最もよい方法として業界に認知されてきています。よって、実際のロジックをモデル上で現すことはほとんどありません。つまり、従来のようなコードレベルのフローチャートを書くことはないのです。 　このことは、よく誤解されます。例えば、UMLを書けば、誰でも同じようにプログラムロジックが書けるようになるという勘違いです。UMLによるプログラム構造の表現は、プログラムコードを捉えるということよりも、もっと、大きな視点でプログラム構造をとらえることです。オブジェクトの単位、オブジェクトの関係、オブジェクト間のメッセージの流れに着目することがプログラム構造を理解するうえでは最も重要と言えます。しかし、ロジックを理解させることが必要なケースもあります。例えば、複雑な業務ロジックをコードに落とす時です。この場合は、必要に応じて、UMLのアクティビティ図で表現することができます。 （注）UMLによるプログラム構造表現について 図1 UMLは内部設計にて大きな効果をもたらす

◇ステップ2：要求をとらえる必要性に気付く

　順平君は設計がきちんとできるようになり、さらに、オブジェクト指向という武器を身に付けることで、ようやく一人前のエンジニアになったように思っていました。しかし、ちょうどそのころに、ほろ苦い経験をすることになりました。順平君がかかわったシステムが、ほとんどユーザーから使われることなく自然消滅してしまったのです。システムの構造はしっかり設計していましたし、システムの拡張性についてもしっかり設計したつもりです。ところが、拡張性どころか、システムが使いにくかったために、ユーザーから使われなくなったのです。なぜそうなったのか順平君にも分かっていました。

　実は、順平君は、ユーザーが何を望んでいるかという、ソフトウェアに対する要求を的確にとらえる技を持ち得ていなかったのです。本当に必要な要求が何であるかをおろそかにした結果、ユーザーからシステムが見放されてしまったのです。そのような経験から順平君は、ユースケースというモデリング手法に着目しました。ユースケースによって、設計をする前にユーザーの要求をとらえることに務めたのです。これができるようになれば、要求から設計へスムーズに流れるようになるだろうと考えました。

コラム：要求分析におけるUMLの効果

要求をとらえるフェイズを要求分析フェイズといいます。要求分析フェイズにて、効果を発揮するのが前回取り上げたユースケースモデルです。ユースケース図によって、ユーザーから見た要求の大まかな構造をとらえ、ユースケース記述によってその詳細を説明するのです。あくまでユースケースモデルはユーザー主導で作成されることが重要です。そのためにダイアグラムも分かりやすくシンプルに表現されています。ユーザー主導で作成されたユースケースモデルには、システムの使われ方が、ユーザーの業務知識をベースに記述されます。 図2 ユースケース図

◇ステップ3：要求の概念構造を表現することの重要さに気付く

　順平君は、ユースケースモデルを使いこなすことで、システム要求をとらえるという上流工程までをこなせるようになってきました。しかし、そのうち大きな悩みが生じました。ユースケースモデルと設計モデル、それぞれを作成することはできますが、両者のつながりが定義できないのです。

　ユースケースモデルはシステムを利用するというユーザーの視点（WHAT）から作成しますが、設計モデルは、どう作るべきかという（HOW）視点で作成されます。設計モデルのクラスには、ソフトウェアを動かすアーキテクチャの詳細が表現されているため十二分に複雑なものとなってしまいます。また、パフォーマンスを重視して、クラスの関係構造を崩すことも多々あるのです。そういう視点で作られたモデルは、当然の話としてユーザーには理解不能なものなのです。

　本来、オブジェクト指向とは、人間にとって分かりやすい構造をソフトウェアにもたらすことができるはずなのですが、設計モデルだけでは、ソフトウェアの構造をユーザーに説明することはできません。また、複雑になりすぎた設計モデルをもう少しシンプルな構造として表すことはできないものでしょうか？

　このような悩みから、順平君は、システムを分析するフェイズに関心を持つようになりました。順平君にとってのシステム分析フェイズの印象は、高尚すぎてあまり価値がないとか、要求分析と何が違うのか分かりづらくひたすら避けて通っていたのですが、もう一度チャレンジしてみることにしました。

　システム分析について勉強してみると、どうやら要求の中に存在する語彙（ごい）に着目して、その中からクラスを抽出し、クラス図を作成していくことが主な作業であることを知りました。つまりは、実装環境の中に存在する、DBクラスや画面クラス、あるいはServletとかASP.NET関連のクラスなどは、モデリングの対象となりません。本連載の「第6回 『関連』の理解をさらに深める」で取り上げた下記の図（図3）などは、まさにそのような観点で作成されたものです。

図3 分析モデル

　順平くんは、システム分析の視点を持つことにより、分析モデルの意義を少しずつ理解するようになりました。

コラム：システム分析におけるUMLの効果

システム分析におけるUMLの効果とは「要求の概念構造をとらえる」ことと「要求から設計へ誘う」ことです。これはUMLによる分析モデルを作成することで達成します。 1. 要求の概念構造をとらえることができる 　ユースケース図は、システムの使われ方をユースケースという単位に区切ったものでユーザーから見た機能を単位としたモデルです。このような機能中心のモデルでは、本質的なビジネスの関心事となる概念の構造に着目できません。よって、要求の機能的な意味は理解できても、要求の中にある概念とその構造には気が付いていないものです。初めて分析モデリングを経験した人は、概念構造をオブジェクト指向によってとらえることで、対象領域の深い理解を得られることに気が付きます。システムの要求的な視点ではなく、ソフトウェアの機能的視点でもない、要求の中の概念構造をチームの中で議論して分析モデルを作り上げる過程には、まさに思考のビジュアル化という未体験ゾーンに突入したという実感がわくことになるでしょう。 2. 要求から設計へ誘うことができる 　分析モデルは、「要求の中に潜む概念の構造を理解すること」に使います。よって、分析モデルとして作成されるクラス図中のクラスは、ユーザーの理解可能な要求の中に存在する用語の中から候補を見つけます。これらの作業は何を作るというWHATの視点で作業を行います。しかし、要求の中に存在する用語の中から概念（クラス）を見つけた後は、その概念構造を深く理解するために中身を構造分解していきます。例えば「第6回『関連』の理解をさらに深める」で挙げたレシートの分解のようにです。このときのアプローチは、まさに対象問題を情報システム化するためというHOWの視点も必要となります。 　つまり、データを重複管理しないよう一元管理させるという視点が必要となるのです。このようにして作成される分析モデルは、要求モデルから設計モデルにつなげるために、その中間に存在するモデルとして有効なものとなります。設計モデルから見ると、設計モデルをシンプル、かつ、本質的な構造として表現している分析モデルの存在は貴重なものとなります。システムを理解しようとする開発者に、設計モデルを見せる前に、分析モデルを見せることで、対象システムの本質的構造を理解することができます。つまり、分析モデルは、設計モデルを雲の上で操っているようなもので、分析モデルを見るとシステムの本質的な概念の意味構造を知ることができ、非常に安定した世界をシステム開発にもたらすことができるのです。また、ユースケース（要求）モデルから見ると、機能に着目したユースケースモデルを理解する際に、分析モデルによって、要求の概念構造を理解できるため、要求に対する理解度を深めることができます。 図4 分析モデルは設計モデルを雲の上から操る（編集注：筆者の希望により、今回はあえて文字をぼかしてあります。ご了承ください）

◇ステップ4：ビジネスからシステムを見ることの重要さに気付く

　順平君は、いよいよ大規模開発を経験することになりました。対象のシステムは、順平君にとって非常に複雑に思えるものでした。なぜなら開発対象が企業全体のシステムであるため、まず人間系も含む企業システムの構造をとらえ、そのシステムが正しく動作するための仕組みを考える必要があったからです。その過程で、個々のソフトウェア・システムの単位を切り出す必要がありました。しかし、順平君がいままで経験したことは、すべて要求分析からスタートするというパターンしかありません。そこで、順平君は、ビジネス分析を学びながら実践していくことにしました。ここでいうビジネス分析とは、ビジネス戦略などを発案したりすることではなく、企業のビジネス戦略に則したビジネスの構造を可視化することです。

　順平君は、まず、企業におけるビジネスの関心事に着目して、ビジネスフローを書きました。ビジネスフローは、UMLのアクティビティ図を利用して作成しました。

図5 ビジネスフローで利用されるUMLアクティビティ図（編集注：筆者の希望により、今回はあえて文字をぼかしてあります。ご了承ください）

　しかし、ビジネスフローだけでは、ビジネスで何をすべきか理解できても、ビジネスにおける普遍的な概念構造をとらえることはできません。そこで、ビジネスの中に存在する語彙を使ってクラス図を作成することにしました。このクラス図は、属性・操作には着目せず、ビジネスで現れる重要な用語をクラスとして、用語と用語の概念的な関係構造をとらえるという目的で行われました。

図6 ビジネス分析で利用されるクラス図（編集注：筆者の希望により、今回はあえて文字をぼかしてあります。ご了承ください）

　クラス図を書いてみると、ビジネスの中に存在する普遍的な概念をとらえることができ、その図をベースにさまざまなディスカッションがチーム内に起こりました。しかも、そのディスカッションには、ユーザーも参加させているのですが、ユーザーにはクラス図が分からないという問題が生じず、むしろユーザーの意見がクラス図の中の関連や多重度をどうするかといった深い議論の中で重要な位置を占めていることに順平君は気付きました。このようなディスカッションの中で、いつの間にかビジネス領域の概念をユーザーと開発者が共有していることに気付かされたのです。これは、開発者にとっても、ユーザーにとっても、驚くべき出来事です。ビジネスフローでもなく、ビジネスロジックでもない、もう1つの世界、「ビジネスの概念構造を知る」ということが、ビジネスを理解するのにこれだけ役立っていると参加者全員が知ることになったのです。

　また、順平君にとっては、要求（ユースケースモデル）の中に存在する語彙に着目して、その中からクラスを抽出し、クラス図を作成していくという手法しか知らなかったため、要求を抽出する前からビジネスモデルとして、クラス図を作成するということはとても新鮮に思えました。

　順平君は、この日からシステム分析に対する考え方も変わりました。ビジネスモデルで作成したクラス図の中から、システム要求の範囲にあるクラスを対象にするためにユースケースモデルでスコープを絞り、その中から分析モデルを作成するという視点が加わったのです。

コラム：ビジネス分析におけるUMLの効果

このストーリーに書かれているように、ビジネス分析では「ビジネスはどう動いているのか、動くべきなのか」という観点でビジネスモデルが作成されます。これは、「システムでは何が必要か」ということが観点となる要求分析とは異なります。ビジネスモデルは、ビジネスを視覚化するということが目的となります。ビジネスの視覚化をUMLによって行い、ユーザーと開発者が視覚化されたビジネスをモデルで共有できれば、ビジネスの流れのどの部分を最適化すべきか、どの部分をシステム化対象にするか、といった議論に発展させることができるようになります。 　また、開発した後でもビジネスのある部分が拡張されたり変更されたりした際に、ビジネスモデルを通してシステムモデルの拡張・変更個所を見つけることができます。最近はビジネスとITが融合された世界で新たなビジネスアイデアが生まれています。つまりビジネスとITは切っても切り離せない時代になったわけです。このような世界では、ビジネスITという仮想世界の視覚化、つまりモデル化の需要はさらに高まってくることになるでしょう。

開発フェイズの基本

　順平君開発体験記はいかがでしたか。順平君の道のりは、おそらく皆さんがオブジェクト指向を導入する過程で経験する道のりに共通する部分もあるかと思います。

　この順平君の道のりは、オブジェクト指向による開発をどのように進めていくかという手順、つまり開発フェイズ（開発工程）に当てはめることができます。オブジェクト指向開発では、表1のような開発フェイズによって開発を進めていきます。ここでいう開発フェイズとは、開発を進めるうえでの手順をフェイズとして切り取ったものです。フェイズには明確な目的があり、その目的に合った観点によりモデリングなどの作業を進めていきます。

フェイズ名	目的	順平君の経験したステップ	概要
ビジネス分析	ビジネスの視覚化	ステップ4	ビジネスを視覚化し、ユーザー・開発者間で共有理解を得、そのうえで改善点やシステム化対象を洗い出す
要求分析	要求の把握（ユースケース=システム利用例の視覚化）	ステップ2	システム化対象の要求についてユーザーの視点でユースケースモデルを作成することで明確化する
システム分析	要求の概念構造の視覚化	ステップ3	要求の中に現れる用語を利用して、要求の意味概念構造をとらえるためにクラス図を作成する
システム設計	ソフトウェア構造の視覚化	ステップ1	実装されるアーキテクチャを含んだ、ソフトウェア構造をモデル化
実装・テスト	ソフトウェアの実装とテスト	なし	設計に合わせて実装を行い、単体・複合テストを行う
表：開発フェイズ

　今回はここまでです。次回は、これらフェイズを組み合わせて実際にどのように開発を進めていくのかといった開発プロセスの基本的な考え方について説明します。それでは、次回をお楽しみに！

IT Architect 連載記事一覧