なぜ仕様型か

UMLによって変化したこと

UMLは少し前からずいぶんと話題になっています.ではオブジェクト指向が当たり前のものとなった,或いは,オブジェクト指向を学ぶのに楽になったかというと必ずしもそうではないように思います. これまで多くの場面で,業務分析や要件定義を行い,疑似コードや実体−関連図で内部処理や構造を記述し,プログラムを作っていくということが行われてきました.何も昔の話ではなくて今でも多くの会社はそうしているのだろうと思います.では,それにも関わらずなぜUMLという単なる表記法をありがたがってしまうのかを少し考えてみたいと思います.

  1. 共通語としてのUML 複数の会社でもの作りをするときには,何か共通の言葉がないと通じ合うことができません.UMLを使えば,それが可能になる.特に最近のように色々な会社が一緒になってソフトウェアを作る場合は重要である.一見妥当な意見です. しかし過去にそのような機会がありながら利用されることはなかった.例えば,国内で1990年前後に構造化分析・設計手法がブームになりました.今ほどではないにしろ書籍や雑誌にも記事がたくさんありましたし,最初で(もしかすると最後の)CASEブームもこの時でした.しかし,手法そのものが定着することはありませんでした(早くから始まった欧米の事情は別でしょう).

  2. 共通表記としてのUML 先の構造化分析・設計手法にもわずかながら派生形がありました.有名なHatley-Phirbaiによるリアルタイム拡張に対するこちらも有名なWard-Mellorの拡張といった様に.しかし,表記やその呼称には手法に通底する存在理由があります.単にある名前を四角で表すと云ったことでは統一できないのはいうまでもありません.

  3. 過剰な期待 少し逆説的かもしれませんが,必要な情報がないから売れる,ということもあるように思います.あまたのUML本もUMLそのものについて詳細に説明できても,自分の関心のある問題領域に関して必要なプロセス,技術を提示しているわけではありません.例えばリアルタイムに適用する場合をとっても,一方では,応答が早ければ良いという少し定義から逸脱した使い方もあれば,KHz単位で数百のタスクが動作する場合もあるわけですから,逆に云えば何もかもがかかれている筈はないのです.

これまで,構造化分析・設計やデータ中心設計にしろOMTといった主要なオブジェクト指向設計法にしろ,国内で広く定着するということはありませんでした.もちろん,名前は知っているとか,自分は使ったことがあるという方はいらっしゃるでしょうけれど,使われていたとはいえない. 何か理由がある筈です.例えば,当時はツールが高価だったとか(1セット揃えると1000万円を超えるものもありました),良いトレーナが少なかったとか,良い書籍がタイムリーに手に入らなかった,といった理由が考えられます.しかし,一番はそういった系統だった手法に余り関心が持たれていないということがあるのだろうと思います. もちろん,先にも述べたように単一の手法が,多様なソフトウェア開発を全て説明することはできません.しかし,それでも設計法に関心を持つことは,自分たちのやり方を少しでも良い方向に(場合によっては反面教師として)変えていくために必要だろうと思います. しかし,表記法のUMLにこれだけ関心が集まるのは摩訶不思議.意地悪にいえば,それが手法ではないからでしょうか?

開発上流における役割

一般に,分析はユースケースで完了し,その後はモデル図を書きながら最終的に実装と同等のクラス図を沢山使って終わりということがあるようです. 仕様を記述することや,上流設計を行うということが,この場合だと抜け勝ちではと思います. Nirvana は丁度この隙間を埋めます.

  1. 分析で現われたオブジェクトをクラス図を用いて表現します.
  2. 仕様は,これらオブジェクトをインポートしながら記述します.
  3. 仕様型を詳細化しながら設計型とします.
    Nirvana はこの記述を行うために最適の機能を保持しています.

トップ   差分 バックアップ リロード   一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-06-22 (金) 18:49:47 (176d)