PowerPoint プレゼンテーション

Transcription

1 オブジェクト指向 プログラミング演習 第 4 回 UML

2 前回までのお話 モジュール化 オブジェクト指向 Java での書き方 ソースコード : クラスの定義の並び クラスの定義 : 中身はフィールドの宣言とメソッドの定義 継承 / インタフェース フィールドの宣言 メソッドの定義 オーバーライド main メソッド 絵が描けて クリックに反応できれば 最低限の GUI が作れる 簡単な GUI のサンプル

3 今日のお題 設計 MVC ユースケース図 (use case diagram) クラス図 (class diagram) 状態機械図 (state machine diagram) UML の一部

4 MVC Model View Control モデル, ビュー, コントロール ユーザインタフェースを持つプログラムを設計するときの指針 次のような部品に分けて考えると分かりやすい : モデル : 対象を表現するデータ データを更新するコードも含む ビュー : モデルをユーザに提示する表現 モデルをもとに描くコード コントロール : ユーザからの入力をモデルに伝える

5 MVC を Java で書くときの概形の例 public class Control implements MouseListener { } Model model; View view; Control() { } model = new Model(); view = new View(model); // Frame を作って View を追加する // View の MouseListener として this を指定する public void mouseclicked(mouseevent e) { } public static void main(string args[]) { new Control(); } class Model { } class View extends Canvas { } Model model; View(Model model) { this.model = model; } public void paint(graphics gc) { } Model のインスタンスを作って覚えて置き View に同じものを渡す 渡された Model のインスタンスを憶えておく model をもとに画面を描く OOP5.java にモデルを追加した形の例 ここでは Control を主体にしている 操作に応じて model のメソッドを呼ぶ model の変更後に view の repaint を呼んで画面を更新する

6 モデル ゲームの世界 ( 現実世界 ) データでどのように表現するかを決める モデルによる表現 ( コンピュータの世界 ) ある状態 操作 表現モデル化 データ ( ある値 ) 計算手順 操作などによる変化を表現したメソッドを書く 別の状態 ( 画面表示 ) 解釈 データ ( 別の値 ) データをもとに分かりやすく表示するコードを書く

7 UML: 作図するということ 自分で考えをまとめる 他人に考えを伝える 描き方に決まりがある UML(Unified Modeling Language) 図は作りたいシステムの一面を表す 図に表されない詳細があっても この図はそういうもの と割り切って描く

8 ユースケース図 利用者の要件を実現するためにシステムが実行する内容を記述する まず システムに分かりやすい名前をつける 個々の要件 ( ユースケース ) ごとに記述する 各ユースケースを分かりやすく簡潔に記述する システムの内側と外側を区別する システムの外側にある人や物を アクター とよぶ アクターはシステムが制御 操作できない システムの内側の機能を作る必要がある システムが実行する内容 ( ユースケース ) と それに関連するアクターを線で結ぶ

9 ユースケース図の例 (1) プレイヤー 七ならべ プレイヤーにカードを配る プレイヤーがカードを出す あがり を提示する システムを四角で囲む システムの名前を書く ユースケースを楕円で囲み システムに配置する アクターをシステムの外に置く 関連するユースケースとアクターを線で結ぶ アクターが人間でない場合も棒人間を使う ユースケースはシステムがやるべきこと ( 機能 ) を書くので 主語は システム に統一するとよい この例では プレイヤーが出したカードを受け取る など

10 ユースケース図の例 (2) Web ブラウザ URL の入力を受け取る HTTP リクエストを送信する ユーザ HTTP レスポンスを受信する Web サーバ Web ページを表示する 画面のクリックを検知し リンク先のページを表示する ユースケースの説明が長くなるのはお勧めしない ( システムが )X を Y する 程度に収める

11 ユースケース図の役割 システムが実行すべき内容 ( 機能 ) を整理する 各ユースケースを X を Y する と説明することで システム全体を それぞれ一つの機能を持った部品 ( メソッド ) の組み合わせと捉える 機能ごとに誰 ( アクター ) が関連するかを明確にする

12 クラス図 各クラスを三つの枠を持つ四角 ( 箱 ) で表す クラス名 フィールドの名前と型 コンストラクタとメソッドの名前と型を枠の中に書いて クラスの概要を示す クラスやメソッドに分かりやすい名前を付ける クラスを設計するときにクラスの仕様を書く 他人が書いたソースコードにあるクラスの機能を図示する クラス間の関係を矢印で描く クラス間の関係 : 使っている / 継承している

13 クラス図の矢印 クラス A の中でクラス B のインスタンスを使っている場合 : B が A の部品であって A のインスタンスの消滅と同時に B のインスタンスも消滅する場合 A B メソッドの引数や返戻値 変数 値を参照するためのフィールドとして使っている場合 さしあたり厳密に区別する必要はない A B クラスAがクラスBを継承している場合 BがAのスーパークラスである場合 A B よく分からなければ を使う B がインタフェースである場合 A B

14 クラス図の例 (1) 三角形の面積 ( 第 2 回 ) クラスごとに枠を三つ持つ箱を一つ描く v0:choten v1:choten v2:choten Sankaku Sankaku(p0:Choten,p1:Choten,p2:Choten) menseki():double main(args:string[]):void 一番上の枠にはクラス名を書く 2 番目の枠にフィールドを書く 3 番目の枠にコンストラクタとメソッドを書く 型は : を付けて後ろに書く x:double y:double Choten Choten(x:double,y:double) kyori(c:choten):double

15 クラス図の例 (2) 先ほどの MVC の概略 model:model view:view Control Control() mouseclicked():void main(args:string[]):void Model MouseListener mouseclicked(e:mouseevent):void mouseentered(e:mouseevent):void mouseexited(e:mouseevent):void mousepressed(e:mouseevent):void mousereleased(e:mouseevent):void Frame Frame(title:String) add(comp:component):component pack():void Canvas model:model View View(model:Model) paint(gc:graphics):void Canvas() paint(g:graphics):void 他人が作った部品を使うので 全部描くのは たいへん 自分が作るクラスはきちんと描く 他人が作ったクラスについては 関連が 深そうなところだけ描いて 適宜省略する

16 クラス図の役割 全体の部品は何か 部品の部品は何か それぞれが持つ機能は何か を考える 部品への分け方 ( モジュール化 ) を明確にする 機能を明確にする / どのクラスに計算手順を配置するかを明確にする クラス図に従ってプログラムを書く 明確にする という言い方をしているのは 唯一の正解があるわけではないからです プログラムを設計する人が決める必要があります

17 状態機械図 作業中の個々の過程を 状態 と捉えて 複数の状態の間の移り変わりを示すことで 作業の流れを示す 各状態に分かりやすい名前を付ける トリガー 各状態は 次の状態へ移るきっかけを待っていることを表す トリガーは ユーザの入力や時間経過

18 状態機械図の例 (1) 神経衰弱におけるプレイヤ 1 人の手番 1 人の手番 entry/ カードを 2 枚選ぶ 同じ数字のカードが選ばれ カードが全て取られた ゲーム終了 同じ数字のカードが選ばれ まだカードが残っている 角マルの四角を二段に分け 上に状態名を書く 異なる数字のカードが選ばれた 次のプレイヤの手番 状態の下の段には アクションを ( あれば ) 書く その状態になったときの動作があれば entry に書く その状態でいる間動き続ける動作を do に書く その状態から移るときの動作を exit に書く 開始状態を で描く 終了状態をで描く 状態の間の遷移を矢印で描き 遷移のトリガーを書く

19 状態機械図の例 (2) 状態の下段には アクションの代わりに 状態機械図を ( 入れ子に ) 描いてもよい 同じ数字のカードが選ばれ まだカードが残っている 1 人の手番 カードが 1 枚も選ばれていない カードを 1 枚選ぶ カードが 1 枚選ばれている exit/ 数字が同じか判定する exit/ ゲームの終了を判定する 同じ数字のカードが選ばれ カードが全て取られた ゲーム終了 異なる数字のカードが選ばれた 次のプレイヤの手番

20 状態機械図の役割 システムが行う作業の流れを 状態の変化 に着目して整理する どんな状態があり得るか を明確にする 状態から状態への移り変わり ( 遷移 ) のトリガーを明確にする 階層的に処理 ( 作業 ) を分析する 状態機械図からプログラムへ : 現在の状態を表す変数またはフィールドを用意する トリガーを識別して 状態を変化させる ( 変数やフィールドの値を変える ) プログラムを書く

21 課題に向けた演習時間 各自 自分の課題に向けた作業を してください

22 さぁ やれ と言われても 設計は大事 しかし やってみないと分からないことは まだ分からない 悩みすぎは時間の無駄 こんなんでいいんじゃね? という見切り発車が意外と役に立つ ( 開発の一周目 ) View( 画面 ) から作るのもお勧め 目に見える部分を作ると 実行して試して分かる できている感じがする モチベーションの維持は大事 あとで目に見えない部分を作ったとき それを見える形にする部分ができていると 確認が楽 画面の構成 : その程度の設計から始める 1. 状態が変化しても変わらない ( モデルを気にしない ) 表示 ここから始める 2. 状態が変わったら変わる ( モデルを参照しながら ) 表示 凝りすぎると時間がなくなるので ほどほどに

23 無駄や面倒を嫌がってはダメ 唯一の正解に早くたどりつけ という教育を受けて来た弊害? 無駄なく効率的に開発する ことを目標にしてはいけない プロでも難しい 最終的には使われないコードをたくさん書いている その方が結果的に速く開発できることを知っている 最初から効率的にやろうとすると 一歩も進めない 見切り発車をすると あとで全部書き直すことになるかも知れない 書き直せばよいのです

24 出席確認演習 : 進捗報告 今日の課題に向けた演習時間中に行ったことを 2~3 行で簡単に報告しなさい 報告の具体性に応じて 演習点をつけます ソースコードを書くことだけが進捗ではない 質問があれば ( 報告とは別に ) 書いてよい ( 週あけまでには できるだけ回答する努力をします ) 提出方法 :sec02@sun.ac.jp 宛にメール 提出期限 : この時間中 (14:30 まで )

25 出席確認 ( 進捗報告 ) について 具体的なことを書けない人 心配です 具体的でない例 ) 今日は 課題についての考えを整理していました 今日はゲームのプログラムを書き進めました 心配はしますが 学ぶ意志を示さない人を助けることはしません こういう報告をする人は たいてい何もしていません どこから手をつけていいか分からなくて 困っていませんか? もしそうなら どこから手をつけていいかわからない と素直に相談すべき