雇われるだけの人生から目指せ独立、社会人2年目なゲーム脳SEのブログ。更新頻度=週2~3回。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
いよいよVisual Editorの学習も終わりましたことですし、今回は張り切って抽象クラス図の続きと相互作用図を作成していきます。まずは思いつくまま、GUIを抽象クラス図に組み込んでみました。
・・・何だこれは。
イケてない、最高にイケてないです!イメージが全く沸いてきません。どうしたものでしょう。
原因を考えてみました。
そうだ!
やはりこんな時は紙に書き下ろしてみるのが一番です。画面イメージは眺めていてもアイディアが出てこないですし、後まわしにして先にロジックを考えましょう。
それから日本語名のクラスだと実装イメージがわいてこないので全部英語名にしてしまいましょう。
それからそれから、集約(Aggregation)関係はJudeでソースをはき出す際に配列にされてしまいますから、明示的にjava.util.List<E>をパラメータバインドして・・・
こうして新しく作成したクラスと既存のList<E>をテンプレートバインディング関係(bind relation)で結んで・・・
クラス名を削除すると匿名のバインドクラスができる!そこからさらに・・・
実パラメータを設定!よしうまくいった!
Listをそのままエンティティとして使うなんてのはナンセンスだから新しくリスト用のエンティティを作って・・・
よっし!これでどうだ!!
テンション上がってきたついでに相互作用図いってみるかー!
まずはノートブック作成のシーケンス図を作ってみるよ-!!
シーケンス図だから、こうやって適当にクラスとかオブジェクトを並べてライフライン(lifeline)を引く。余談だけれども、UML1.Xではオブジェクトからライフラインが伸びているイメージだけど、UML2.0では上の四角い箱やらよくわからない丸い記号も含めてライフラインと呼ぶらしい。線じゃあないのにラインだなんてなんだか変な話!
閑話休題、まずは俺(ユーザクラスのオブジェクトね)から画面(これはまだクラス構成が決まっていないから、暫定的にオブジェクトにしてみました)にボタンを押しましたメッセージを引いてみる!
すると画面からはよくわからない仕組みでロジックが呼び出される!
呼び出されたロジックはこれまたよくわからない仕組みで先ほど抽象クラス図で定義したNotebookListを画面に返すわけだ。すると画面はこれを受け取ってノートブックを画面に表示する。うむ、簡単簡単、実にシンプルだ。
ロジックをわざわざ画面と分離して、画面から直接NotbookListを作る仕組みにアクセスしないのは、画面の部分がSwing実装からWebアプリケーションに変化してもロジックを一切変更しないでそのまま移植できる強みがあるから。こうして画面表示(View)とデータやロジック(Model, Control)を分離する作りが世間でよく言われているMVCという奴らしい。
どんどんインスピレーションがわいて来た。それじゃ次はロジックからデータを取得してくるクラスに対してメッセージを送ってみるか!
ちょちょいのちょいっと。
まずはNotebookInstanceManagerさんにノートブック作ってくれーっとメッセージを投げる。
その内容を元にNotebookInstanceManagerはNotebookをNewする(コンストラクタを呼び出す)、これでNotebookがつくられた。
作られたNotebookをそのままにしていちゃプログラムが終了したらデータが消えてしまう。当然何かにデータを残さなくちゃならない。今回はデータベースなんて用意していないから、ファイルシステムを使う。だから、ファイルシステムに対して保存してくれーと命令を投げる。ここは今のところ、Javaの標準APIを使う予定。
本当ならココもパーシスタ層といって、永続記録装置・・・要するにデータベースとかファイルシステムとか・・・に対して、データを保存する専門のクラスを作る方がいいんだけど、あまり深く考えず省いた。まぁ、最初だし。
で、保存もできたらあとはこのノートブックをNotebookListにつめて返却すればいいんだけど、じゃあそのNotebookListはどこから用意するの?(当然中身が空だとまずい。最後に作ったノートしか入っていないリストが返されることになるから)とか、そもそも本当にcreateNewNotebookの返値はNotebookListでいいのかとか(ノート作るのに成功しましたサインだけ返せばよくって、その後もう一回ノートリストを取得するためのメッセージをコントローラから投げればいいんじゃないかとか)、それ以前にノートの保存に失敗したらどうするのとか、突っ込みどころがどんどん出てきてもう大変。だんだんテンションも下がってきた。今日はここまで!
・・・すみません、途中から思いっきりテンションだけで書き連ねてしまいました。
本当はもっと教科書(はじめて学ぶUML 第2版)に即した形で進めたかったのですが、私の習熟度不足のせいで上手く型にはめることができませんでした。もうノリとテンションばっかりです。お恥ずかしい。
ただ、この図を描いていて感じたのは、「行き詰まったらとにかく別の図を書いてみるとうまくいく」ことでしょうか。
とにかくわかっているところから表現しやすい図にどんどん落とし込んでいくと、視点も切り替わり次々とアイディアがわいてくるものです。もし皆さんもUMLを描く機会がありましたら、クラス図に行き詰まったら相互作用図を、相互作用図に行き詰まったらまたクラス図に戻って続きを描いてみるなど、理解度の深い場所から進めることを(勝手に)おすすめいたします。
それよりなにより、Judeのバインドパラメータの使い方がわかったのが今回の最大の収穫ですね。何度テンプレートバインディング関係を張っても上手くできなくって半ばあきらめかけていたのですが、まさか新しくクラスを作って、それに対して線を引いてから名前を消すとは思いませんでした・・・難しい。
今回はこのあたりで失礼いたします。次回は最後に沸いてきた突っ込みどころを今日作った図に反映していきます!
・・・何だこれは。
イケてない、最高にイケてないです!イメージが全く沸いてきません。どうしたものでしょう。
原因を考えてみました。
そうだ!
やはりこんな時は紙に書き下ろしてみるのが一番です。画面イメージは眺めていてもアイディアが出てこないですし、後まわしにして先にロジックを考えましょう。
それから日本語名のクラスだと実装イメージがわいてこないので全部英語名にしてしまいましょう。
それからそれから、集約(Aggregation)関係はJudeでソースをはき出す際に配列にされてしまいますから、明示的にjava.util.List<E>をパラメータバインドして・・・
こうして新しく作成したクラスと既存のList<E>をテンプレートバインディング関係(bind relation)で結んで・・・
クラス名を削除すると匿名のバインドクラスができる!そこからさらに・・・
実パラメータを設定!よしうまくいった!
Listをそのままエンティティとして使うなんてのはナンセンスだから新しくリスト用のエンティティを作って・・・
よっし!これでどうだ!!
テンション上がってきたついでに相互作用図いってみるかー!
まずはノートブック作成のシーケンス図を作ってみるよ-!!
シーケンス図だから、こうやって適当にクラスとかオブジェクトを並べてライフライン(lifeline)を引く。余談だけれども、UML1.Xではオブジェクトからライフラインが伸びているイメージだけど、UML2.0では上の四角い箱やらよくわからない丸い記号も含めてライフラインと呼ぶらしい。線じゃあないのにラインだなんてなんだか変な話!
閑話休題、まずは俺(ユーザクラスのオブジェクトね)から画面(これはまだクラス構成が決まっていないから、暫定的にオブジェクトにしてみました)にボタンを押しましたメッセージを引いてみる!
すると画面からはよくわからない仕組みでロジックが呼び出される!
呼び出されたロジックはこれまたよくわからない仕組みで先ほど抽象クラス図で定義したNotebookListを画面に返すわけだ。すると画面はこれを受け取ってノートブックを画面に表示する。うむ、簡単簡単、実にシンプルだ。
ロジックをわざわざ画面と分離して、画面から直接NotbookListを作る仕組みにアクセスしないのは、画面の部分がSwing実装からWebアプリケーションに変化してもロジックを一切変更しないでそのまま移植できる強みがあるから。こうして画面表示(View)とデータやロジック(Model, Control)を分離する作りが世間でよく言われているMVCという奴らしい。
どんどんインスピレーションがわいて来た。それじゃ次はロジックからデータを取得してくるクラスに対してメッセージを送ってみるか!
ちょちょいのちょいっと。
まずはNotebookInstanceManagerさんにノートブック作ってくれーっとメッセージを投げる。
その内容を元にNotebookInstanceManagerはNotebookをNewする(コンストラクタを呼び出す)、これでNotebookがつくられた。
作られたNotebookをそのままにしていちゃプログラムが終了したらデータが消えてしまう。当然何かにデータを残さなくちゃならない。今回はデータベースなんて用意していないから、ファイルシステムを使う。だから、ファイルシステムに対して保存してくれーと命令を投げる。ここは今のところ、Javaの標準APIを使う予定。
本当ならココもパーシスタ層といって、永続記録装置・・・要するにデータベースとかファイルシステムとか・・・に対して、データを保存する専門のクラスを作る方がいいんだけど、あまり深く考えず省いた。まぁ、最初だし。
で、保存もできたらあとはこのノートブックをNotebookListにつめて返却すればいいんだけど、じゃあそのNotebookListはどこから用意するの?(当然中身が空だとまずい。最後に作ったノートしか入っていないリストが返されることになるから)とか、そもそも本当にcreateNewNotebookの返値はNotebookListでいいのかとか(ノート作るのに成功しましたサインだけ返せばよくって、その後もう一回ノートリストを取得するためのメッセージをコントローラから投げればいいんじゃないかとか)、それ以前にノートの保存に失敗したらどうするのとか、突っ込みどころがどんどん出てきてもう大変。だんだんテンションも下がってきた。今日はここまで!
・・・すみません、途中から思いっきりテンションだけで書き連ねてしまいました。
本当はもっと教科書(はじめて学ぶUML 第2版)に即した形で進めたかったのですが、私の習熟度不足のせいで上手く型にはめることができませんでした。もうノリとテンションばっかりです。お恥ずかしい。
ただ、この図を描いていて感じたのは、「行き詰まったらとにかく別の図を書いてみるとうまくいく」ことでしょうか。
とにかくわかっているところから表現しやすい図にどんどん落とし込んでいくと、視点も切り替わり次々とアイディアがわいてくるものです。もし皆さんもUMLを描く機会がありましたら、クラス図に行き詰まったら相互作用図を、相互作用図に行き詰まったらまたクラス図に戻って続きを描いてみるなど、理解度の深い場所から進めることを(勝手に)おすすめいたします。
それよりなにより、Judeのバインドパラメータの使い方がわかったのが今回の最大の収穫ですね。何度テンプレートバインディング関係を張っても上手くできなくって半ばあきらめかけていたのですが、まさか新しくクラスを作って、それに対して線を引いてから名前を消すとは思いませんでした・・・難しい。
今回はこのあたりで失礼いたします。次回は最後に沸いてきた突っ込みどころを今日作った図に反映していきます!
PR
この記事にコメントする
カレンダー
10 | 2024/11 | 12 |
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
ブログ内検索
最新記事
(10/12)
(10/09)
(10/09)
(10/08)
(10/05)
カテゴリー
プロフィール
HN:
akisute
性別:
男性
職業:
システムエンジニア
趣味:
ゲーム・東方・ニコ動。あと散歩。
推奨環境
横幅900px以上、Firefox 3, Safari 3, Opera 9.5, Chrome 0.2以上。IE7ギリギリ対応。IE6未対応。