ssaarchive/UMLセミナー
をテンプレートにして作成
Check
[
トップ
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
開始行:
* UMLを使った開発について [#i19e0781]
※2006年にMCTにおいてUML勉強会で使用したテキストです。
#contents
**なぜUMLが作られたのか [#f66c67ff]
-UMLが作られた経緯をおさらいします。
-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人が、UMLという統一表記法を作り...
~
&size(20){''めでたし! めでたし!''};
***抜け殻になったUML [#uc28da92]
-統合に難儀していた方法論については、UMLに盛り込まれて...
-UMLはあくまでも表現方法の統一を行っただけです。
-したがって、UMLの知識だけでは実践で役に立ちません!
--UMLって大したこと無い?
--覚えるのは時間の無駄でしょうか?
***UMLはすべての方法論の基礎 [#wf52db24]
-肝心な方法論を除外してしまったUMLですが、
オブジェクト指向における分析、
設計手法の基本的なところは押さえてあります。
-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){''デスマーチ''};(日本語訳:八甲田山)」に陥るこ...
デスマーチとは、仕様バグ、実装バグが入り乱れ、ひとつバグ...
こうなると、スケジュールは大幅に遅れ、予算は超過し、クラ...
***デスマーチにならないために [#z9d9178d]
-細かなリスク管理
-仕様変更に対応する柔軟性
-正確な工数見積もり
↓
-プロトタイプによる検証(リスク駆動型)
-リファクタリングに耐える質の高いコード
-優れた開発手法により進捗の透過性を確保
もはやWaterfall型では不可能です!
**開発プロセス RUP (Rational Unified Process)の紹介 [#abb...
***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での設計が活きてくる [#a79...
-拡張性と柔軟性に優れたプログラムを作るには、設計が大切で...
-UMLによるクラス設計は、洗練された抽象化オブジェクトや綺...
-よく、「デグレードが怖くてコードを変えたくない」という話...
*UMLの大御所、iver jacobsonさんからの一言 [#tb7a098c]
CENTER:&size(30){''Good enough is better than best!''};
*参考文献 [#a88c77f0]
-ユースケースによるアスペクト指向ソフトウエア開発
イヴァー・ヤコブソン/パンウェイ・ング著
ISBN4-7981-0896-0
-独習UML第3版
㈱テクノロジックアート著
ISBN4-7981-0763-8
-ラショナル統一プロセス入門
フィリップ・クルーシュテン著
(出版元 ピアソンエドケーション)
#back
[[アーカイブに戻る>ssaarchive]]
終了行:
* UMLを使った開発について [#i19e0781]
※2006年にMCTにおいてUML勉強会で使用したテキストです。
#contents
**なぜUMLが作られたのか [#f66c67ff]
-UMLが作られた経緯をおさらいします。
-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人が、UMLという統一表記法を作り...
~
&size(20){''めでたし! めでたし!''};
***抜け殻になったUML [#uc28da92]
-統合に難儀していた方法論については、UMLに盛り込まれて...
-UMLはあくまでも表現方法の統一を行っただけです。
-したがって、UMLの知識だけでは実践で役に立ちません!
--UMLって大したこと無い?
--覚えるのは時間の無駄でしょうか?
***UMLはすべての方法論の基礎 [#wf52db24]
-肝心な方法論を除外してしまったUMLですが、
オブジェクト指向における分析、
設計手法の基本的なところは押さえてあります。
-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){''デスマーチ''};(日本語訳:八甲田山)」に陥るこ...
デスマーチとは、仕様バグ、実装バグが入り乱れ、ひとつバグ...
こうなると、スケジュールは大幅に遅れ、予算は超過し、クラ...
***デスマーチにならないために [#z9d9178d]
-細かなリスク管理
-仕様変更に対応する柔軟性
-正確な工数見積もり
↓
-プロトタイプによる検証(リスク駆動型)
-リファクタリングに耐える質の高いコード
-優れた開発手法により進捗の透過性を確保
もはやWaterfall型では不可能です!
**開発プロセス RUP (Rational Unified Process)の紹介 [#abb...
***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での設計が活きてくる [#a79...
-拡張性と柔軟性に優れたプログラムを作るには、設計が大切で...
-UMLによるクラス設計は、洗練された抽象化オブジェクトや綺...
-よく、「デグレードが怖くてコードを変えたくない」という話...
*UMLの大御所、iver jacobsonさんからの一言 [#tb7a098c]
CENTER:&size(30){''Good enough is better than best!''};
*参考文献 [#a88c77f0]
-ユースケースによるアスペクト指向ソフトウエア開発
イヴァー・ヤコブソン/パンウェイ・ング著
ISBN4-7981-0896-0
-独習UML第3版
㈱テクノロジックアート著
ISBN4-7981-0763-8
-ラショナル統一プロセス入門
フィリップ・クルーシュテン著
(出版元 ピアソンエドケーション)
#back
[[アーカイブに戻る>ssaarchive]]
ページ名: