UMTP UMLモデリング技能認定L3 - たこはちの「へのかっぱ」日記

UMTP UML モデリング技能認定L3について調べてみた。120分でモデリング文章題3問、モデリングの際に必要な知識を問う小問題5問で、正解率60％程度以上が合格となる。

しかし、どの程度の難度なのかよくわからないのだ。L3については具体的なシラバスも開示されていないし、開示のサンプル問題もわずかだ。雑学王を目指す認定試験でもないのにシラバスが事前提供されていないというのは問題だとは思う。設計の原理原則、モデリング技法といってもどの範囲で網羅すればいいかが分からないので取り組みにくい。それでも、少ないUMTPの公開情報やL3サンプル問題、また既に受講された方のブログなどを参照してみると、以下のようなキーワードで出題されていることはわかった。



■オブジェクト指向に関係する原理原則

    ■設計の原理原則

        ・結合度と凝集度

    ■オブジェクト指向分析の指針

        ・概念モデリング（サンプル）

    ■オブジェクト指向設計原則

        ・リスコフの置換原則

        ・契約による設計(Design by Contract)

        ・GRASP

        ・継承（スーパークラスとサブクラスの特性を問う）（サンプル）

■モデリング技法

    ・ビジネスプロセスモデリング（サンプル）

    ・CRCカード

    ・ロバストネス分析

■OCL（オブジェクト制約言語）

    ・会社・社員・夫婦の関係（サンプル）

    ・預金口座での預入・引出・残高確認（サンプル）

■モデリング問題の例

    ・漫画喫茶のクラス図（サンプル）

    ・クレーンゲーム機のクラス図とステートマシン図（サンプル）

    ・試験管理に関するクラス図での属性／多重度／派生属性

    ・クロスワードパズルに関する２つのクラス図の比較

    ・組込系でのステートマシン図の穴埋め 

    ・オセロのアルゴリズムに関するアクティビティ図とクラス図

    ・WRC(ラリー)に関するクラス図

    ・音楽教室に関するクラス図

サンプル問題を見たが、なんとか70％くらいは正答できそうではある。しかし「正しいものをすべて選択せよ」形式や穴埋めなどの問題ですべてが正答できていないと0点となるような採点方式だと50％くらいしか得点できないかもしれない。まだサンプル数は少なすぎて合否の判断が予測できないのだ。幸いにも、設計原則はある程度理解できているし、ビジネスモデリングやロバストネス分析は業務での実績もあるし、OCLも社内で学習したこともある。なんとかなりそうな気もしてきた。

一般的なソフトウェアエンジニアリングとしての設計の原理原則をまとめてみた。

■課題解決の原則	設計は、課題解決の原則に基づく。対象に与えられた課題(要件／仕様)に対して、考えられる解決策(設計)の候補を挙げ、それらの優位性を判定して、最適な解決策を１つに絞り込む。選択した解決策については、その正当性の評価を提示しておく。解が絞り込めない場合は、選択肢をぎりぎりまで保持してよい。 ※設計原則を参照のこと。
■アーキテクチャ設計	ソフトウェアの全体的な構造を一貫性のある概念で設計すること。システムを論理的な側面から階層構造を決定し、論理的な階層構造を物理構造に対応付ける。設計では、複数の候補を比較検討することでシステム課題に対する全体最適な解となり、また早期に決定することで分業が可能となり作業効率が向上する。アーキテクチャ設計は全体の見取り図(俯瞰図)となり、開発者間のコミュニケーションを円滑にすることができる。 ※アーキテクチャを参照のこと。
■モジュール化／モジュール分割／分割と統治	モジュールと呼ばれる個々に名前付けされたコンポーネントに分割すること。扱いやすいより小さな部分要素に分割し、それら要素を組織化する枠組み／方式にもとづいて統治すべきである。機能／責務によって小さな部分要素に分割し、プログラムが複雑になるのを避ける。
■モジュール独立性	モジュールは、だた一つの目的を持った機能を実現するために設計し、他のモジュールとは必要される最低限の相互作用に留め、モジュールの独立性を高めるべきだ。変更に強い設計を目指すことができ、変更や問題が影響する範囲を狭くできる。
■低結合度と高凝集度 (coupling/cohesion)	結合度はモジュールと他のモジュールとの関連の強さであり、凝集度はモジュールが機能的に独立している度合。モジュール間の結合度が低いほうが良い。修正や問題が影響する範囲が少なくなる。モジュール間の結合度が低いと、一般に再利用率が高まる。
■抽象化	抽象化とは、重要な部分に焦点を当て、本質的でない部分を省略すること。手続き抽象とデータ抽象がある。設計上の複雑な問題を解くには、抽象化を利用して問題を単純化／一般化することが必要。対象を抽象化することにより、設計者が同時に扱うべき情報量を減らすことで設計作業を効率的に進めることができる。抽象レベルを上げることにより、対象の要素間の結合度を下げれ、対象から本質的なデータと手続きを見出すことにより、共通化すべき部分が識別でき、また本質的でない(一般に変化しやすい)部分を本質的な部分から切り離すことができる。
■段階的詳細化	設計は抽象化のレベルに合わせ、高い抽象レベルから低い抽象レベルへと段階的に詳細化を行うべきだ。段階的により細かなモジュールへと分解していくこと、段階的に記述の詳細レベルを高めること(詳述化)の2つの観点がある。 ※段階的詳細化を参照のこと。
■パターンの適用	パターンとは、特定の状況下で繰り返し現れる問題に対して、立証された共通の解決策だ。アーキテクチャ設計では、レイヤ、MVC、パイプ&フィルタなどのアーキテクチャスタイルが適用できる。アーキテクチャを考えるときの良きリファレンスであり、持っている課題とそのパターンが解決する課題と突き合せることにより、容易にアーキテクチャ候補を選出でき、統一された／一貫性のあるシステムを構築できる。詳細設計では、アーキテクチャスタイルよりも抽象度が低く局所的であるデザインパターンを適用できる。
■情報隠蔽 (カプセル化)	モジュールは自分が持つ情報(手続きやデータ)について、必要としない他のモジュールから参照できないように設計する。
■契約による設計 (Design by Contract)	構成要素の機能、操作／手続きは以下の3条件を明確にしておくことで、仕様の曖昧さを排除できる。契約とは、サプライヤ側(機能を提供する側)とクライアント側(機能を利用する側)の間で責任の所在を明確するための条件の集合である。 * 事前条件…… 操作が開始可能な前提条件 * 事後条件…… 操作が終了した時点で満たされる条件 * 不変条件…… 操作により変化しない条件
■複雑さの最小化	プログラムを読みにくくさせる複雑なデータ構造や難解な処理手続をできるだけ排除し、複雑さの低減を図ること。巧妙なコードよりも、簡潔で読みやすいコードを記述する。また複数の実現方法が考えられる場合、よりシンプルな方を選択することだ。
■変更の予測 (変更容易性)	将来の外部環境の変化によってプログラム変更が必要となる箇所を予測しておく。変更が予測される部分は分散させない。モジュールや操作は小さく作る、大域変数を少なくする、シンプルなアルゴリズムを採用するなど。
■テスト容易性の考慮	第三者がテストしやすく、バグを発見しやすいように設計すること。レビュー、ユニットテスト、自動テストが可能なようにモジュールを設計する。
■リファクタリング	機能や振る舞いを変えることなく、コンポーネントの構造を最適化すること。重複をなくす、非効率なアルゴリズムの改修、よりシンプルな構造にするなどを目的に行う。

またオブジェクト指向設計に関係する原理原則やパターンを挙げておく。

■単一責任の原則 (Single Responsibility Principle)	クラスは、ただ１つの責務／役割を持った機能を実現すべきである。１つの理由のみによってクラスが変更され、役割をテスト単位として単独でテストできる。複数の責務を与えると、巨大化し、変更が複雑化し、保守性が悪くなる。
■オープン・クローズドの原則 (Open-Closed Principle)	ソフトウェアの構成要素(クラス、モジュール、関数など)は拡張に対して開いていて、修正に対して閉じていなかればならい。拡張に対して開いているとは、構成要素の振る舞いを拡張できることであり、修正に対して閉じているとは、モジュールの振る舞いを拡張しても既存のモジュールは変更の必要がないということだ。
■リスコフの置換原則 (Liskov Substitution Principle)	派生クラスは、その基本クラスと置換え可能でなければならないし、基本クラスが許可する全てを許可しなければならないということ。
■依存性逆転の原則 (Dependency Inversion Principle)	上位モジュールは、下位モジュールに依存してはならない。下位モジュールの抽象(目的)に依存させ、実装の詳細に依存させてはいけない。
■インタフェース分離の原則 (Interface Segregation Principle)	クライアントに、クライアント依存しないメソッドへの依存性を強制してはならない。インタフェース内の強い関連があるものをグループ化して分離する。
■GRASPの適用 (General Responsibility Assignment Software Pattern)	モジュールに責務を割り当てる際に原則であり、9つのパターンで構成される。情報エキスパート、生産者、コントローラ、疎結合性、高凝集性、多相性（ポリモルフィズム）、純粋架空物、間接化、バリエーション防護だそうだ。コントローラやポリモルフィズム、は馴染みがあるが他のものはよく分からない。また別途調べておこう。