統一モデリング言語

システム品質を向上させるためには、設計品質を高める必要があります。
システムに対する要求を、システムとして実現(実装)するためには、要求と実装の間を取り持つ「設計」がキーとなります。「設計」というのは、人間が要求している内容を、コンピュータシステムとして実現させるための「懸け橋」といえます。

設計するための技法は、いままで様々な方法が生み出され、そして採用されてきました。
しかし、設計は考え方であるため、プログラミングのように文法が決まっているわけではないですし、設計手法がルール化(明文化)されているということもありませんので、組織により、また時間の経過により変動(バラつき)が生じてしまいます。

設計書のフォーマットやテンプレートが決められていたり、章立てや雛形が用意されていたり、ということはありますが、それを改変したり逸脱したりしたとしても、設計内容を表現するにあたって、その記述手法が必要であったという弁明があると許容されてしまいます。

しかし、設計書の記述スタイルがバラバラまちまちであると、記述レベルが十分なのかを担保することは難しく、また読み手(プログラマーやテスタ―など)の解釈により齟齬を生む可能性も否定できません。結果として、システム品質が担保されなくなってしまいます。

その解決手段の一つとして、統一モデリング言語(ＵＭＬ)というものが存在しています。
ＵＭＬによる標準的なシステム開発が行なわれることで、品質を評価するものさし(基準)も得られることになります。
システム開発作業が個人独自のスタイルではなく、共通的な手法で作成され、共通的な基準で成果物がチェックされることで、システム品質の均質化が図られ、誰にとってもわかりやすい形でシステム化が行なわれることとなります。

ＵＭＬ

統一モデリング言語は、オブジェクト指向でシステム設計をする際に用いられる記述法で、Unified(統一)Modeling Language(モデリング言語)の頭文字からＵＭＬと呼ばれています。

1990年代に、それまでの手続き型プログラミングや構造化分析設計手法を拡張する形でデータと手続きを一体化して考えるというオブジェクト指向による開発技法が、数多くのシステム開発者により発表されるようになりました。しかし、開発技法が乱立してしまうことで、システム開発者側に混乱が発生し、新たな考え方であるオブジェクト指向によるシステム開発が推進されない状況となってしまい、それを統一しようという動きがみられるようになります。

当時、ラショナル・ソフトウェアという会社に在籍していた、オブジェクトモデル化技法を提唱するジェームズ・ランボーと、オブジェクト指向設計であるブーチ法を生み出したグラディ・ブーチが、共同で技法の統一を検討します。そこに、オブジェクト指向ソフトウェア工学の開発者であるイヴァー・ヤコブソンが加わることになり、この３人(スリーアミーゴスと呼ばれます)が主導となって1996年にＵＭＬパートナーズという国際コンソーシアムが結成され、そこでお互いの技法で共通的に利用可能な記法(言語)として統一モデリング言語(ＵＭＬ)をまとめあげることとなります。

ＵＭＬは言語と位置づけられているように開発方法論をまとめたものではなく、あくまでも記法を整理しただけのもので、方法論についてはスリーアミーゴス内でも意見統一をみることはできませんでした。オブジェクト指向システムの標準化を目的に1989年に結成されたＯＭＧ(Object Management Group)からの要請に応える形で、オブジェクト指向をシステム開発で積極的に利活用できることを目的に、システム仕様の視覚化を意図したダイアグラム(図法)として公表されたものがＵＭＬです。

1997年1月にＵＭＬ1.0仕様ドラフト版の提案があり、仕様の精査と標準化を進めて同年8月にＵＭＬ1.1がＯＭＧに提出され、11月に採用となります。
その後はＯＭＧが仕様の策定と改訂を行ない、2005年になると改善版としてＵＭＬ2.0が完成し、その頃にはＵＭＬはモデリング言語として広く採用されるようになります。

オブジェクト指向

オブジェクト指向システム設計というのは、システム化によって実現したいことを具体的な事象(オブジェクト)としてとらえ、その事象がどのように構成され、どのように実現できているかを分析し、その分析によって得られた情報に基づいて、システムとして組み立てていくというものです。

たとえば電話機の場合、「電話をかける」と「電話をうける」の２つの事象を想定すると、まず「電話機」としての機能を実現するために何によって構成されているのかを考え、どうすると「電話をかける」機能を実現できるか、どうすれば「電話をうける」機能が実現できるか、という分析を行ないます。

分析した結果で得られたそれぞれの情報と処理手順を一つのまとまりにし、外部から与えられたメッセージによりそれぞれの機能が実現されるという「ひとかたまり」をオブジェクトとして定義します。オブジェクトとして位置づけられたものが機能を実現する単位であり、その一つ一つを組み上げてまとめあげたオブジェクトの集合をシステムと考えます。

オブジェクトは、ある機能が実現された結果を示すもので、どのように実現したかという手順(からくり)はオブジェクト内部の事情として隠ぺいされています。したがって、機能の変更が発生した場合、そのオブジェクト内部だけの変更で機能変更が実現できるというのがオブジェクト指向の考え方で、機能の変更により、あれもこれも変更作業が必要となってしまうという事態を防ぐものです。

ＵＭＬ図一覧

ＵＭＬは、システムの構造や仕様を図によって表現することで、誰にでもわかりやすく同等な理解が得られ、システム品質を確保することを目的とした表記法です。
ＵＭＬ2.0では、１３のダイアグラムが定義されており、構造図と振る舞い図に分類わけされています。

構造図

構造図(Structural Diagrams)というのは、システムの静的な構造を示すものです。

振る舞い図

振る舞い図(Behavioral Diagrams)は、システムの動的な振る舞い(動作や変化)を示すものです。

システム品質の高品質化

システム品質を高めるには、「ユーザのシステム要求」「ユーザ要求を実現するためのシステム設計」そして「設計内容をプログラムに実装する」、これらのトレーサビリティを確保することが求められます。
このトレーサビリティを実現するために有効なツールが統一モデリング言語(ＵＭＬ)です。

システム設計は、ユーザ要求とプログラム実装の「懸け橋」となります。
システム設計の品質を確保するには、誰もが間違わないよう、より詳細で具体的な設計手順が定義されていることが望ましいと考えられます。しかし、システム化要求は社会の変化に合わせて多様化し複雑化していく傾向にあり、システム設計もそれに合わせた改善改良が求められることとなります。
システム設計の考え方を一律固定的に定義してしまうと、今までに存在しない革新的なシステム化要請が発生した場合、アンマッチが生じてしまいます。そこで、設計の考え方ではなく、表現方法(設計内容の書き方)を共通化して誰もが間違えることなく設計内容を理解できる仕組みとして考え出されたものがＵＭＬです。

ＵＭＬは言語と名付けられていますが、ダイアグラムと呼ばれる、情報を２次元で図示する記述法となっています。ＵＭＬ2.0で定義されているのも、１３種類のダイアグラムです。
したがって、システム開発者だけではなく、ユーザへの説明用としても利用することができ、システム提案資料やシステム設計書に記載されることがあります。

システム要求の見える化

開発するシステムの品質を確保するには、ユーザのシステムへの要求内容を把握し、ユーザと合意をしておかなければなりません。それを実現する方法の一つとして、ＵＭＬの振る舞い図を利用しましょう。

「ユースケース図」を使用すると、ユーザがシステムに何を期待しているかが明示されるので、ユーザのシステムへの理解を深めることにできます。
「アクティビティ図」では、ユーザ内の担当者単位に業務の流れと作業内容と範囲を表現できるため、システム化におけるヌケやダブりを確認することができ、作業の効率化を図ることも可能となります。

システム設計の見える化

システムの設計では、ユーザが要求する具体的なシステム化の事例を「オブジェクト図」で表現します。
「オブジェクト図」で、具体的な事象と、その事象が実現するための手続きを挙げ、それを基に「クラス図」を作成します。
作成されたクラスの属性と操作を記述し、クラス間の関係を導き出すことで、要求された内容がシステムとして成立するかを見極めます。

システムの状態は、ユーザがシステムに対して行なう操作や処理等により変動していきますが、そういった状態が遷移する状況は「ステートマシン図」に記載されます。
また、「シーケンス図」は各プログラム画面での項目入力や結果出力などの動きをシーケンシャルに表現する図です。

システム規模が大きくなると、多くのＵＭＬ図が作成されることとなりますが、それらの図を見比べることで記述のモレやブレを補正しやすくなり、作成品質の均質化を図れることになります。

大規模なシステムでは、製作するプログラムが数百本から数千本というボリュームになり、プログラム製作者を多数用意しなければならなくなりますが、ＵＭＬの記法を理解しているメンバーであれば、プログラムで実現すべき内容を容易に理解でき、実装ミスの防止につながり、製作品質を高めることができます。

試験工程においても、設計内容が理解しやすくなるため、効果的な試験が実施でき、試験品質を向上させることができます。

システム品質の見える化

ＵＭＬを利用することで、設計品質・製作品質・試験品質のいずれも品質の評価がしやすくなり、最終的なシステム品質の確保につながります。