EclipseからのDerbyデータベース接続（Embedded）の作成
MementoWeaver開発記(6)
PersistenceManagerの実装に入るにあたって、Java Persistence API(JPA)を使用することとする。理由はJavaの習作のようなものなので使えるものは手広く使いたいから*1。
以前の中野ー新川での仕事でもJPAを使っていたが、もうすっかり忘れてしまっているので、開発環境の構築から始めなければならないし、そもそもまだDBMSの設定もしていなかったのでまずはDerbyのセットアップから。
EclipseからのDerbyデータベースの作成
まずはEclipseでDatabase Developmentパースペクティブを開き、Database Connectionsの上で右クリックし、New。で新規接続の作成ウイザードが立ち上がる。Derbyを選択して次へ。
まだDerbyの接続用のドライバを定義していなかったので、最初は何も表示されない。
右肩の＋のようなアイコンをクリック。
今回はDerbyを組み込み(Embedded)モードで使用するので、Derby Embedded JDBC Driverを選択する。ただし、初期状態ではDerby.jarが見つからないので警告される。
JAR Listタブを開くとDerby.jarを探しているけど見つからない、と言うような警告が出ているので、Derby.jarを選択してEdit JAR/Zip をクリック。FileChooserがあがってくるので、Derby.jarの場所を教えてあげる。Java7@Windows7の場合、デフォルトではC:\Program Files\Java\jdk1.7.0_13\db\lib辺りに入っている筈。
ここを設定すると警告が消える。
Propertiesタブで一応IDとPWDを設定する。後でも変えられるのでここで入れなくても良かったのかも。
ドライバの選択画面に戻ってくるとここでまたID/PWDを入力できる。DB名やファイルパスなどを変えたければここで変更する。
Test Connectionボタンを押して、Pingが通れば接続は出来たことになる。
Finishでワークベンチに戻ってくると、Database Connections以下に作成したMyDBが見えている。
どうやらEclipse上からはGUIでテーブルの作成とかは出来なさそう(調査不足かもしれない)なので、DDLを作成する。
Softwares Idea ModelerからDDLを生成する。
AmaterasUMLを入れたのだから、そこからDDLを出させても良いのだが、まだAmaterasUMLにERDを移していないので、Software Idea ModelerからDDLを生成する。
Tools->Generate Source Code でソースコードの生成ダイアグラムが表示される。
ここで生成する言語(SQL DDL)を選択してGenerateすると以下のようなSQLファイルが作成される。
-- Table Material -------------------------- CREATE TABLE [Material] ( [MATERIALID] [CHAR] (14) NOT NULL, [CREATEDYEAR] [INTEGER] NOT NULL, [CREATEDMONTH] [INTEGER] NOT NULL, [MATERIALTYPE] [CHAR] (1) NOT NULL, [MATERIALSTATE] [CHAR] (1) NOT NULL , CONSTRAINT PK_Material PRIMARY KEY (MATERIALID) ) -- Table TaggedMaterial --------------------------
このままではDerby用のDDLとしては使用できない*2ので、テキストエディタで以下を加工した。
- ブランケットを削除
- 各文の末尾にセミコロンを追加
- Null可能カラムには型定義の後に'NULL'が出力されてしまうので削除
また、以下については自分の誤りだったためモデルを修正。
AmaterasUMLの導入
MementoWeaver開発記(5)
ユースケース：「素材をインストールする」の処理を書きはじめる。
主に前回のコンポーネント図で言うところのInstall Processingのコンポーネントに相当する処理を実装する。
ここで行う主な処理は以下のような流れとなる。
- 素材ソース、ステージングエリアのパスをチェック
- ファイルリストの取得。.jpeg, .jpg, .mov を対象とする(大文字小文字は無視)
- 素材ソース内のファイル毎に以下繰り返し
- ファイルの最終更新時刻を取得
- ステージングエリアにファイル名を変更してコピー
- DerivationManagerに派生ファイルの作成を要求
- PersistenceManagerにインストール状況の登録を要求
- 次の画面に遷移
以下、気付いた点や追加で実施したことや感想などを雑多に列挙。
Java SE 7におけるjava.nio.file.Files
Java 7からnioにFilesクラスが導入され、ファイルの扱いがとても便利になった。
今までのJavaではファイルコピーするにも自分でChannelを作成するなどしなければならないとか、ある意味とてもクラス主義的で教条主義臭かったところが改善され、EoDの向上を実現していると思う。
上記のファイルコピーならば、Files.copy(Path src, Path target)で出来てしまう*1。
APIはFiles (Java Platform SE 7 )を参照。
あと、Javaメモ目次(Hishidama's Java Memo)はJavaで開発するときには毎回お世話になっているページだが、知りたいことが簡潔にまとめられていて何時も助かっています。ありがとうございます。
UMLプラグインの追加
概要としてのデザインを示すのであればSoftware Ideas Modelerによるお絵描きで良いが、やはり開発を始めると、より細粒度のクラス図程度は欲しくなってきた。
EclipseのAvailable SoftwareからJunoリポジトリを漁ってみたが、めぼしいUMLプラグインを発見出来なかったので、AmaterasUML(AmaterasUML - Project Amateras)の導入を試みる。
AmaterasUMLのダウンロード
AmaterasUML - Project Amaterasからzipファイルをダウンロードする。
UMLモデリングツール（お絵描き含む）の比較
MementoWeaver開発記(4)
(大幅に加筆・訂正)
前回でJavaFXの使い方の最初の一歩はなんとなくわかりそうな気がしてきたので、各種の設計ドキュメントを書いてみる。
その際に、いくつかのフリーなモデリングツールを試してみたので、選択の理由と評価(感想)をまとめておく。
ドキュメント種別と使用ツールの関連
現時点で作成するドキュメントとそのツールの関係は以下のとおり。
| ドキュメント | 使用ツール | 備考 |
|---|---|---|
| ユースケース図 | astah* community | Software Ideas Modelerから乗り換え |
| ユースケース記述 | LibreOffice 4(http://ja.libreoffice.org/) | フリーのツールでユースケース記述までサポートはしてくれないのでWriterを使う |
| コンポーネント図 | astah* community | 一般的に期待されるようなコンポーネント図とは一寸違うけど、社内的に言うところのCRDのレベルを描くために。Software Ideas Modelerから乗換え |
| クラス図 | AmaterasUML | Javaからリバースしたいのでastah* communityでは不可 |
| 状態マシン図 | astah* community | Software Ideas Modelerから乗り換え |
| ER図 | ERMaster | Software Ideas Modelerから乗り換え |
| その他 | LibreOffice | 一旦、上記にはまらないような文書はオフィスソフトで描くことにしておく |
いつもの事ながら有用なフリーウェアを開発されている関係者の皆様に感謝します。
モデリングツールの比較
現時点ではAstah*,AmaterasUML,ERMasterに落ち着いているが、他のツールについても試してみた感想などを簡単にまとめる(プライベートなので無料で使えるツールに限定)。
関心のある諸元
| ツール | 入手元 | 動作形態 | リバース | ユースケース図 | コンポーネント図 | クラス図 | ステートマシン図 | ER図 |
|---|---|---|---|---|---|---|---|---|
| astah* community | astah* community - 無償UMLモデリングツール | 単体 | 不可 | ok | ok | ok | ok | - |
| AmaterasUML | AmaterasUML - Project Amateras | eclipse | 可(クラス図) | ok | - | ok | - | - |
| ERMaster | ER Master | eclipse | 可(DDL) | - | - | - | - | ok |
| Software Ideas Modeler | http://www.softwareideas.net/ | 単体 | 未確認 | ok | ok | ok | ok | ok |
| Modelio | http://www.modelio.org/ | 単体 | 未確認 | ok | ok | ok | ok | - |
| ArgoUML | http://argouml.tigris.org/ | 単体 | 未確認 | ok | ok | ok | ok | - |
| Violet UML Editor | http://alexdp.free.fr/violetumleditor/page.php | 単体/eclipse | 不可 | ok | - | ok | ok | - |
感想
astah* community
国内での定番ともいえるモデリングツール。
UMLをスケッチするには結局のところastah*が最も使いやすいように感じた。
UML2系にも対応。
community版ではJavaからのリバースが出来ないので、これだけで閉じられないのが残念(有償版なら出来るようだが、自宅用ではお金を掛けられない)。
AmaterasUML
Eclipseプラグインであることは、ツールを複数立ち上げなくてすむという意味で1つのメリット。またJavaソースからのクラス図生成も行えるのはポイントが高い*1。
残念なのは、対応するモデルがユースケース図、クラス図、シーケンス図、アクティビティ図のみであること。
今回はステートマシンは欲しいと考えていたので主力にはなれず。
Javaの読み書きは行えるが、基本的にはお絵描きツールという認識(違ってたらごめんなさい)。
ERMaster
正直、これはすごい！って思った。ERモデリングのツールなんだけど、フリーでこの完成度は驚いた。
Eclipseプラグインであることも1つの利点だが、DDLのリバース/フォワードもメジャーなDBMSには対応している*2ようだし*3、基本的な作図については全く不満無し。
今まで使ったことのある他のERツール(フリー)と比較すると、特にメタデータの扱いが秀逸。
Software Ideas Modeler
何と言っても優れているのは、対応するダイアグラムのカバレッジの広さ。
UML,ER,BPMN等の比較的メジャーなダイアグラムから、「何それ美味しいの？」的なダイアグラムまで広範にカバーしている。
(その分、各ダイアグラムの扱いについて厳密性は失われているが。)
このツール1つでトップダウンアプローチのダイアグラムについては、ほぼ全て網羅できるのではないか？と期待して実際に使い始めてみたが、残念なことに若干Buggy。
ダイアグラムの構成要素を複製した時に、内部識別子的な何かの管理にバグがあるらしく、次に開いたときに図が書き換わっている、ってことが何度かあった。
このバグは一寸致命的なので今回は採用を見送る。
ArgoUML
以前に使っていたことのあるUMLモデリングツール。
特に欠点を感じているわけではないが、UML2系に非対応であることと、他のツールと比較して特に秀逸なところがあるわけでもないので今回は見送り。
作成したドキュメント
ユースケース図
要するに管理者がデジカメから素材を取ってきて、HTML(=メメント)を作ってというだけのツールなのでユースケースとしてはこの程度かと。
HTMLを作成する際には、素材に付与したタグをベースにして作成するHTMLを切り替える。
クラス図
クラス図はJavaと同期を取るために頻繁に更新されるだろうからここでは省略。Git上のプロジェクト内においておく。
ERD
一時的に付与したタグなんかを保管するためにDBにもデータを持たせる。
ADにも書いているけど、DBMSは導入が手軽なJavaDB(Derby)を使用することにする。
素材とタグの状態遷移は状態マシン図で表現する。
状態マシン図
ステートマシン(Material)
ステートマシン(TaggedMaterial)
データ配置
ユースケースの補足としてデータ配置のイメージをポンチ絵(Libre Office Draw)で表現する。
ファーストカットなのでまだまだ変更は入ると思うが、とりあえずこのような感じで進めてみる。
BOOK：要求定義工学入門
- 作者: Pericles Loucopoulos,Vassilios Karakostas,富野寿
- 出版社/メーカー: 構造計画研究所
- 発売日: 1997/10
- メディア: 単行本
- この商品を含むブログ (1件) を見る
読了。いかんせん15年以上も昔の本なので、戦術レベルの記載については一寸時代を感じてしまう。とはいえ、要求定義アクティビティそのものについての洞察には学ぶところも多かったし、何と言っても幅広い文献を指している意味で、手元に持っておきたいと思わされた。
でも、やはり冒頭に書いたとおり時代を感じる部分があるので、もう一度通読してエッセンスを再構成しておくのが吉かな。
なお、若干のかび臭さを感じたのは、CASEツールやAIへの素朴な楽観論。
どうも「CASEとはなんだったんだろう？」的な言説を目にすることが多いので、自分自身も若干バイアスは掛かっているかもしれない。
それでも、かつての技術者たちが夢見たCASE(のエッセンス)は薄く広く浸透しているはず。
DSL然り。
統合することで新たなCASEを作れるのではないかと妄想するのもまた楽しいかも知れない。
Ease Of Developmentの夢はまだ醒めていないんだろう。自分自身も。
