グーグルケータイOS、androidのお勉強（８）－メソッドその２

　久々に、シリーズ「グーグルケータイOS、androidのお勉強」。
　今、画面をやっています。
　画面では、レイアウトのXMLと、Javaのクラスが必要でした。

　Javaのクラスでは、
　　onCreate()　　　　　　　：アプリ生成時
　　onCreateOptionsMenu()　　：メニューオプション作成
　　onOptionsItemSelected()　：メニュー項目が選択された

　を書き換えないといけなく、前回はonCreateをやったので、今回はonCreateOptionsMenuです。

---

■onCreateOptionsMenuの記述

　サンプル画面にはメニューがありました。そのメニューが作成されるとき、onCreateOptionsMenuが呼び出されるようです。

　で、このonCreateOptionsMenu、画面のクラス（ここでは、Notepadv1）に以下のように記述するようです。

 public boolean onCreateOptionsMenu(Menu menu) {
        boolean result = super.onCreateOptionsMenu(menu);
        menu.add(0, INSERT_ID, R.string.menu_insert);
        return result;
    }

（上記枠内は、http://code.google.com/android/intro/tutorial-ex1.htmlのStep９から引用）
Menuに関しては、Notepadv1.javaで

import android.view.Menu;
import android.view.Menu.Item;

を上のほうで宣言しています。

で、上位のonCreateOptionsMenuを呼び出し、menu.addでメニューを追加します。

このメニューのことば、R.string.menu_insertは、プロジェクトのフォルダーの下、res/value/strings.xmlに記述します。

---

■res/value/strings.xmlの記述

そこでは、こんなふうになっています。

＜resources＞
    ＜string name="app_name"＞Notepad v1＜/string＞
    ＜string name="no_notes"＞No Notes Yet＜/string＞
    ＜string name="menu_insert"＞Add Item＜/string＞
＜/resources＞

（上記＜　＞は、本当は半角。サンプルプログラムから引用）

そこの
＜string name="menu_insert"＞Add Item＜/string＞
が表示内容にあたります。

---

と、こんなことで今回はおわりにします。。

見える化同士でも、連携にはXMLのような・・（をUMLを例に説明する）

　前に書いた、意味論の世界の見える化→形式論の世界の自動化にXMLがいいという話を書きましたけど、意味論の世界の見える化ツールの連携にも、やっぱXMLだよね！というお話を、UMLを例に書いてみます。

---

　結局UMLは、プログラム開発に必要な業務の情報の見える化なわけです。

　そして、業務（の情報）には、動的なものと静的なものがあるわけです
　静的な情報、つまり保持しておくべきデータについて、その関係は、

　出力に必要なデータ
　　↓　
　正規化
　　↓
（UMLではないけど）ER図→DB、ファイル定義
　　↓
　クラス図のクラス（＝エンティティ）および属性

となり、

　動的に必要なデータ
　　↓
　アクティビティ図
　　↓
　ユースケース図→画面イベント→画面定義
　　↓
　クラス図のメソッドとして、クラスに割り振る

ということになります。

---

ってことで、ER図のエンティティと属性は、クラス図に使える部分が多いわけです。
（っていうか、そこをベースに考える）

また、アクティビティ図のアクティビティのコンピューター化する部分が、
ユースケース図のユースケースとなり、
ユースケースから引かれるアクターは、たいていアクティビティ図の
　　・アクティビティが所属するスイムレーンか
　　・アクティビティから引かれる線の元や先があるスイムレーン
が多いわけです（必ずしもそうじゃないけど）

なので、アクティビティ図がユースケースに使えると、役立つわけです。

また、アクティビティないし、ユースケースをクラスのメソッドにしたい
ことも多いので、この点でも、流用できると役立つわけです。

---

　以上により、アクティビティ図、ユースケース図、クラス図のそれぞれが、
XML化してくると、それぞれが流用できて、(自動化のようにすべて使う
わけではないけど）、支援して、利用できるようになるので（利用も簡単に
なるので、出来る人が増える）、メリット大だとおもうわけです。

見える化→XML→形式化の自動化（ER図→XML→テーブル定義を例に）

　昨日の見える化から形式化における自動化の話のつづき。

　たとえば、要求仕様の出力内容から、データベースを作成する場合、

（１）出力内容から、正規化により、テーブル(エンティティ）と項目を抽出する
（２）(エンティティ）と項目をER図で見える化する

ここで、最終的に

・ER図の見える化した内容からテーブル定義(CREATE TABLE）を作成する

としたいわけです（もちろん、型とかNot NULL情報はないので、それは補うとします）
でも、ER図から、テーブル定義には落ちません。そこで、どうするか・・

---

ここは、XMLを使うのが素直だと思うんです。

（１）出力内容から、正規化により、テーブル(エンティティ）と項目を抽出する
（２）(エンティティ）と項目をER図で見える化する
（３）ER図を、XMLで書き出す
（４）そのXMLを読み込み、（XSLTやプログラムにより）
　　　テーブル定義(CREATE TABLE）を作成(変換）する

っていう風になると思うんです。ER図→XMLは、フリーソフトとして
DBDesigner（日本語サイトはここ、
ウィリアムのいたずらは使ったことないので、どんなXMLがかかれるか、
日本語が使えるかとかは、わかんない）とかあるらしい・・・
ってことで、出来ない話ではないわけです。

（っていうか、テーブルとリンクにわけて、テーブル定義は、テーブル名
　とかを指定するタグと、項目のタグ、あとリンクのほうは接続するテーブル
　とカーディナリティを定義すれば、XML化すぐにできますね　＾＾；）

で、XML化してしまえば、あとは、そこからCreate　Tableをつくるなり、なんなりって
いうのは、XMLを読み込んでテキスト書き出しするプログラムでしかない。。

---

　っていうことで、見える化したものを、いろんな形式化(形式言語：
今回はCreate Tableでしたけど、Javaによる入出力とか、いろいろな派生が
ありえます）して自動化するためには、交換フォーマットとしてXMLで
落とし込むっていうのが、一番現実的かな・・と思ったりもします。

INPUTタグでClassを利用することによって、エラーチェックが見える化／自動化できるかも？

　まえに、ここでJavaとJavaScriptにおける、「型の代わりのクラス」を使うことによって、テストが階層化できたり、自動化できるという話を書きましたよね。

　で、そうなってくると、HTMLのフォームにおいて、INPUTタグのところ、

＜INPUT　TYPE=TEXT　ID=su1 CLASS=suryo＞

のように、CLASS指定をして、そこで、「型の代わりのクラス」を書いておけば、
ボタンがクリックされたとき、そのフォームのINPUT文に対し、クラスで指定されたチェック（上記例だと、数量のチェック、suryo_validation）を行うようにするという感じでいいことになる。

　で、その数量は、整数に属しているのであれば、その数量のチェックの中で、整数のチェックを呼び出せばよい（階層化）。

---

　こうなってくると、チェック部分は、なにもHTMLの中にある必要はなく、HTMLの中では、チェック用のJavascriptを呼び出し、そのチェック用Javascriptの中で、それぞれのClassで指定された「型の代わりのクラス」のチェックを記述すればよい。
　そうなってくると、この「型の代わりのクラス」のチェックは再利用できるし、あるボタンがおされたとき、どの変数をつかい、その変数の型はなんだから、どんなチェックがされるはずかというのが、表形式みたいな感じ

ボタン：受注

項目　　　　クラス
受注年月日　hizuke
顧客名　　　kokyaku
受注商品１　shohin
受注数量１　int
受注単価１　TANKA
受注商品２　shohin
受注数量２　int
受注単価２　TANKA
：
：

なかんじで、見える化できる。
さらに、クラスのところ、たとえば、hizukeをクリックすると、

型：hizuke

要素チェック　全体　要素数 3　区切り/
文法チェック　年月日（要素）
範囲チェック　全体（要素）　2008/1/1
：
：

のように、チェック内容も見える化できるようにして、
実際のチェックのときには、プログラムをあえて書かなくても、
上記のチェックが自動的に動くようにすれば、
チェックの手間が省けると思う。

---

やっぱ、具体的な例を示しながらでないと、
わかりにくいですよね、。今度やっときます。

形式論→意味論 X 見える化→自動化→エージェント。。。

　システム開発は、昔はプログラミング言語論などで、
どのような言語が効率的かとか、言語によるTipsの話が
多かったと思います。

　で、いまもそれはそうなのですが、自動化されてしまうと、
そのような形式論（形式言語）部分の話は、自動化対象と
なってしまい、むしろ、自分の業務を、どのプログラムに
マッピングしていくかという、意味論的な部分が中心に
なってくると思います。

---

さっきの、

見える化→自動化→エージェント

と話をあわせると、

●むかし

（１）プログラム言語の見える化
　→フローチャートやVISIOでいろんな図を書いたり
　　標準化された設計資料を使って書くなど・・

●いま

（２）プログラム言語の自動化
　brancoなどによる、プログラムの自動生成など、
　自動生成は、いま結構やられてますよね。
　ま、このブログもその辺の話が多いわけです。

（３）業務の見える化
　業務を見える化して、それを、プログラムに
置き換えていこうという流れ。
　UMLのアクティビティ図など

●ってことは今後は・・

　エージェント化は、ネットワークなどではやられているけど、
プログラムレベルでのエージェントとかは考えられる・・

　けど、（２）と（３）をつなげて、業務の自動化＋見える化
みたいな部分が先でしょうね・・

見える化→自動化→エージェント

　世間一般で、ここ数年、「見える化」がはやっているわけですけど、
　これは、見えないものを、見えるようにするということなわけです。

　グラフとか、経営資料であれば、「見える化」すれば十分かもしれない
けど、作業が伴うものについては、さらに、「自動化」してくれたほうが
うれしいわけです。

　たとえば、経営資料をかっちょいいFlashでグラフ化するのも、
それはコンピューター屋さんにとってはいいかもしれないけど、
どっちかというと、あぶない指標を自動的にチェックして、
そのグラフについて、先に出してくれたほうが、うれしいわけです。

　さらに、この自動化、決まったやり方であれば、１通りの方法を
自動化するだけでいいですが、環境に応じてやり方が変わるような
場合は、自律的にプログラムが動くエージェントのほうがいいわけです。

---

　まとめると、流れとして、

　　　　見える化→自動化→エージェント

であり、決まったやり方があるのであれば、自動化可能、

さらに、決まったやり方が状況に応じて変化するなら、
エージェント化ってことだと思います。

---

　ただし、じゃあ、決まったやり方があるから全部自動化すべきかどうか
という話にはならないのですが・・

　ただ、決まりがない、自動化できないものに対して、なにもしないって
いうんじゃなくって、それを、「見える化」できないかと考えたり、
決まりがあるモノに対して、「見える化」からさらに進んで、
「自動化」、「エージェント化」できないかと考えるのは、意味あること
だと思うんですよ。


ま、そもそも、この流れとかには、反論ある人も多いと思いますけど・・

NTTドコモ、OSにGoogleの「Android」を採用へ

ここのGIGAZINEの記事
NTTドコモが携帯電話の基本設計を抜本的に変更、OSにGoogleの「Android」を採用へ
http://gigazine.net/index.php?/news/comments/20080324_docomo_android/
によると(以下斜体は上記サイトより引用）


NTTドコモが携帯電話端末の基本設計を抜本的に変更し、基本ソフトとしてGoogleが開発したLinuxベースの携帯電話向けOS「Andoroid」を採用するそうです。


そーいえば、「Android」のシリーズ、途中でしたね。
今度再開しますね・・・

オブジェクト指向と、RDBとセマンティックWebの関係をまとめてみる

　前に、JavaのクラスとOWLについて書いたので、ここで、

　・オブジェクト指向における、クラスとオブジェクトと、
　・RDBにおけるテーブルとレコード、ER図におけるエンティティと
　・セマンティックWebにおけるRDFとOWL

の関係について、まとめてみたいと思います。

---

■クラス－テーブル－エンティティ－OWL

　オブジェクト指向で定義するクラスと、
　ER図のエンティティが対応し、
　これと、セマンティックWebのOWLのクラスが
　だいたい対応する。
　RDFスキーマのクラスも、そうともいえる。

　そして、ER図のエンティティと、RDBのテーブルが、
　だいたい対応する。

　ただし、クラスの場合、メソッドがあるけど、ER図などにはないとか、

　ER図のエンティティにおいては、というかRDBではサブクラスという
　概念はなく、そのかわり、（consist ofと同じように）
　外部キー（参照キー）との関係で示し、
　１対多のとき、１のほうが親になるとか、

　RDBのテーブルには、エンティティ以外に、関係だけを表した、
　連結テーブルというのがあるとか

いった、違いはある。だから、「だいたい」

---

■そうだとすると、

　そうだとすると、それぞれを具現化した、

オブジェクト指向のオブジェクトは、
RDBのレコードに相当する。

このレコードを、RDFの主語としたとき、

オブジェクト指向の属性は、
RDBの項目（フィールド名）に相当し、
RDFの述語に相当する。

そして

オブジェクト指向の属性値は、
RDBの項目の値に相当し、
RDFの目的語に相当する。

っていったら、厳密に考えている人には怒られそうだけど、
だいたい、そんなかんじ。。

JavaとJavaScriptとOWLにおける、「型のかわりのクラス」によるチェックの話

　昨日、、「型のかわりのクラス」を使って、値のチェックの自動化とか、階層化の話を、Javaをベースにして書きました。結局まとめると、

・型をクラスで表現する。継承を利用して、階層化することもある

・値のチェックのメソッドをどのクラスでもint validate(String val)とし、
　階層化されている場合、super.validation(val);を呼び出し、親でのチェックもする

・範囲など、チェックに必要なものは、「型のかわりのクラス」の属性として
　定義し、チェック前までに設定する。設定値がなけれ（デフォルトなら）チェックしない。

こうすると、チェックが自動化、階層化できるため、追加チェックの手間が省けたり、テスト漏れが防止できそうという話を書いた。

---

　でも、サーバーならそれでいいが、クライアントの場合は？
　JavaScriptだと、クラスの概念がない。

　しょうがないので、

・クラス名_validation(val)を関数名とし、そこでチェックし、
・クラス名_属性名で、範囲など、チェックに必要な項目とし、
・継承する場合、クラス名_validation関数の中で、親のクラス名_validation関数
　を呼び出す

という形になるのかしら・・・

---

　で、ここで、ついでに言うと、OWLの場合、はなしはかんたんなんだよね。

　OWLのクラスがこの「型のかわりのクラス」に相当し、
　親は subClassOfで設定すればいい。
　範囲などは、プロパティ制約で記述することになる。

　ってことで、Javaの「型のかわりのクラス」は、OWLの定義そのものと言える。
　ってことは、業務用語をセマンティク的に（OWLで）定義すると、そこからJavaの「型のかわりのクラス」を定義でき、自動的にチェックモジュールを生成できる可能性がある。ってことだね。

電子政府でいっぱいお金使ったはずなのに、年金記録問題がおきるのは。。。

　e-Japan構想ということで、政府は電子化（電子政府）したはずですよね。
　それも、たくさんのお金＝税金を使って。。

　電子化すると、検索とか早くなって、いろんなデータを有機的に使えて（たとえば、税金のデータと年金のデータがむすびつき、税金のデータから、旧姓がわかったり、昔の勤務先がわかって、それを年金データに使うなどということが電子的にできて）、年金の記録漏れ問題とかに有効なはずですよね。。。

　でも。。。e-Japanのおかげで、不明な部分の照合が楽になったとは聞かない気が。。

---

　今日、メタデータ技術とセマンティックウェブっていう本を読んだけど、そこの「第９章　電子政府」（P151～P164）に、その答えらしきことが。。。

　アメリカ、イギリス、オーストラリアでは、検索を重視して、メタデータを利用した電子政府化を行っている。それに対して、日本では、申請部分のシステム開発は重視されているけど、各省庁を超えた検索を行うためのメタデータとか、そーいうのは？？？（検討されていないような気が）・・

　この場合、いくら申請部分が電子化されても、年金問題のような、データマイニングっぽい検索とか、そーいうのには活用できない・・とまでは言い切れないが、あまり役立たないかもしれない。それに、今、紙のデータを電子化する・・っていうことをしないと、年金問題には、役立たないし。。

---

　っていうことで、e-Japanであんまりお金を使っても、メタデータとか、検索によるデータの利活用部分をよくしているわけではないので、年金問題とかには役立たない・・

　ってことなんすかね。。なんか、お金＝税金がもったいない気が・・

値のチェックの自動化と階層化を、Javaで説明してみる

　昨日の、値チェックの自動化の話。

　要するに、Javaでいうと、こんな感じになる。

・すべてのクラスにvalidateというメソッドをもち、
　そこでチェックを行う。

・int,doubleといった型も、Myint,Mydouble
　とかつくり、それらが、型に結びついたクラス
　Integer,Doubleから継承され、validateという
　メソッドをもつものとする。

・上記２つを、「型のかわりのクラス」と
　呼ぶことにする

・画面項目値は、上記の「型のかわりのクラス」の
　どれかの型をもつこととする
　受注金額は、Tuka（通貨）クラスとか・・

・この「型のかわりのクラス」に親子関係がある場合
　（通貨は整数）、継承して、そのテストを呼び出す

class Tuka extends Myint {
　int validate(String val) // チェック前なので文字で受け取る
　{
　　　//　　：　　　ほかにチェックしたいことがあれば
　　super.validation(val);
　　　//　　：　　　ほかにチェックしたいことがあれば
　}
}

　なかんじ

・範囲など、チェックに必要な値は、「型のかわりのクラス」
　の属性に持っていて、チェック前までには、値が入っている
　ようにする。

　画面のクラスで、
　class Gamen1{
　　Tuka zyutyuKingaku;

　とかあったら、コンストラクタのGamen1のなかで、
　　zyutyuKingaku.maxval=100000;
　　zyutyuKingaku.minval=0;
とか、セットしておく

・値が入っていない＝デフォルト値のものは、今回のチェック対象
　ではないとする。

---

　こうすると、すべての値に対して、画面からとりこむときに、

　項目値.validate(画面入力値＝文字列で）;
　（例：zyutyuKingaku.validate(para1);）

　とすれば、必ずチェックできるし、チェックすべき項目は、
　「型のかわりのクラス」に属性として書かれているので、
　チェックしわすれのミスが防げる
　（この辺は、たぶんツールか何かを使って、属性値を定義
　　すれば、もっとミスが防げる）

　そして、チェック項目を追加する場合、この「型のかわりのクラス」
　のvalidateに追加すれば、いっぺんに追加できる。

---

　そーいう意味では、いま、

　　Tuka zyutyuKingaku;

　というかたちで、書いていたけど、各項目を各クラスにしてしまい、

　ZytyuKingaku zyutyuKingaku;

　この項目特有のチェックを、このクラスに書いたほうがいいのかもしれない

class ZytyuKingaku extends Tuka {
　int validate(String val) // チェック前なので文字で受け取る
　{
　　　//　　：　　　受注金額でチェックしたいことがあれば
　　super.validation(val);
　　　//　　：　　　受注金額でチェックしたいことがあれば
　}
}

---

今回は、Javaで書いたけど、JavaScriptとか、OWLの話をこんど・・

SugarCRMのケアブレインズが社名変更・・って、どーして、ケアブレインズのHPに載ってない？

ここの「ウルシステムズ」のホームページにある、

[2008.3.19]
子会社の商号変更に関するお知らせ（PDF）
http://ir.eol.co.jp/EIR/3798?task=download&download_category=tanshin&id=538006&a=b.pdf
(PDFは、eol（プロネクサス＝旧亜細亜証券印刷のグループ企業）が配信しているので、URLがちがう）
によると（以下斜体は、上記PDFより引用）


当社連結子会社の株式会社ケアブレインズは、本日開催の取締役会及び定時株主総会において
下記のとおり商号を変更することを決議いたしましたので、お知らせします。


ほうほう・・・


旧商号：株式会社ケアブレインズ（英文名：CareBrains,Inc.）
新商号：オープンソースCRM株式会社（英文名：OpensourceCRM, Inc.）


ほー・・・

---

でもね、
ケアブレインズのプレスリリースのページ
http://www.carebrains.co.jp/press/index.html
に行っても、書いてないんですけど（－＿－；）
（３月２３日、午前３時現在）

なーぜー（＾＾；）

ネット上に金融機関の検査資料―「破綻懸念先」として小売業や建設業など三つの企業名

ここのニュース
＜情報流出＞ネット上に金融機関の検査資料が　日銀松江支店
http://headlines.yahoo.co.jp/hl?a=20080322-00000026-mai-soci
によると（以下斜体、および表題は上記サイトより引用）


　日本銀行松江支店（松江市、吉岡伸泰支店長）が金融機関を検査した際の内部資料の一部が、インターネット上に流出していることが２２日わかった。業務課の男性職員の私有パソコンが、ファイル交換ソフト「Ｗｉｎｎｙ（ウィニー）」の暴露ウイルスに感染したのが原因で、資料には取引先の会社名や「破綻（はたん）懸念先」の記述などが含まれていた。


で、


２ちゃんねる上には、「破綻懸念先」として小売業や建設業など三つの企業名などが記されていた


って、これ、もし上場企業とかだったら、まずいよねえ・・
まあ、上場してなくても、まずいけど・・


インターネット上の情報と内部情報が異なっているものもみられ


もし、間違った情報で、風評被害とか出たら、
だれのせいになるの？？・・・

正しくコピペできる技術と、コピペ元を探す技術が重要ってことだと思う

　最近のプログラムは、コピペ（コピー＆ペースト、どっかからパチってきて、修正して貼り込む）が中心になっているとおもう。
　そして、バグの多くは、正しくコピペしていない（コピペの修正ミスや、コピペ時に想定していないことがおきてしまって、結果として、そのコピペはふさわしくない）っていうことが多いと思う。

　つーことは、暴論を言えば、現場を救うには
（１）コピペしなくて済む技術
（２）正しくコピペできる技術
（３）コピペ元を探す技術
が重要っていうことになると思う。

自動生成は、（１）または（２）が中心の技術であり、
テストは、（２）の検証になる。
フレームワークやひな形、（１）、（２）が中心？？
デザインパターンは、（３）のようでもあり・・・？

これらを意識して、充実させることが、生産性を上げていくことにつながると思う。

オントロジーとタクソノミの立場から、値チェックの自動化―思いつきで。。。

ふと、おもいついたことを、メモとして書いているので、
間違いとか、勘違いとかあるかとは思うんだけど、
そのときはごめんなさい。

　プログラムにおける、データのチェックをする際、
おなじようなチェックをすることはよくある話なわけです。

　たとえば、受注金額が、数か所で出てきたら、たいてい、
　同じチェックをしているはずです。
（つまり、受注金額の妥当性チェック）

　これはなぜかというと、同じ属性をもったものは、
同じ（種類の）値を示すので、おなじチェックを
するわけです。
　受注金額なら、範囲と数字チェックとか。
　そして、この場合、階層構造になっていて、
　受注金額は数字なので、ほかの数値同様、数値チェックを
するわけです。

　ってことは、その項目の用語集をつくり、その関係を、
オントロジー的に表現できれば、チェック部分の自動化もできるし、
チェック方法を追加したい場合も、いっぺんに追加できるんじゃないか
（自動化できるなら）
とおもう。

---

　で、この話はたぶん、XBRLのタクソノミにつながっていく話だと思う。
XBRLのオントロジー的表現？？ともいえるタクソノミをつかって、XBRL
はさまざまなチェックをできると、日銀の人が、XML Today & Tomorrowで言ってた気がする。

　であれば、同様な方法で、業務においても、用語を定義し、
値チェックの自動生成に生かすことはできないのだろうか・・？？