IT (情報技術) 学習記録

主に情報処理技術者試験、オラクルマスター、Linux技術者試験(LPIC)等の、IT系、または電気系の学習記録を中心に。(働き方や世の中も)

モデリング表意言語 UML (Unified Modeling Language) とは…本当に言語だろうか


モデリング表意言語 UML (Unified Modeling Language) とは…本当に言語だろうか


 UML (Unified Modeling Language) は、ドキュメントの記法の一種であり、良くも悪くも、それ以上でもそれ以下でもない。少なくとも現在の日本における大多数のシステム開発現場においては。

 確かにUMLの中の一部の図は、オブジェクト指向の言語や設計を強く意識したものとなっている。しかし、それはあくまでも一部である。(例えば「クラス図」は、その名称からもわかるようにオブジェクト指向を意識した図である。一方で、例えば「ユースケース図」は、あくまでも業務フロー分析のための図であり、オブジェクト指向とは直接的な関係はない)

 決してUMLによるドキュメンテーションが即、オブジェクト指向につながる訳ではない。


 UMLは確かに2000年代に流行したと思う。

 実際に、UML駆動型のCASEツールなども生まれた(UMLをINPUTとして、ソースコードのひな形をOUTPUTするツールなど)。しかし、UMLがそれ自体、直接コンパイルされて実行されるような性質のものではなく、あくまでもドキュメントの一種である事から、他の古来から存在するドキュメントと同じように、メンテナンスの問題(ソースコードとの乖離)を抱える事となった。

 日本の、特に官公庁や大企業における基幹業務系システム開発の現場では、UMLの誕生よりずっと昔から、設計書/仕様書の書き方について、独自にではあるが、研究されて来た。

 それは確かにオブジェクト指向には必ずしも向いていない、いわゆるプロセス中心指向のものであったとしても、“「業務ロジック」や「システムアーキテクチャー」を書き表し、ユーザーと共有する”、という目的のために研究され、工夫を重ねてきた背景がある。

 そこに、適用プロセスを敢えて定義していないUMLを導入しようとしても、効果は限定的となる。


 UMLが最も活躍したのは、おそらく「オフショア開発」といった異文化の人々が情報をやりとりする現場である。特に新興国のIT開発の現場では、古来からのドキュメントの蓄積などはなく、UMLがそのまま標準として利用できただろう。

 しかし、そもそもオフショア開発自体が日本の業務システム開発で成功しているかという点は、何とも言い難い。何しろ日本のシステム開発はカスタマイズのカタマリになっているので、オフショアでいくらコストを削減しても、中長期的に見ればシステムの改修(保守:エンハンス)で、かえってコストが増大する結果になっている面もある。

 オフショア開発とは異なるが、主として中小企業向けの「作りっぱなしの業務システム」においても、ユーザー企業側に成果物標準などが存在しない状況の中では、UMLはよりどころになる。

 現実的な位置づけとしては、ドキュメントの基礎素養の一つとして理解しておく必要がある事は確かとして、実際には他のドキュメント体系とも複合させつつ、うまく利用して行くものと言えるだろう。

 ここで言う他のドキュメント体系とは、例えるなら、上流工程向けの「Mind-SA」などである。


 2017年現在において、UMLに関する認定試験は、下記の2種類がある。

UMTP/Japan 特定非営利活動法人UMLモデリング推進協議会

UMLモデリング技能認定試験 UMTP

UML教育研究所 UTI

OMG認定UML技術者資格試験プログラム OCUP / OCUP2


 私はUMTPの方を8年前にLevel2(L2)まで取得したが、認定試験としては少々苦戦しているようにも思える。UML単独ですべてをやろうとする部分に無理が生じているのかもしれない…。