UMLを基礎から理解する　――UMLでできること，できないこと

●UMLとはビジュアルな言語である

　開発チームのミーティングで，ホワイトボードに何か絵を書いて議論することがあると思います．設計仕様書を読みながらいきなりコーディングするのではなく，そのあたりにある紙に何か絵を描きながら，試行錯誤してコーディングすると思います（図2）．そのような絵には，けっこう重要な情報が含まれています．その絵を使い捨てにするか，残しておくか，そこが重要なポイントです．残しておけば，仕様書やソース・コードを再度読む回数が減ります．つまり，「百聞は一見にしかず」を利用できるわけです．

　では，どのような描きかたと残しかたが良いのでしょうか．各自が自己流の絵を描いていては，残しておいても効果が少ないので統一する必要があります．そこで，表記法と意味を統一したのがUMLです．

　UMLは言語（ここでは表記法も言語と呼ぶ）なので，開発方法論（「どのように設計するか」ということ）や開発プロセス（「どのような手順で開発するか」ということ）とは独立した存在です．しかし，実際にはオブジェクト指向プログラミングの考えかたが前提となっています．つまり，オブジェクト指向で開発するときの絵の品質を，設計成果物に高めるための言語と考えればまちがいありません^注1．

 注1；オブジェクト指向でソフトウェアを開発すると，中身が数行しかないサブルーチンなどがよく登場する．「ソフトウェアを理解するにはソース・コードを読むのがいちばん」と思っているベテラン組み込みエンジニアの技が使えない側面がある．たぶん，これもUMLが発展した要因だろう．

〔図2〕絵を描いて議論しながら，仕様をまとめていく