![[SSA]](https://www.techarts.co.jp/ssabanner.png "[SSA]")
* UMLを使った開発について [#i19e0781] ※2006年にMCTにおいてUML勉強会で使用したテキストです。 #contents **なぜＵＭＬが作られたのか [#f66c67ff] -UMLが作られた経緯をおさらいします。 -UMLを活用するにあたり、 -なぜUMLが必要になったかを知り、 -UMLを使う理由を理解しましょう ***意外に浅いＵＭＬの歴史 [#x6b1ea1b] -C++ができたのは1980年 -Javaができたのが1990年 -UML1.0は1997年 -UML2.0は2004年 -UMLはまだまだ発展途上である！ ***方法論の統合からUMLが誕生 [#hc7277b8] 90年代初頭に、 -BoochさんのBooch法（モデリング言語）、 -JacobsonさんのOOSE法（ユースケース分析）、 -RumbauthさんのOMT法（方法論）、~ などが入り乱れ、 オブジェクト指向の方法論や表現法の統一が なかなか達成できない状況になる。~ コマッタ… &size(20){''コマッタ…''}; ***とりあえず書式だけでも決めよう [#a45ec776] -ということで合意した3人が、ＵＭＬという統一表記法を作り出しました。 ~ めでたし！ めでたし！ &size(20){''めでたし！ めでたし！''}; ***抜け殻になったＵＭＬ [#uc28da92] -統合に難儀していた方法論については、ＵＭＬに盛り込まれていません。 -UMLはあくまでも表現方法の統一を行っただけです。 -したがって、UMLの知識だけでは実践で役に立ちません！ --ＵＭＬって大したこと無い？ --覚えるのは時間の無駄でしょうか？ ***UMLはすべての方法論の基礎 [#wf52db24] -肝心な方法論を除外してしまったＵＭＬですが、 オブジェクト指向における分析、 設計手法の基本的なところは押さえてあります。 -UMLは多くの方法論を表現し、 実践するためのベースとなっています。 -さまざまな開発手法や方法論を学ぶにあたって、 UMLの知識は必須です。 --つまり、UMLは最初の1歩なのです。 UMLはそれほど複雑でありませんし、 最初にすべてを知る必要もありません。 ***UMLと開発手法のコンビが必要 [#je457df9] -目的を達成するために、多くの開発手法があります。 -UMLは方法論（開発手法）を含んでいません。 -UMLは多くの実践的な開発手法とのコンビネーションで威力を発揮します。 --開発手法とはどのようなものがあるでしょうか？ **主な開発手法 [#c22abcd2] -ソフトウエア工学 - waterfall型 -XP(エクストリームプログラミング) - 反復型 -SCRUM - 反復型 -UP(Unified Process) – 反復型 -RUP(Rational Unified Process) – 反復型 ***Waterfall型開発手法とは [#r48196db] 古典的なソフトウエア工学に基づいている。~ 「要求」→「仕様」→「分析」→「設計」→「実装」→「テスト」~ という手順を踏み、各ステージを完全に消化してから次のステージに進む。原則的に逆もどりはしない。 -長所 --達成率の管理が容易 --完璧なドキュメントが残る --製品の品質を向上できる -短所 --開発途中での仕様変更ができない(設計からやりなおし） --思わぬ障害がでたときに破綻する(リスク管理が脆弱) --工数見積もりを誤ると大幅に遅延する(遅延なしは奇跡に近い) ***反復型の開発手法とは [#s1971c12] 1日から6週間ぐらいの短いサイクルでプロジェクトを区切り、そのサイクルを繰り返してプロジェクトを進めていく手法。 -長所 --仕様変更に柔軟に対応できる --早い時期にリスクを減らせる --プロジェクトの見通しが良い -短所 --設計、開発の要求スキルが高い ***デスマーチ [#i0725108] プロジェクトにとって、最悪の事態は~ ｢&size(18){''デスマーチ''};(日本語訳:八甲田山)」に陥ることです。~ デスマーチとは、仕様バグ、実装バグが入り乱れ、ひとつバグを取ると2つのバグが発生するといった泥沼の状態です。（よく聞きますね）~ こうなると、スケジュールは大幅に遅れ、予算は超過し、クライアントは怒り狂い、プロジェクトの責任者は更迭されるかクビになることでしょう。~ ***デスマーチにならないために [#z9d9178d] -細かなリスク管理 -仕様変更に対応する柔軟性 -正確な工数見積もり ↓ -プロトタイプによる検証(リスク駆動型) -リファクタリングに耐える質の高いコード -優れた開発手法により進捗の透過性を確保 もはやWaterfall型では不可能です！ **開発プロセス RUP (Rational Unified Process)の紹介 [#abb4233f] ***RUPとは [#c8b5c468] -Rational社が開発した開発手法。 -Unified Processをベースに拡張。 -最新のフィーチャーを取りれている。 -反復型の開発 -ユースケース駆動 -リスク駆動 -品質管理 ***反復(iteration)の概念 [#k17496e3] &ref(./rup1.png,75%); ***リスク駆動型 [#g811e65c] -リスクの種類 + 要求リスク --- システムに対する要求に関する誤解など + 技術リスク --- 安定性、設計技術、運用と干渉、製品サポート、将来性など + 要員リスク --- 適切な人材の確保や教育、チームワークや適性など + 政治リスク --- プロジェクトの利害関係者の圧力や対立からの干渉など &ref(./rup2.png); リスクの大きなものから積極的に解決していく、リスク駆動型の開発。 プロジェクトの初期段階で大きなリスクは減少する。 *アスペクト指向とは [#w4780538] -オブジェクト指向に取って代わるものではない -オブジェクト指向で表現しにくいものを実現 -ユースケースとの相性は良い -言語レベルでのサポートはこれから **アスペクト指向でできること [#v17881ae] すべてのコンポーネント、クラス、メソッドに、 横断的に作用する機能を実現する。 -セキュリティ管理 -ログ機能 -メモリ管理 -ファイル操作の最適化 -例外処理 -広範囲にわたる横断的な拡張 などをモデル化できます。 *ユースケース駆動 [#h27e922e] 要求仕様や実装方法など、 さまざまな問題を ユースケースを使って分析します。 **ユースケース分析 [#zab99c60] -最初に、必要最小限なデザインを行います。(Minimal design) -それに基づき、基本的なフローを作成します。 -たとえば、Webでの音楽データ配信サービスを例に考えて見ます。 ***音楽配信システムのユースケース分析 [#o94e7db1] &ref(./rup3.png,75%); ***基本フローをまず作ってみる [#d33d4db8] -ここで重要なのは、まず基本フローのみ動作するプログラムを作ってみることです。 -エラー処理、パスワード認証、ネットワークのアクセスは後回しで構いません。 -動作するものを作ることにより、原理的な検証とクライアントが望むイメージを確認することができます。 ***代替部、拡張部を順次作っていく [#w4cdfd0f] -基本部分の検証が終えたら、順次エラー処理や代替部、拡張部を作っていきます。 -先ほどのユースケースには、ネットワークアクセスについては記載されていません。ここでは、ネットワークのことは考えずに、ローカルのファイルにアクセスできればよいのです。 ***どんどん拡張していくと出来上がり [#t0d47461] -最初のユースケースには無かった、ネットワークアクセス、課金システム、ユーザー情報管理システムなどのユースケースを追加してゆき、システムを徐々に拡大していきます。 -ここでも、基本フローの検証から代替、拡張という手順を踏みます。 -すると、いつのまにか立派なネットワーク音楽配信システムが出来上がっているのです。 ***柔軟な拡張性が肝心 [#h5e53029] -このような、基本機能を拡張しながら作成していく手法は、拡張性に優れたプログラムでなければ実現できません。 -オブジェクト指向に則ってきちんと書かれたプログラムならば、拡張は容易なはずです。 ---(残念ながらアスペクト部に関しては通常の言語では冗長な処理になってしまいます) *拡張性に優れたプログラムは UMLでの設計が活きてくる [#a79cfd9a] -拡張性と柔軟性に優れたプログラムを作るには、設計が大切です。設計の段階で、オブジェクトの抽象化をしっかりと行うことが重要です。 -UMLによるクラス設計は、洗練された抽象化オブジェクトや綺麗なプログラムを設計するのに大いに役立つことでしょう。 -よく、「デグレードが怖くてコードを変えたくない」という話を耳にしますが、それは設計がきちんとされていない証拠です。論理的に設計されたプログラムならば、変更に恐怖を覚えることはありません。 *UMLの大御所、iver jacobsonさんからの一言 [#tb7a098c] CENTER:&size(30){''Good enough is better than best!''}; *参考文献 [#a88c77f0] -ユースケースによるアスペクト指向ソフトウエア開発 イヴァー・ヤコブソン／パンウェイ・ング著 ISBN4-7981-0896-0 -独習ＵＭＬ第３版 ㈱テクノロジックアート著 ISBN4-7981-0763-8 -ラショナル統一プロセス入門 フィリップ・クルーシュテン著 (出版元 ピアソンエドケーション） #back [[アーカイブに戻る>ssaarchive]]
