オブジェクト指向で開発の最初から最後までの手順例－その９：出力データ抽出

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今回は、ここの順番から言うと「（５－１－１）データの項目をだしてくる」です。

---

■出力データ項目をあつめる

　さて、データ項目を抽出するのですが、その際には、出力データとなっている項目をあつめます。
　入力項目は、出力項目を分析した上で、必要な項目を入力とするわけで、先に出力から考えます（これは、項目の話で、出てきたエンティティの関係は、入力出力関係なく、すぐにまとめます）。

　ただし、これは、入力項目を集めちゃダメ！という意味ではまったくありません。そうではなく、「出力項目を決めないで進んじゃダメ！」という意味です。
　どんどん開発が進んでいって、「あー、この項目、どっからも入力がないじゃん（＞＿＜！）」ってなっちゃったら、たいへんだからです。
（たまにあります　＾＾；）

---

■どうやってあつめるか？

　前に、主語と目的語の単文を作ったと思うのですが、そのとき、目的語となっているものの中に、出力があります。

　出力は、だいたい、こういうものが欲しいという要件で決まるか、今出力しているもの、作業に使っているものなどなどなので、必死にならなくっても、自然とあつまる・・はずです（＾＾；）

　要求が決まんないと、こまるんだけどね（＾＾；）

---

■今回は？

　発注情報がそれにあたり、これは、流通XML-EDIできまっています。
（今回は、２００３年だったかの拡張前のものです。それしか手元にないので）
　以下のとおりです。

＜＜メッセージ情報＞＞
メッセージID
データ作成年月日
発注企業.企業コード
発注企業.企業名漢字
発注企業.企業名カナ
受注企業．企業コード
受注企業．企業漢字
受注企業．企業カナ

＜＜ヘッダ情報＞＞
発注伝票番号
伝票作成年月日
伝票有効年月日
発注年月日
発注時間
発注管理番号
納品指定年月日
特価区分
企画コード
入力種別
伝票区分
納品区分
発注企業組織.伝票企画コード
発注部署.課コード
発注部署.売場部署名漢字
発注部署.売場部署名カナ
発注部署.発注担当者カナ
発注店舗．店舗コード
発注店舗．店舗名漢字
発注店舗．店舗名カナ
納入先．納入先コード
納入先．納入先名漢字
納入先．納入先名カナ
発注企業の分類コード
受注企業組織.伝票企業コード
消費税.税率
消費税.税区分

＜＜明細情報　明細＞＞
行番号
商品.GTINコード
商品.代替商品コード
商品.商品名漢字
商品.商品名カナ
発注情報．数量
発注情報．単位数
発注情報．単位入数
発注情報．原単価
発注情報．原価金額
発注情報．売単価
発注情報．売価金額
特価区分
消費税.税率
消費税.税区分

なお、

＜＜＞＞　は、エレメントの大項目
中項目.小項目　となっているのは、中項目がエレメントの２段目の項目
　　　　　　　小項目がデータ項目

中項目.　がないのは、エレメントの２段目の項目のないものです

---

ということで、次回から、
「（５－１－２）正規化理論を利用し、ER図にまとめる」
に入っていきます。

はてながブログ荒らしとかネットイナゴとか対策－「はてなスター」

ここのニュース
ブログ荒らしがなくなる？はてなが米国発新サービス「はてなスター」
http://news.goo.ne.jp/article/internet/business/it/iw2007071203-internet.html
によると（以下斜体は上記サイトより引用）


はてなスターは、ブログに設けられた専用ボタンをクリックすることで、閲覧者がエントリに対して「☆」を付けられるサービス。最近1カ月以内に☆を付けた相手は「Favorite」となり、互いに☆を付けあうことにより「Friend」登録される。自分が☆を付けた相手が、自分のブログを閲覧したときには「コメントボタン」が表示され、コメント書き込める。これにより、自分の気に入った相手である「Favorite」からのみコメントを受け付け、コメントの閲覧も「Favorite」からのみ可能となる。


スパム会社による、まとめサイトが増えたりして・・・

（１）なにかよさげなまとめ記事（というか、エントリそのまま引用）
　　　のブログをつくる
（２）星印をつけてもらったら。。。。
（３）そっこうで、スパムコメント
（４）そのあとは、違うIDを取得し、（１）に戻る

なめんどうなことはしないか・・


とかなんとかいう、心配は、ウィリアムのいたずらは、
一切いらないのだ。
なぜなら、Gooには、対応してないみたいだから（＞＿＜！）
（Gooは、JavaScriptは貼れないのだ。楽天も）

オブジェクト指向で開発の最初から最後までの手順例－その８：エンティティを再度まとめ

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今回は、ここの順番から言うと「（５－１－１）データの項目をだしてくる」を行う前に、ちょっと、やることを書いておきます。

---

■再度、エンティティをまとめる。

「（５－１－１）データの項目をだしてくる」の前またはあとにやる作業なのですが、ここまでのエンティティを再度まとめておきます。

　エンティティに関しては、「（１）エンティティの抽出」でやりました。
　しかし、その後、「（２）機能要求をまとめる」で、実際にはヒアリングしていたり、「（５－１－１）データの項目をだしてくる」でデータについて詳しく調べたりして、より深い情報があつまっています。

　正規化を行う前に、それらのエンティティをまとめておくのがいいとおもいます。

---

■今回の場合

　今回の場合は、オブジェクト指向で開発の最初から最後までの手順例－その３：エンティティ抽出で、以下のエンティティがでています。

　・発注
　・小売（発注者）
　・卸（受注者）
　・商品

で、その後、オブジェクト指向で開発の最初から最後までの手順例－その４：業務要件。で、小売には、（最終的に運ばれる）店舗と、納品場所（物流センター）があるという話になりました。

ってことで、

　・発注
　・小売（発注者）
　　　・店舗
　　　・納品場所
　・卸（受注者）
　・商品

っていうことになるとおもいます。

---

ということで、エンティティの再度まとめは、ここまで

エンティティと属性を決めてから画面チェックしないと、修正大変だよ（－＿－；）

　ある日、森の中、熊さんに出会った・・

　じゃなくって、ある日、システムを開発するのに、画面から決めている人たちに出会ったんだけど、先に、エンティティとその属性項目をきめて、値の範囲とかを決めないとだめっすよ。

（エンティティと項目は、要求仕様できまるし、そうでない場合は、画面の詳細設計の前に、DB定義をする）。

　だって、たとえば、ログイン名が何文字までなのか、日本語OKかわかんないのに、エラーチェックするって書いてもねえ（＾＾；）
　ERで、ユーザーエンティティ（テーブル）のログイン名は、英数字何文字とかきまって、はじめてエラーチェックできるわけで・・・・

---

　で、その場合なんだけど、エラーチェックはまとめたほうがいい。
（全部をまとめるか、属性ごとにメソッドをつくるかなんていうのは、些細な問題で、とにかく、まとめたほうがいい）。

　理由は、画面それぞれで、たとえば、さっきのログイン名チェックをしていたら、「いやー、ログイン名、いままで１５文字以下だったのが、６文字以上、１５文字以下にします」って言う具合に仕様変更になったら、画面の担当者みんなが直さなきゃなんなくなるよ（＾＾；）
　当然もれとか、矛盾も出るよね。

　で、画面によってテストケースが変わるような場合は、エラーチェックメソッドのほうで、きりわける。
　

---

　たとえば、全部まとめるエラーチェックの場合、

　int[] err_cheks(HashMap data,int[] chkList)

　みたいなかんじで、HashMapのほうに、キー（項目名）と入力値、chkListに、やるべきエラーチェック番号を設定する（小さいシステムの場合、chkListはいらない。ハッシュマップのキーからチェックすべきものがわかるから）。

　で、このとき、たとえば、種別が１０以下の数字で表す項目に、文字が入っていたら、範囲チェック（１０以下か？）は、する必要がない（できない）。
　なので、チェックリストに入っているものでも、あるエラーが起きたら、このチェックは飛ばすというのもある（内部的にフラグで制御する）

　結果がint[]なのは、ワーニングとかの場合は、いくつかエラーが立つ。
　致命的なエラーなら、そこでエラーチェックは終わり、１個だけ返ってくる。
　nullか、配列要素０ならOKってことですね。

　で、String getErrMsg(int errno);でエラーメッセージを拾うと。。。
（この場合、intの配列にいっぱい要素があったら、１番上からみて、致命的なものを選ぶ）

---

　で、そんなことはいいんだけど、そのエラーチェックメソッドerr_cheksって、自動生成できないかなあ。。今考え中（＾＾；）ｖ

ライブドア脱「ヒルズ族」 ３０日、赤坂へ移転。

ここのニュース
ライブドア脱「ヒルズ族」　３０日、赤坂へ移転
http://headlines.yahoo.co.jp/hl?a=20070710-00000910-san-soci
によると（以下斜体は上記サイトより引用）

　ライブドアホールディングスは、今月３０日に、本社を現在の六本木ヒルズ（東京都港区）から赤坂ツインタワー本館（同）へ移転することを明らかにした。前社長の堀江貴文被告（証券取引法違反罪で公判中）らによる粉飾決算事件の影響で経営が悪化したため、「移転でコスト削減を図る」としている。


移転で、コスト削減で。。。赤坂（＾＾；）
うーん、削減なら・・（＾＾；）

オブジェクト指向で開発の最初から最後までの手順例－その７：データ解析概要

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今回は、ここの順番から言うと「（５－１）データ解析ルート」で、きょうはその概要を書きます。

---

■データ解析ルート

　システムを考える場合、入出力となるデータと、それを処理するプロセスにわかれます。
　入出力は主に、主語、目的語となるエンティティの分析であり、これは、テーブルに関係してきます。
　一方の処理は、業務に関連し、アクティビティになります。
　これらをあわせたものがクラス図になるわけですが、今回のデータ解析ルートは、この入出力の分析になります。
　成果物はER図とします。

---

■データ解析ルートでやること

　データ解析ルートでは、ER図をだす＝テーブルの解析をする＝正規化ということになります。

　正規化は
第一正規形：繰り返し排除
第二正規形：主キーを決める（＝結果として主キーとの従属項目排除）
第三正規形：主キー以外で従属項目となるものの排除
という手順をとります。

このとき、第二正規形の作業をするとき

全項目を取り出し、項目間の従属関係を全部調べて・・・
というのもいいのですが（これをボトムアップ方式と呼ぶのかなあ？？）、

あらかじめ、エンティティを決めておいて（エンティティ＝主語、目的語となる実体）それに、どんどんデータを当てはめていき、その中から主キーを探す（これをトップダウン方式と呼ぶのかなあ？？）ほうが、はるかに簡単なので、こっちを採用します。
　とはいうものの、作業中に新たにエンティティを発見するということも、当然あるのですが。。

---

■手順のまとめ

　したがって、これらの手順をまとめると

（１）下準備
　　・エンティティをまとめる
　　・データ項目をとりだす

（２）正規化
　　・第一正規形：繰り返し排除
　　・第二正規形：主キーを決める
　　・第三正規形：主キー以外で従属項目となるものの排除

（３）まとめ
　　・ER図に描く

ということになります。

---

■これと業務との関係（データ解析を先にやる理由）

　で、業務との関係ですが、エンティティは、たいていテーブルなどになります。ということはですねえ、このデータのCRUD(生成・読み込み・書き込み・削除）は、たいていあるはずです（量が増えない場合、削除はないこともある）。

　かりにシステム外でも、システムガ動く前に、読み込むデータは何らかの形で生成されていないといけません。ということは、そういう業務ないし、作業があるということです。

　このように、エンティティから、業務のもれをチェックすることが出来ます。
　そのために、データ解析を先に行います。

---

次回は、「エンティティをまとめる」お話をしたいと思います。

CAPTCHAって、読めるか読めないかより、特徴点が、あるかないかなのか！

ここのスラッシュドットニュース
スパマーがCAPTCHAの突破に成功?
http://slashdot.jp/security/07/07/09/078257.shtml
に、CAPTCHAが破られた？っていう話がある。

で、それはどうでもよくて（＾＾；）

そのコメントに、
飾りじゃないのよCAPTCHAは ～前代未聞のCAPTCHAもどき
http://takagi-hiromitsu.jp/diary/20060810.html#p01
をリンクしてるのがあって、そのサイトを読んで気がついた！

そうか、CAPTCHAって、人が読めるか、機械が読めるかって言う問題じゃなくって、

・特徴点を出してきて、
・数字しか出ないCAPTCHAだったら、その特徴点が、１から９で異なっていれば、（英語ならAからZで異なっていれば）
・読みやすいか読みにくいかは関係なく、その数字は、ずばり！判定できるってことか・・

　特徴点抽出に関しては、拡大縮小されても、相対的位置関係などで、問題なくなってしまうかもしれないし。。。

　その数字に近いかで判断するとすれば・・

　・・・・

「セカンドライフ」日本向け正式サービスをにらみ、電通が最大級都市建設へ

ここの痛いニュース
「セカンドライフ」日本向け正式サービスをにらみ、電通が最大級都市建設へ
http://blog.livedoor.jp/dqnplus/archives/1001383.html

どーなんでしょーねー。セカンドライフ。

本屋さんでは、本がいっぱい出てる・・・

けど、その前出ていたRSSやWeb２．０の本が、
そのかわりに、今は、出ていないように、
次に何かはやったら、終わっちゃうのかなあ（＾＾；）

そのうち、電通は、この都市の建物のREITでも、発行するんだろうか・・・

マイクロソフト、内部統制文書化ツールとソースコードを無償配布

記事を見たけど、自分で中身を見ている暇が今ないので、
メモメモ。。

マイクロソフト、内部統制文書化ツールとソースコードを無償配布
http://opentechpress.jp/news/article.pl?sid=07/07/06/0127225&from=rss

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

　マイクロソフトは7月4日、「Microsoft Office Visio 2007（Visio 2007）」と「Visio 2003」上で動作し、内部統制の仕組み構築に対応した業務プロセスの文書化を支援するツール「Microsoft Office Visio 内部統制文書化ツール」の無償提供を開始したと発表した。


公開しているサイトは、以下のところ
Microsoft Office Visio 内部統制文書化ツール
http://www.microsoft.com/japan/office/2007/visio/naibutousei/default.mspx

オブジェクト指向で開発の最初から最後までの手順例－その６：主語、目的語の明確化。

オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今回は、ここの順番から言うと「（４）動詞から、単文にまとめる」です。

---

■単文にまとめる理由

　単文にするのは、述語に対する主語と目的語を明確にするためです。
　なので、別に単文にしなくても、これらが明確になるんなら、どうまとめてもいいんですけど、まあ、単文にしたほうがわかりやすいです。
　ただし、その文に条件がつく場合があり、その条件は、複文というか、複雑になっちゃうことがあるんですけど、これはOKとしましょう（でも、条件も単文化というか、一義的にとれるようにする）

　で、主語、目的語に使われるものは、たいてい引数などになります。
　（動詞が、主語、目的語のクラスに所属するとき、クラスの属性を使うので引数にならないということはある）

　主語は、アクティビティ図のスイムレーン、つまり担当者になります。

---

■今回の例

　今回の例では、動詞は、前回の結果、

・発注する
・確認する
・編集する

でした。これを文にすると

・発注者は、受注者に、商品を発注する
・発注者は、発注を確認する
・発注者は、発注を編集する

ここで、発注者は小売、受注者は、卸です。
「受注者が、発注を確認する（編集する）」ことも論理的には考えられますが、今回のシステムは、小売しか見ない（卸とは共有しない）ので、それについては考えないこととします。

---

　ということで、次は、プロセスのほうに行っても、データのほうに行ってもいいのですが、今回は、データーのほうを先にします（ある理由からデータのほうを先にしたほうがいいのです）。
　
なので、次回は「（５－１）データ解析ルート」についてです。

ケータイで爆弾の遠隔操作だって！

　フリーペーパーのＴｏｋｙｏＨｅａｄｌｉｎｅ、今出ている号（２００７年７月９日号）の３面、「木村太郎のニュースの真髄　第３２４回」の「英国のような捜査は多分期待できない日本の治安当局」に書いてあったんだけど、英国で起きた連続テロ事件で、ケータイを爆弾の遠隔起爆装置として使おうとしてたそうな・・・

　うーん、たしかに、ケータイでネットができるということは（さらに、そのケータイのアプリから外部入出力が操作できるということは）、遠隔操作も、できそうですな。。

　もちろん、そんなことに使うより、
　ラジコンとか、そーいうことに使ったほうがいいと思うけど。。。

　でも、悪いことは出来ません。

　結局そのケータイ、捜査当局に押収されて、逆にケータイのアドレス帳にいれておいた、仲間の連絡先から、どんどん仲間がわれていったそうな。。。
　仲間のケータイ番号から、今どこにいるかがばれてしまい。。。
　だそうな。。（＾＾；）

Hello World程度のデータベース（その２７：外部スキーマ（１１）ＳＱＬその１０）

　情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

いま、ＳＱＬをやっています。
ＳＱＬは検索(select)、挿入(insert）、削除(delete）、更新(update)とあって、今回はUPDATEです。

---

■ＵＰＤＡＴＥの構文

　ＵＰＤＡＴＥの構文は、

　UPDATE テーブル名 SET 項目名＝値,・・・・・ WHERE 条件式

のカタチです。
　で、このSET　項目名＝値の値に対して
　　・固定値をセットする
　　・同一テーブルの項目値を（計算して）セットする
　　・他テーブルの項目値をセットする
　というケースがあります。

---

■固定値をセットする

　これは、簡単で、たとえば、OUBO_TBLのOUBOIDが４の人のOUBONENを2006にする場合、
UPDATE OUBO_TBL SET OUBONEN = 2006　WHERE OUBOID=4;

でいいわけです。OUBONENは数字なので2006のように、数字をかいていますが、
SEI_KANAのように文字項目だったら、SEI_KANA='こうさか'のように、'でかこみます。

---

■同一テーブルの項目値を（計算して）セット

　値のところには、計算式（関数で計算した結果もＯＫ）がかけます。
　なので、たとえば、上記のもので、OUBONENを１足すというようにするのであれば、

　UPDATE OUBO_TBL SET OUBONEN = OUBONEN+1 WHERE OUBOID=5;

　となります。

　なお、計算式で計算する場合、同じ項目がいくつも出てきたらどうするのかについて、
　詳しくは、
　ここ　http://dev.mysql.com/doc/refman/4.1/ja/update.html
のUPDATE は左から右へ評価されますを参照してください。

---

■他テーブルの項目値をセットする
　ＭｙＳＱＬでは、４．０からできるそうなのですが、他のテーブルの値を参照してセットすることが出来ます。その場合は、テーブル名で書くテーブルは、変更するテーブルだけでなく、参照するテーブルも書きます。また、ＷＨＥＲＥ句の後に書く条件は、ＪＯＩＮ句で書く条件も書きます。

　たとえば、SHAIN_TBLのNYUSYANENは、OUBO_TBLのOUBONENに１年足したものとします。
　（SHAIN_TBLのSHAINIDとOUBO_TBLのSHAINIDが、JOINするキー）
　その場合は、こんなＳＱＬです。

UPDATE OUBO_TBL, SHAIN_TBL SET SHAIN_TBL.NYUSYANEN = OUBO_TBL.OUBONEN+1
WHERE OUBO_TBL.SHAINID=SHAIN_TBL.SHAINID;

---

ということで、ＵＰＤＡＴＥがおわりました。
ということでＳＱＬもおわりで、
ということは、ここで３層スキーマの話も終わりということにします。

ということで、次回は、ＤＢ操作をするのは、どういう仕組みで行うかという話になります。

「Amazonで90％以上OFFのお買い得品を速攻で見つける方法」だって

ここのGIGAZINEの記事
Amazonで90％以上OFFのお買い得品を速攻で見つける方法
http://gigazine.net/index.php?/news/comments/20070705_amazon_bargain/
にあります。要するに、ＵＲＬの引数、pct-offに=90-と指定すればいいそうな
50-70（５０％から７０％）のような範囲指定もできるみたい。

でも、そもそも、Amazonで買い物をしないので、別にウィリアムのいたずら的には、どーでもいいんですけどね（＾＾；）

１つのクラスの各メソッドで担当者がちがうとき

１つのクラス＝１ファイル中にいくつかのメソッドがあって、担当者が違うとき、
ＣＶＳなどで管理すると、つねに競合が起こり、上書きしていいかどうか、どのようにきりとっていいかわからない（担当者分のところを切り貼りすればいいかというと・・・たまに自分のプログラムを通すため、関係以外に所も直さなきゃいけなくて、そこも直している場合があるので）。

こーいうとき

１．各担当者ごとにクラスを継承して持つ
　例：userというクラスのadd,delがＡさん、updateがＢさんだったとすると、

　public class userA extends user
　のように、継承する

２．自分の担当のところは、メソッドを埋める。そうでないところは継承したものを使う
　　public class userA extends user
　｛
　　　　public int add()
　　　｛
　　　　　　プログラムを書く
　　　　｝

　　　　public int del()
　　　｛
　　　　　　プログラムを書く
　　　　｝
　　｝

３．てきとうなところでＵＰ

４．管理者が、よせあつめる。同じメソッドに対し、２人の人が書き込みがあったら、
　　どうするか、当事者で話す

５．担当者のひとを寄せ集めてうめて、みんなが継承しているもとのクラスを作る
　　userAからaddとdel、userBからupdateを切り出し、userにいれて公開する
　　なお、２人の人が書き込んでる場合、そこが解決しなければ、その部分はおいておいて、
　　他の部分を更新して、公開してもいい

こうすると、自分のところは最新（現在開発中のところ）で、それ以外のところは一世代前の、みんなに公開しているところ（安定しているところ）ということになる。

　

Xbox360、史上最大規模の不具合、修理費用総額1400億円！！。。。

ひえー（＠＿＠！）
ここの痛いニュース
Xbox360、史上最大規模の不具合　保証期間延長し無償修理へ…費用総額1400億円
http://blog.livedoor.jp/dqnplus/archives/1000199.html
によると（以下斜体は上記サイトより引用）

米マイクロソフトは５日、同社の家庭用ゲーム機「Ｘｂｏｘ（エックスボックス）３６０」の一部で本体が正常に作動しなくなるなどの欠陥が見つかったとして、保証期間を延長し、無償修理を実施すると発表した。

対象となる台数は不明だが、修理などにかかる費用は計１０億５０００万～１１億５０００万ドル（約１２９０～１４１０億円）を見込んでおり、家庭用ゲーム機史上で最大規模の不具合とみられる。



これ、マイクロソフトだから出来るんだよねー。
他の会社だったら、こんなに費用かかったら、つぶれちゃうよ。。
ある意味、マイクロソフト、すげー。。