電子政府に国民という視点はあるのだろうか？

　さて、前にプロセス指向とオブジェクト指向の話を書きました。
　プロセス指向、構造化分析とその後のＤＯＡにより、ＤＦＤからＥＲ図に落とし込むという手法で、システム開発手法は、一応完結しました。
　この手法にのっとり、全社的な会社業務をトップダウンに分析していく１つの方法論が、（もともとは政府調達のために出来たから、関係ないけど）ＥＡといえると思います。
　そして、ＥＡは電子政府、e-Japanに採用され、今に至っています
（電子政府のＥＡにおいては、一部クラス図は表れるが、それはＥＲの代用であり、後述するクラス図の目的とは違う）。

　この手法は、会社や政府の業務をトップダウンに分析していきます。したがって、最終的には、こまかな業務にブレイクダウンされ、それをシステム化していきます。いわば役所なり会社なりのトップから下へおりていく、会社（電子政府の場合、役人）の視点からの業務分析といえます。

---

　オブジェクト指向の場合、このＥＲのデータとアクティビティ図、ユースケース図からきたユースケースを、クラス図にまとめます。そしてそのクラスは、オブジェクトであるモノという実体から派生させて考えたものです。つまり、現実にあるモノの視点で業務が再統合されます。

　たとえば、電子政府をオブジェクト指向で分析した場合を考えると、各役所で出てきた業務に対し、対象が、国民（市民？）の業務と必要なデータをもう一度、クラス図上で、まとめなおします。つまり、クラス図に書くとき、国民とか自治体とか、利用者の視点でもう一度まとめなおすことが出来ます。
　そこで必要なメソッドが抜けていたり、ダブっていたりしたら気がつきます。

---

　しかし、ＥＡには、クラス図を、そのような形（利用者からの見直しのカタチ）で利用することはないわけで。。。

　はたして、設計的に、そのようなやり方で、利用者の視点でモノを見てるんでしょうか。。
　役人の視点から見てシステム化するだけなら、単に利用者は、システムに振り回されて、より不便になるような気がする。

オブジェクト指向は、なぜクラス指向と言わないのか

　むかし、表題のようなことを書いているサイトがあったと思う。
　（そのサイトがどこにあるかは、わすれてしまったけど）

　今日、生物のお勉強をしていて、理由をおもいついたので、ちょっと書いてみる。

---

■たしかにオブジェクト指向はクラス中心に考えている

　たしかにオブジェクト指向では、クラスという概念を中心に考えている。
　Ｊａｖａで書くのもクラスだし。。

　でも、クラス指向とは言わず、オブジェクト指向という。。
　これはなぜ？

---

■そもそも、はじめにあったのは、プロセス指向

　そもそも、初めにあったのは、構造化分析などで行われる、業務を分析する、プロセス指向的なアプローチだった。
　これは、業務なので、動詞中心（つまり出来事、コトの世界）の話。

　でも、業務というのは、形があったり、目に見えるものではない。
　そのため、業務の内容が変わりやすく、また担当者により範囲も不明確なため、仕様変更も多かった。

---

■そこで、オブジェクト「もの」中心で考えるようになった。

　そこで、出来るだけ変わらないもの・・・というので、
　データ中心（データの構造は変わりにくい）を経て、
　モノの世界、名詞中心で物事を押さえるようになった。

　実在するモノで考えていくので、この場合、変わりにくい

　つまり、はっきりしないプロセス＝動詞＝コトの世界から、

　その実体がはっきりするオブジェクト＝名詞＝モノの世界へと

発想を転換した、それがオブジェクト指向ということになる。

---

■しかし、クラスには実体がなく、あいまい性が残る

　しかし、オブジェクト指向で利用されるクラスは、オブジェクトを
人の見方によって切り出したものであり、実体がない（クラスの実体は、
オブジェクトになってしまう）そうすると、業務同様、人が考えるもの
で、あいまい性（というか恣意性というか）がのこる。

　オブジェクト指向は、モノに立脚しているから、恣意性が入りにくい。
　そこが特徴になる。

---

■つまり、モノを言い表しているのがオブジェクト

　つまり、オブジェクト指向で重要なのは、
　モノの世界に注目したがゆえに、恣意性が減少するコトが言いたいわけで、
　それを言い表しているのは「オブジェクト」である。

　なので、オブジェクト指向なのかな？

---

と、生物の種（これは遺伝子プールとして実在する）と、
そのほかの目とか網とか（これは人間が考えたクラスわけ、分類）の違いの話を
放送大学大学院　生物環境科学２の話を聞いて思った。

ＤＴＰの構造を考える－その１４：まとめなど

　土日シリーズ「ＤＴＰの構造を考える」です。

　このシリーズ、第９回までで、本の構造、さらにＤＴＰソフト全体でもつ、フォント、色、ライブラリの構造を概念的に説明してきました。
　それ以降、機能のお話しを書いています。

　今回は、前回、ちょっと残っていた、位置決めの話をして、最後にまとめて、このシリーズをおしまいにしたいと思います。

---

■位置決めと再表示範囲で処理スピードがきまってくる

　さて、挿入・削除・属性変更で大きさ、高さが変わった場合、位置決めをしなおして、再表示します。このときの位置決めの範囲なのですが、変更があった文字以降は、もちろんなのですが、その前の文字も位置決めにかかわってくることがあります。
　たとえば、文字を挿入したら、行頭に”）”がきてしまう場合は、ふつう、行頭に”）”を持っていきません（行頭禁則文字なので）。この場合、その行の文字をつめて、”）”が文末にはいるようにします。追加した文字の箇所が行中でも、その行の先頭からその行の最後（”）”の字）までをつめるわけです。

　このように、修正の先頭は、その文字ではなく、その親（この場合、行）全体にかかわってきます。
　一方終わりは、たとえば、”。”のあと、行末まで結構開いていると、１文字入れても、そこで吸収されてしまい、次の行からは動かなくなります。そこで、この位置決めはここで終了していいことになります。
　このように、どこまでの範囲で再評価をどのようにさせるかで、処理スピードは変わってきます。

　また、どこまでの位置決めのルールをフォローするかという問題があります。
　英語でアルファベットが並ぶ場合、ハイフネーションをしなければ、その行に押し込まなければいけません。だから、いっぱい並べば、どんどん横幅を小さくして（長体をかけて）押し込むことになります。

　ところが、写研文化に従えば、長体は、４０％までしかかけません。

　さあ、どーする・・・そのままでは、入れられなくなります。
　ここで、字全体を小さくする（にも、限界があり、１、２級の文字とかは、あり得ない。３級ならルビであるかなあ？？）、自動ハイフネーションする（辞書があればね）、エラーとする、無理やり文字を切ってしまう。。

　などなど、どこまでがんばるかは、ＤＴＰソフトによってきます。

---

■キーボードショートカット

　一般的な編集ソフトの作り方で取り上げなかったＤＴＰの話題として、キーボードショートカットがあります。キーボードショートカットは、キーボードからイベントがあがると、モデルの処理を呼び出すようなコントローラーがあり（画面のイベントと共用してるかも。。）、そこで、制御しています。（もしくは、画面イベントに変換し、コントローラーに送るという手もあるが。。）

---

■まとめ

まとめると、ＤＴＰには、本があったとき、その素材として、文、写真（イメージ）、線画とあり、それぞれ、枠の中に入っています。文は、さらに行とか文字とかに分かれます。

　この、本ーページー枠ー（文、写真、線画）という、見た目の構造が物理構造で、このほかに、意味的な論理構造というのをもちます。
　これは、 一般的な編集ソフトの作り方　その１０：メモリ上への要素展開（共通要素の例）で示したように、メモリ上に表現するときは、これら要素の共通部分があり、これにより親子関係などが表現できるようになっていて、具体的な、要素固有の値（写真のファイル名や文字のフォントなど）は、この構造から継承した、各要素のクラスに記述されます。
（オブジェクト指向でない場合、各要素の構造体を持ち、そこにセットされています）

　そして、各要素独自の操作である位置決めや表示なども、共通要素から継承された各要素のメソッドに書きます（オブジェクト指向でない場合は、そういうクラスがある）

　このほかに、本やＤＴＰソフト全体で、色やフォント情報を持ちます。

---

　画面からある要素が選択され（どの要素が選択されているかを決める手法はアル）、何をするかのイベントが指定されると、コントローラーに入り、処理すべきモデルが呼び出されます。

　ＤＴＰソフトでは、画面－コントローラー各要素を操作するモデル部分に分かれ、バッチ処理、キーボードショートカットも、コントローラーに入るようになります（ＭＶＣの考え）

　モデルの部分としては、一般的な編集ソフトの作り方　その１２：イベント発生時の動き（概要）。で示したような基本的な動きがあり、これらが呼び出されると、本を親とした各要素を操作し、そのあと必要があれば、再度位置決め、表示となります。この操作方法は、各社各様にちがいますが、「行の構成アルゴリズム」という位置決めアルゴリズムが一応、ＪＩＳ規格としてあります。

　エクステンションは、動的にプログラムを読み込むことでも実現できます（他の方法もあるけど）

---

ということで、このシリーズは、ひとまずここでおしまいです。

次週から、土日シリーズ土曜日は、違う話をやる予定です。

500MBの無料オンラインストレージ「Windows Live Folders」日本語版今夏開始予定

ここのＧＩＧＡＺＩＮＥの記事
500MBの無料オンラインストレージ「Windows Live Folders」日本語版今夏開始予定
http://gigazine.net/index.php?/news/comments/20070628_windows_live_folders/

によると（以下斜体は上記サイトより引用）


マイクロソフトの無料オンラインストレージサービス「Windows Live Folders」が今年の夏にはベータ版から正式版になるそうです。

既に日本語版も入り口だけは用意されており、使用できる全容量は500MB。1ファイル当たりの最大サイズは50MBで、Windows Live IDを持っていないユーザーに公開することもできます。そのため、仕事で大きなサイズのファイルを渡す際に便利かも。


会社はもちろん、個人利用でも、USBメモリを持ち歩かないでいいというメリットはアル？？

ウィリアムのいたずらの場合、ここで作ったプログラム（いま、makebrewしかないけど）
なんかを、パブリック フォルダでみんなに公開できるかなあ？って思ってます
ここの文章

パブリック フォルダは、インターネット上のすべてのユーザーがアクセスすることが可能。ただし編集などは不可能。各フォルダとファイルには、それぞれウェブアドレスが割り当てられるので、そのリンクを送信するだけで、他のユーザーにファイルを公開することができるという仕組み。

を読むと。。。
そーすると、いま、＜　＞　￥　を全角にしてるけど、ちゃんとした
ソースをそこにおけるので、いいなあ・・・

ということで、ちょっと注目しています。

一般的な編集ソフトの作り方 その２４：まとめなど。。。

ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。
　ここでは、主に、

　　・メモリ上に、要素をもつ
　　・イベント発生時の動き
　　・画面の構成

ということで、今まで書いてきました。
　今日は今までのまとめと、触れていなかった、バッチ、コピーなどです。

---

■いままでのまとめ

　大きな流れは、

・画面でイベントが起こると、共有メモリを利用して、イベントを通知するメイン画面を
　探し出し、そこへ通知、さらに、データを変更する必要があれば、データを処理する
　モデル部分のメソッドを呼び出し

・モデル部分では「イベント発生時の動き」に書いたような、
　　　　・印刷
　　　　・保存
　　　　・読み込み
　　　　・カット（切り取り）
　　　　・ペースト（貼り込み）
　　　　・プロパティ（属性設定・変更）
　　　　・表示
　　　　・要素の選択
　　　　・（要素の）移動
　処理があって、それぞれの処理をおこなう。

・その際、データはそれぞれの型に応じて、
　　　　・挿入
　　　　・削除
　　　　・位置変更
　　　　・表示
　などの処理が記述してあり、モデルからの指示で、それぞれの処理を行う。

・その結果、再表示が必要なら、再表示などを行う

という流れでした。そして、それぞれの処理については、今まで書いてきました。

---

■バッチ

　で、ＤＴＰソフトの中には、バッチ処理ができるモノがあります。
　これは、画面表示をせずに、モデル部分を動かすものになります。

---

■コピー

　コピーは、
　　　・データ部分のメモリを保持し、それを挿入削除する
　　　・コマンドの形にしてしまい、それを実行する
　など、さまざまです。
　（デザインパターンでも、こー言うのがあった気がするが。。。）

　この保持の仕方によっては、「元に戻す」をしたときに、どこまで戻るかの
差になったり。。。するのかな（＾＾；）

---

っていうことで、このシリーズはいったんおしまいです。
もしかしたら、連結リストの形でのソース（前に示したのは配列・ベクター型だったので）
とかも示すかもしれない（しめさないかもしれない）けど、ま、とりあえず、このシリーズ
は、いったんここまでです（＾＾）ｖ

プロセス中心に画面割りした場合の、仕様変更による修正とマスタ保守抜け

　前に、プロセス中心に画面割りすると、オブジェクト中心にやるより、画面数が膨大に増えるという話題を書いたけど、それ以外のプロセス中心に画面割したときの問題について。

　プロセス中心、つまり、申請書作成とか、申請書編集、申請書削除などの、１業務で１画面で持ってしまった場合、画面は、その業務に必要な変数をもつことになる。
　したがってここで、申請書の項目が増えた、減ったなど、オブジェクト（＝申請書などの”もの”）の項目が変更になった場合、そのものを入力、出力にもつ、すべてのプロセスの画面を修正しないといけない。
　これは、修正量が多い

　まあ、もともと、前の話で、画面が増えると書いたのだから、修正が増えるのは、当然なのだが。。

---

　さらに、DOAが出てきた背景を考えると、データ構造以上に、プロセス、つまり業務というのは、変わりやすいということだった。

　まあ、本当にそうかどうかは？だけど、仮にそうだとすると、プロセスごとに画面割をしていると、変わりやすいっていうことになる。

---

　さらに、大きな問題になりそうなのは、マスタ関係の機能が抜ける危険があることかも。。

　クラス図で書いて行き、そのメソッドを元に、画面のアクションを作っていく場合、クラス図上に、CRUD（作成・検索・編集・削除）に相当する、ぞれぞれのメソッドがあるかないかチェックし、なかったら、付け足す。
　したがって、クラス図上にあるマスタにたいしても、保守機能は入る。

　しかし、業務プロセスごとに画面を作る場合を考えると、その業務プロセスは、要求から来る。要求は、基本的に、業務に関することしか出てこない。

　しかし、マスタファイル、マスタテーブルというのは、業務を行う前から存在しているファイル、テーブルをさすのが普通。ということは、業務のヒアリングにおいては、すでにあるものとして思われていて、それを作成する方法や画面については、一切考えていない可能性がある。

　そうすると、ヒアリングした業務プロセスを元に画面を作ると・・・
　マスタ保守関連が、ごっそり抜ける危険がある。

---

　いや、そーいう人がいたので、今回書いてみた。
（ウィリアムのいたずらではないよ。ウィリアムのいたずらは、たいてい、オブジェクトを下に画面割するので。。）

軍事利用して、ロボットがロボットに教える軍隊作ったら、すごいかも！

いやー、前田（みんみん）アナのトレンドたまごもすごいです。

ロボットが、動作も学習できるそうです。
TTF:2,092 どんどん賢くなる[07/6/27]
http://www.tv-tokyo.co.jp/wbs/toretama/070627.html

こうなってくると、軍事利用も考えられますよね。
ロボットが射撃隊になって、一斉射撃とか、海岸線を警備とか・・
ロボットなので、防弾チョッキ・・・というよりか、ロボット自体を強く作る？
それに、人とちがって、壊れても、大きく壊れなければ、修理できるし、
戦車などで、ロボットを破壊しても、こんどはその破壊されたロボットが
障害物となって行く手を阻み・・・

うーん、ロボットの軍隊、なかなか手ごわそうです。

---

きっと、そうなってくると、ロボットがロボットを教えることになるのかもしれません。

　まず、人間が教えて教育用ロボットを作り、
　（ここでは、仮に、ビリーという名前にしましょう）
　その教育用ロボット・ビリーが、他のロボットを教えると・・・

　こうなってくると、ロボットのビリーは２４時間教え続けることも
　可能だから・・すごい量のロボットを教育でき、ものすごい量の
　（ロボット隊員による）軍隊を作ることも可能になってくる・・

---

そう、賢明な読者には、気が付かれたかもしれませんが、
ビリーを使って、ブートストラップ式に軍隊（キャンプ）を作っていく、

まさに、

　ビリーズブートキャンプ

って、そーいうオチかい（＾＾；）

プロセス中心に画面割りすると、オブジェクト中心にやるより、画面数が膨大に増える

　画面割りについて。

　以前ここに書いたときは、画面割りは、主語、目的語というもの＝オブジェクトをベースに画面にして、その画面に対して、動詞部分のアクションをボタン等のイベントに対応させて、配置している。

　この方法とは別に、業務、プロセスを中心に画面を立てることもできる。
　　　申請書削除で１画面
　　　申請書作成で１画面
　　　申請書編集で１画面
　　　申請書検索で１画面
　といった具合だ。

　（前に書いた、オブジェクトベースだと、申請書一覧と詳細の２画面。一覧側に削除、新規作成、編集、一覧の上に検索部分があり、検索実行ボタンが横にあり、詳細画面に、登録ボタンがある。どちらの画面にも「戻る」ボタンがある）。

　で、どっちがいいとか、そーいうのは思想的問題になるので、別にいいんだけど、
　ただ、プロセス中心に画面割りをすると、画面数は膨大になる。

　たとえば、上記の場合、申請書が１０種類あったとしたら、その１０種類に対して、ＣＲＵＤ（作成、検索、編集、削除）と４０画面作ることになる。

　オブジェクトベースで考えると、申請書という画面から、個々の画面が派生しているといえる。
　この場合、申請書一覧は１画面にして、コンボボックス(selectのサイズ＝１）で申請書を切り替えて表示させることもできそう。さすがに個々の詳細画面は必要そうだけど。。

　そうすると、一覧画面＋詳細１０個＝１１画面と、２９画面もこの時点で少ない。

　それだけではなく、ＣＲＵＤの機能は一覧画面側についているので、新規に申請書を追加されても、詳細を作って登録するくらいなのに対し、プロセス中心だと、４画面作んないといけない。
　そして、画面数が多いと、適当にメニューを途中に入れてあげないと、わけわかんなくなるので、メニューも必要になる。

　という違いはある。

　他に、もっと大きな違いがあるのだが、話が変わるので、とりあえず、ここできります。

DS用ワンセグチューナー、年内発売へ

ここのニュース
DS用ワンセグチューナー、年内発売へ＝試作品を総会後公開―任天堂
http://headlines.yahoo.co.jp/hl?a=20070628-00000189-jij-biz
によると（以下斜体は上記サイトより引用）

＊任天堂 <7974> は28日、株主総会終了後の株主向け自社製品体験会で、携帯ゲーム機「ニンテンドーDS」向けワンセグチューナーの試作品を公開した。


おおお、ＤＳでワンセグですか・・・


価格について、同社は「数万円もするような高価な商品にはならない」（広報担当）との見方を示している。　

まじ欲しい。
貧乏人のウィリアムのいたずらにも買えそうな気が。。
外部出力できて、録画とか。。って、そこまで求めるのは酷（＾＾；）

いや、見れるだけでも、十分欲しい。

いや、ワンセグ見れなくても、実はＤＳ、欲しいんだけどね（＾＾；）

名寄せで解決しない年金記録問題。。。

っていう記事が、「日経コンピューター」に載ってましたね。
いや、最近忙しくて、きょう、ちょっとみたら、載ってました。
２００７年６月２５日号（特集が、「ERPパッケージがなくなる日」
の号）の１６ページ。

ニュース＆トレンド
名寄せで解決しない年金記録問題
社保庁の”宙に浮いた５０００万件”、政府案では困難

で、統合できない理由として、その記事では

１．そもそも５０００万件は、一度確認済みのデータ
　→確認して、確認できなかったのが５０００万件

２．転職で年金手帳を発行するのは、ざら
　　＝＞１人で複数の基礎年金番号を持ってしまう
　　さらに、転職したとき、生年月日を
　　「意図的に変えて」就職することもある・・・

３．５０００万件のうち、１００歳以上が１６０万件
　　記憶のあいまいな高齢者データは多い。

で、システムの名寄せは、
「柳沢厚労相が、NTTデータと日立の社長に依頼して
急に決まった」そうな
→実現可能性を現場が判断する前に決められた

（以上、上記記事より編集、引用）

---

うーん。。１００歳以上の人とか、死んでるんじゃないのかなあ？
生きてる人が１６０万件？まあ、生きてても、本人に聞いてもねえ・・

それと、就職するときに、生年月日を意図的に変える
＝年をサバを読む
たしかに、ありそうだ。。

その場合、たしかに、前の年金手帳とか、出せないよねえ。。
会社に（＾＾；）
年が、ばれちゃうもんねえ・・

奥が深い（＾＾；）

一般的な編集ソフトの作り方 その２３：画面の構成（エクステンションの実現）

ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。
　ここでは、主に、

　　・メモリ上に、要素をもつ
　　・イベント発生時の動き
　　・画面の構成

ということで、今、「画面の構成」をやっています。
　今回は、ツール機能などに入る、エクステンションについて考えてみたいと思います。

---

■エクステンションの考え方

　エクステンションは、ユーザーが勝手に（＾＾；）プログラムを作って、それを、何らかのイベント（自分が起動するか、画面の何らかの操作等をしたときに）のときに、テキトーな引数を渡して呼び出すっていうものです。
　これにより、ユーザー側では、いろんな処理を追加できるわけです。

　これを実現するには、動的にプログラムをリンクして呼び出す仕組みを使えばいいわけです。

　で、それについて、各社各様のやり方がありますが、まあ、とりあえず、以下のやり方を使えば出来るよ！というのを挙げておきます。

---

■Windowsの場合、DLLか、コマンドの実行

　Windowsの場合は、動的にリンクする方法として、DLLでオブジェクトをつくっておいてもらって、それを呼び出すということができます。
　呼び出すタイミングとDLL、引数などは、設定ファイルに書いてもらうという感じになるのかな？

　もっとも、DLLでなくても、コマンドラインで動くプログラムを、呼び出してもいいわけなのですが。。

---

■Javaの場合はリフレクション

　Javaの場合は、リフレクションを使って、DLLとおなじようなことを実現できます。

　リフレクションでクラスをロードするわけですが、どのクラスを、どのタイミングで呼び出すかについては、やはり、設定ファイルに書くのかな？

---

■Linuxはsoオブジェクト

　Linux等においては、ファイルの拡張子に.soとつく動的モジュールを作ることで実現できます。
　もちろん、コマンドラインで動くプログラムを、呼び出してもいいわけなのですが。。
　いままでと同様に設定ファイルでもいいわけですが。。

---

■WebAPIやソケット通信は。。。

　もっとも、このネット社会、REST型のWebAPIを呼び出すことによってエクステンションすれば、SOAちっくになって、もっと簡単に拡張できそうですけど・・そういうのは、みないなあ。。あるのかなあ。。

　あと、同様に、ソケット間通信にしちゃえばいいじゃん！プラットフォーム関係ないし・・と思うかもしれませんけど、確かにそーなんですけど、そういうのも、みないなあ。。あるのかなあ。。

---

■渡す引数
　で、操作できるように、引数を渡すわけなんですけど、このとき、今画面表示しているものそのものを渡すか、コピーして渡すか？という話があります。
　そのものを渡すと、ぐちゃぐちゃにされるリスクは・・・・

　まあ、あったりします（＾＾；）

クラスに原則として、CRUDのメソッドがないとこまる

　きのうの、要件を出すところから運用まで、一気に書いてみるで、

（４）機能要件の抽出（クラス図のメソッド部分）

のところで、

・（２）の名詞、つまり、主語か、目的語のクラスのメソッドに、
　　開発システムのアクティビティ図のアクティビティを埋める

と書いたところがありますが、メソッドを、主語と目的語のどちらに入れるかについての話。

---

■まず、原則、そのクラスのCRUDは、メソッドにある
これは原則論ですが、あるクラスの
　　・作成または追加（C:Create）
　　・検索（一覧）読み込みなど（R:Read)
　　・編集、更新、変更など（U:Update)
　　・削除（D:Delete）
を意味するようなメソッドは、そのクラスのメソッドとします。

たとえば、「申請書を作成する」というような場合、
申請書クラスに、作成(Create)メソッドがきます。

　ちなみに、Javaで考えると、Cはコンストラクタ、Rはgetter,
Uはsetter,Dはデコンストラクタ・・・は、Javaにはないけど、
closeとかremoveの処理に当たります。

---

■ただし、そうできない、しないほうがいいこともある。

　しかし、たとえば、削除をしようとしても、自分でメモリーを解放できないので、誰かから削除してもらわないといけない場合とか、Factoryみたいに、いろいろなものを生成するようなケースでは、この限りではありません。
　この場合は、主語のほうに入れたりします。

　また、たとえば、

　コンビニ（の店員）は、お客様に、ビッグ（サッカーくじ）を販売する

　という業務（なのか　＾＾；）があったとき、

　ビッグというクラスに「販売する」というメソッドをいれてもいいです。
　でも、コンビニのほうに、「販売する」として、引数を販売するもの（＝ここではビッグ）にしたほうがいいかもしれません。
　このように、主語がある動作をすることが重要で、目的語はいろいろと入れ替えられる場合、主語にメソッドを入れたほうがいい場合もあります。

---

■主語等に入れる場合、目的語をどこかに指定する

　上記の、

　コンビニ（の店員）は、お客様に、ビッグ（サッカーくじ）を販売する

　という業務（なのか　＾＾；）があったとき、
　コンビニクラスや、お客様クラスに「販売する」に対応する
　メソッドを入れる場合、

　メソッドを「ビッグ販売」にするか、
　「販売」メソッドの引数を「ビッグ」にして、目的語をどこかに入れないといけません。そうしないと、何を販売してるのか？？っていうことになります。
　「ビッグ販売」という場合は、販売しているものが一般化できない場合、逆に「販売」で、引数がビッグのときは、いろんなものの販売が一般化できる場合は考えられます。

---

と、この程度の注意点というか、方針はあると思います。
ただ、方針にあまり関係ないようなメソッドは、どこかに入れておけば（どこにいれていいかわかんなかったら主語、主語に入れておかしかったら目的語）OKだと思います・・・けどお（＾＾；）

要件を出すところから運用まで、一気に書いてみる

いままで、
・要件から、クラス図までに落とし込む流れ
・MVCで要件→モデルのクラス図から、コントローラーに落とし込む
・MVCで要件→画面に落とし込むまで
とまとめてきたので、それから先のプログラミングやテストまでも含めて、全部

一気に開発の最初から最後まで、書いてみました。

---

■要件から要求仕様まで
（１）要件の動詞部分に着目し、抜き出す
（２）動詞の主語、目的語を取り出し、
　　　「何々が、何々を、なんとかする」という単文の形にする
　　　→もし～ならば、「何々が、何々を、なんとかする」と、
　　　　条件がつく場合もある

（３）データ分析（クラス図の属性部分）
　　　・（２）の名詞、目的語は、「モノ」なので、これをエンティティとする
　　　・使っている帳票などを、
　　　　　　・第一正規形
　　　　　　・第二正規形（トップダウン方式、エンティティは上記クラス）
　　　　　　・第三正規形
　　　　まで行い、ER関係を明確にする（ER図、クラス図の属性作成など）

（４）機能要件の抽出（クラス図のメソッド部分）
　　　・（２）の動詞部分に着目し、現状のアクティビティ図を作成する
　　　・アクティビティをコンピューター化するとどうなるか考える
　　　・開発システムのアクティビティ図に書き換える
　　　・アクティビティ図のアクティビティをユースケースとして
　　　　ユースケース図に書き換える（やらなくても可）
　　　・（２）の名詞、つまり、主語か、目的語のクラスのメソッドに、
　　　　開発システムのアクティビティ図のアクティビティを埋める

（５）アクティビティの引数を（２）の要件から確認し、
　　　（動詞＝アクティビティ、名詞等は引数、返り値は目的とする結果）
　　　アクティビティと引数から、ユースケースシナリオを作成する
　　　（必要があれば）

（６）性能などの非機能要件をまとめる。

---

■外部設計－機能要件分析

（７）モデル部分のクラス図を作成する
　　・（３）でER図を作成していた場合、エンティティをクラスとすると、
　　　　クラスと属性が埋まる
　　　（クラス図を作っている場合も、ここまで埋まっている）　
　　・そのクラスに対して、（４）、（５）の操作で抽出したメソッドを
　　　適当に割り振って入れる
　　　割り振り方は、メソッドに対応する（２）の要件の、主語または目的語
　　　に対応するクラスに、入れる。

（８）フレームワークに何を採用するか決定する
　　　・サーブレット、struts等

（９）（７）のモデルのメソッドを以下のように用途別に分類する
　　　　・ユーザーが能動的に動かすもの
　　　　　　　画面を使ってアクションを起こす
　　　　　　　画面以外を使ってアクションを起こす
　　　　・ユーザーが意識しないけど動くもの
　　　　　　　自動的に条件がそろうと動く
　　　　　　　他アクションから呼び出し、直後に自動的に実行

（１０）フレームワークを元に、（９）のモデルに対応する（呼び出す）
　　　　コントローラーを決める
　　　・画面の場合、サーブレットを利用するなら、モデルの１メソッド
　　　　１サーブレットクラスになる
　　　　（strutsでも１メソッド１アクションクラス）

---

■外部設計－外部入出力（画面）

（１１）画面割りをきめる
　・比較的自由に決められるが、こういう決め方もある
　　（２）の要件は、
　　　主語（＝人）、目的語（＝対象物）、動詞（アクティビティ）
　　　の形なので、
　　　・まず、主語を確定する
　　　　　　＝＞ログイン画面で、操作している人を決定
　　　　　　＝＞この人が主語
　　　・目的語の画面を作成する
　　　　このとき、目的語が、複数あり、検索が必要な場合は、
　　　　　　　（検索）一覧画面（検索は画面をわけることもある）
　　　　　　　詳細画面
　　　　検索が必要ない場合は、
　　　　　　　詳細画面
　　　・１クラスに対し、CRUD(作成、（一覧）検索、更新、削除）は、
　　　　かならず必要なので、もし、メソッドがなければ補う

（１２）画面に、（１０）で決めたコントローラーを割り振る。
　　画面でイベントが起きたら、そのイベントが（１０）のコントローラー
　　を呼び出すことになるので、何らかの画面イベントにより、（１０）の
　　コントローラーがすべて呼び出されないとまずい。
　　　多くは、画面にボタンをつけて、そこから呼び出されるようにする
　　　たいていの場合、以下のようにボタン割をするとうまくいく。
　　　　・検索入力箇所（独立の画面または一覧画面と共有）：検索実行
　　　　・一覧画面：新規入力（追加）、編集、削除
　　　　・詳細画面：新規入力や編集の登録、キャンセル
　　　承認、承認拒否などの場合、一覧画面につけることも、詳細につける
　　　ことも考えられる。
　　　編集は、一覧の該当レコードのダブルクリックというケースもある。

（１３）画面遷移図をまとめる
　　　呼び出されたコントローラーが、どの画面を表示するかを確認し、
　　　画面を遷移させる。遷移しない画面が出たら、ボタンを付けて遷移
　　　させる

（１４）画面詳細をきめる
　　　モデルの引数は、すべて呼び出しコントロールあるいは、それ以前の
　　　画面において入力されていないといけない。
　　　それらをみたすように、画面項目をおいていき、値の範囲を決めて、
　　　画面詳細設計書にまとめる。

（１５）画面定義書の作成
　　（１３）、（１４）をまとめると、画面定義が出来る

---

■外部設計－外部入出力（DB）

（１６）DB定義書をまとめる
　　（３）のER図を書き換えると、DB定義書が出来る

---

■外部設計－機能要件分析　PART2（まとめ）

（１７）MVCにしたがい、各クラスを定義する
　Mについては、（７）、
　Vについては、（１５）で画面が決まっている
　　　→画面から必要なクラスはフレームワークで決まる
　Cについては、（１０）でクラスが決まっている
ので、その各クラスについて、内容を定義する。
　内容は、以下のとおりになる

・M（モデル部分）
　　コントローラーからの値をうけとり、基本的な処理をする
　　DBアクセスを行う
　　帳票、ファイル等外部入出力の操作もある。

・V（ビュー：画面部分）
　　イベントにおけるチェックなどの処理と、
　　コントローラーの呼び出し

・C（コントローラー部分）
　　引数を受け取り（処理することあり）、
　　モデルを呼び出し、
　　モデルから受け取った値を次の画面用に編集、セットする
　　次の画面を呼び出したり、書き出したりする

---

■内部詳細設計・プログラミング

（１８）（１７）できめたMVCの定義をもとに、
　　プログラム化していく
　　DBアクセスはJDBC
　　サーブレットにおける値の操作は、session操作、getParam,getWriter等
　　など、大体決まっているので（もしくはプロジェクトで決めているので）
　　それにしたがって、プログラムに落とし込む

---

■単体テスト
（１９）テスト仕様書の作成
　仕様上にでている条件を、
　IF文ならば、その条件を満たす場合と満たさない場合で
　switch文なら挙げられているケースで
　組み合わせを考え、同値条件を決める
　→ある条件が成立すると、自動的に他のじょうけんが成立する場合ははずす
　それと、境界値も考え、テストケースを仕様書に記入する

（２０）テストデータの作成
　テスト仕様書にそって、テストデータが必要なら作成する

（２１）テストに必要なプログラムを用意する
　テストプログラムは単体で動かない場合、
　　　テストプログラムを呼び出すプログラムがドライバ、
　　　テストプログラムから呼び出されるプログラムがスタブ、
　これら、スタブ、ドライバを必要なら作成する
　→ドライバとしてJUnitを使うと、きれいにテストできる

（２２）テスト実施
　テストを実施する。
　テスト仕様書にそって行い、エビデンスをとる。
　このとき、OKなら報告書にOKとする

（２３）（NGの場合）バグ票の記入
　もし、テストがNGだったら、バグ票に記入して、
　プロジェクトで決まっている人に渡す

（２４）（NGの場合）修正
　バグの担当者がバグ票を受け取り、修正

（２５）（NGの場合）修正確認
バグ票を発行した人が、（２４）の修正した旨のバグ票をもらったら、
バグが直っているかどうか確認し、確認したら、テストOKとして、
（２６）へ、NGなら、再度修正（２４）へ、

（２６）リグレッションテスト（回帰テスト）
　修正の際、新たなバグを入れている（デグレード）可能性もあるので、
もう一度、バグの箇所以外もテストしなおすことがある。
　これをリグレッションテストという。

---

■結合テスト

（２７）テスト仕様書の作成
　・画面設計書などにでてくる入力（入出力）項目に対し、
　　指定された範囲の境界値のテスト、
　　字種等のテスト、
　　SQLインジェクション、エスケープ文字、0、スペース、
　　入力しないケースなどの項目を挙げる
　・入力項目の組み合わせを行なう
　・要件を満たす場合についてのチェックを行う

それ以降は、（２０）～（２６）と同様である

---

■総合テスト

（２８）テスト仕様書の作成
　・要件仕様に書かれた、機能要件（業務）（１）にそって
　　その条件を満たしているかテスト項目をあげ、仕様書に記述する
　・要件仕様に書かれた、非機能要件（性能など）（６）に関して、
　　その条件を満たしているかテスト項目をあげ、仕様書に記述する

それ以降は、（２０）～（２６）と同様である

---

■運用

（２９）オペレーションマニュアルの作成
・要件仕様書の業務内容（１）にそって、業務手順を記述する

（３０）データ作成
・運用するためのデータを作成する
　既存のシステムからの移行の場合、データクレンジングを行ってから、
　新規システムへのデータ移行をする場合もある

（３１）移行手順・導入手順等の作成
　移行の場合、どのように移行をおこなうかの手順を作成する
　新規システムの場合、いつ、どのマシンを搬入し、どのソフトを入れるか計画

する。

（３２）納品（搬入）
　納品書を作成し、納品する。あるいはシステムを搬入する

（３３）運用
　（３１）の導入手順、移行手順に従い、実行し、
（２９）のオペレーションマニュアルに従い運用する。

---

以上っす。

JDBCのプログラムとその動作の関連、これで合ってるのかな？

JDBCのプログラム、たとえばここにあるように、ふつう

	// ドライバクラスをロード
      	Class.forName("org.gjt.mm.mysql.Driver");

	// データベースへ接続
	String url = "jdbc:mysql:///dbname?useUnicode=true";
	Connection con = DriverManager.getConnection(url);

	// ステートメントを作成して
	Statement stmt = con.createStatement();
	String sql = "SELECT * FROM TBL_A";

	// クエリーを実行して結果セットを取得
	ResultSet rs = stmt.executeQuery(sql);

という順番だと思います。このしくみ、とくに、Class.forNameで何の値もとっていないのに、DriverManagerが呼び出されるのか？について、あんまり書いていないので、多分こうなんだろうな？という勝手な妄想を書いてみたいと思います。

---

■（１）ドライバクラスをロード
　Javaのリフレクションという機能により、Class.forName("org.gjt.mm.mysql.Driver");とやるとorg.gjt.mm.mysql.Driverというクラスが、ロードされます。

　JDBCは、いろんなデータベース用で用意されているので、自分が使うデータベース用のものを、forNameの引数にします（こうすることで、引数が変われば、違うJDBCドライバが使えるようになります）

　クラスがロードされる際、staticの領域は（クラスで１つ用意する形なので）この時点で用意され、以降、staticのメソッドや値は利用できるようになります。
（new Integerとやってなくても、Integer.parseInt()というメソッドは利用できるます。これは、Integer.parseInt()がstaticだから）

---

■データベースへ接続

　上記の理由により、org.gjt.mm.mysql.DriverのクラスDriverManagerが提供する、staticなメソッドは使えるわけです。そのため、ここで、staticなメソッド、getConnectionを使って、データベースのURLに接続します。

　このgetConnectionでは、引数にもとづき、データベースのデーモンに対して、接続をこころみます。（つまり、そのデーモンのソケットに対して、書き出して、データベースにログインします）。

---

■ステートメントを作成して、実行

　接続したら、その後SQL文をつくって、executeQuery（検索）または、executeUpdate(それ以外）で、そのSQLを接続したデータベースに対して発行して、結果を受け取ります。

---

たぶん、こんなかんじかな。。

まちがってたら、ごめんなさい。

一般的な編集ソフトの作り方 その２２：画面の構成（共有メモリ）。

ワープロやドローイングソフトなどの編集ソフトを作る上での一般的な考え方を考える「一般的な編集ソフトの作り方」です。
　ここでは、主に、

　　・メモリ上に、要素をもつ
　　・イベント発生時の動き
　　・画面の構成

ということで、前回から、「画面の構成」をやっています。

　そして前回、たいてい、編集をするメインウィンドウと、属性値などをいれるサブウインドウをもっていて、サブウインドウの内容をメインウィンドウに反映させないといけないので、問題と書きました。それについて考えます。

---

■メインとサブのウィンドウ問題

　メインウィンドウとサブウインドウの問題は、これだけではなくて、メインウィンドウを２つ以上立ち上げられてしまったときのフォーカスの問題があります。
　サブウインドウで属性値を変更されたとき、どっちのメインウィンドウに対する操作なのか（フォーカスをしらべても、サブウインドウにあるだけで、どちらのメインウィンドウにもない）わからないという問題です。

---

■ウィンドウとドキュメントの問題

　また、メインウィンドウをいくつも作ったとき、同じドキュメントを編集したら、どうなるのか？という問題もあります。

---

■解決策１－メイン、サブ、ドキュメントでリンクを持つ＝問題あり

　単純に考えると、属性値変更用のサブウインドウと、メインウィンドウで相互リンクをもってしまうことです。
　こうすれば、サブウインドウで変更が起きたら、それとリンクしているメインウィンドウに変更通知を与えればできそうです。

　がしかし、２つのメインウィンドウで１つの属性値変更のサブウインドウを共有している場合、どっちのメインウィンドウ用か、良く分かりません。

---

■解決策２－共有メモリ（カオル姫方式）

　そこで、ここでいままで書いてきたカオル姫方式、つまり、

１．起動時に、共有メモリ（連想配列ないし、ハッシュマップ）を生成する
２．各画面は、その共有メモリにいれる。
　　　たとえば、メイン画面の１番目だったら、キーをmain1にして、
　　　データをその連想配列にいれる。
　　　サブウィンドウも同じく。
３．各画面では、生成時、その共有メモリをもつ
４．メイン画面のフォーカスも、その共有メモリの中に入れておく
　　　　　キー＝"currentWindow"
　　　　　値＝２でキーにした、画面名
　　メイン画面のフォーカスが変わるごとに入れ替える。
５．サブウインドウで変化が起こったら、共有メモリの"currentWindow"で
　　メイン画面名を取得、そのメイン画面名で、共有メモリを検索して、
　　メイン画面のクラスを取得する。
　　そしたら、変更処理をする

というふうにすればOKです。

---

■ドキュメントとメイン画面の関係

　で、ドキュメントも共有メモリにもてば、ドキュメントが変化したら、
そのドキュメントを利用しているメイン画面をすべて調べ、変更をかける
ということも可能です。

　可能ですが、しません。

　同名のドキュメントを開いても、別々に処理し、一方の操作が、他方に影響させないようにするのが普通です。

　そこで、共有メモリに名前を付けて入れてもいいのですが、
　メイン画面に直接ドキュメントを持たせてしまい、画面ごとに管理するという方法でも問題ないようです。