画面のテストから考えると、画面のボタンは？

まえの
画面定義書が２つのパートにわかれるとすると、画面のテストは・・・
http://blog.goo.ne.jp/xmldtp/e/ecef5a27c6cd9b9dd10f9d6832272aef

に書いたけど、画面は、画面入出力項目と、画面のボタンなどのイベントにわけられる。

で、前回の話の続きなんだけど、画面項目が１つ増えるのと、イベントが１つ増えるのでは、テストにおいては、話が違うっていうことだ。

---

具体的な例で示そう。

いま、取引先一覧（チェック項目つき）の下に、住所、電話番号、取引先名、〆日などがあり、〆日に関しては、取引先一覧を複数項目チェックし、〆日を翌月３０日払いにして、「編集」ボタンをクリックすると、すべての取引先が翌月３０日払いに更新されるものとする。

　この画面に、「担当者」項目を追加したとする。その場合、「担当者」に関するチェックをすればよい。

　その一方、ここに削除ボタンを追加する。そうすると、削除に関する項目である、取引先一覧にチェックが入っている／いないときの処理のテストのほかに、住所、電話番号、取引先名、〆日に値が入っている時でも、入ってる内容がエラーでも、入っていなくても無視されて削除されるかどうかなどをチェックしないといけない。

---

　つまり、ボタンが増えれば増えるほど、入出力項目に絡むテストが増える。
　一方、入出力項目は独立であれば、その項目Xイベント数のテストですむ（ここでもイベントが影響）

　ということで、ボタン満載の画面を作ってしまうと、テストが大変になる
　（使いやすいかどうかは・・・微妙）

　って考えると、画面割には、適切な画面割方針（テストでも困らない＆操作的にも妥協できる）があるっていうことだと思う。

（このはなし、つづく！）

UML等各種ダイアグラムのエラーチェック体系化（その１４：ダイアグラムをＲＤＢに）

シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、
　前回までで、ダイアグラムの構成要素を、ノード、リレーション（エッジとか、アークというのが普通）、属性、属性値に分けようとしています。
　なお、ここで書いたとおり、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
（ちと、更新サボってて古い）

　今回は、ＲＤＢに入れる場合の原則について書きます。

---

■ＲＤＢにいれる原則のまえに・・・

ＲＤＢに入れる原則の前に、ちょっと、構成要素のまとめ

ノードは、複数の属性を持っていて、１つの属性は、（多くは１つだけど、場合によっては複数の）属性値をもつ。

リレーション（エッジ、アークというのが普通）は、
２つのノードを結びつけ、
その結びつけに対して、複数の属性を持っていて、１つの属性は、（多くは１つだけど、場合によっては複数の）属性値をもつ。
（３つ以上結びつく場合は、２つの結びつけにわける＝ＡＢＣが結びつく場合ＡＢとＢＣにわける）

---

■原則

●ノードの種類ごとに１テーブルとする。
　ノードがもつ属性をテーブル項目とし、属性値を、テーブル項目の値とする
　ただし、属性値が複数ある属性に対しては、第一正規形をおこない、その属性で１テーブルとする。
　ノードには、ＩＤをふる。

●リレーション（エッジ、アークというのが普通）も１テーブルとし、
　テーブル中の項目に、始点のノードＩＤ，終点のノードＩＤをもつ
　　　有向グラフの場合。どちらが始点でも終点でもかまわない無向グラフの場合は、ＩＤの値が小さいほうを始点とする。
　このほか、リレーションがもつ属性をテーブル項目とし、属性値を、テーブル項目の値とする
　ただし、属性値が複数ある属性に対しては、第一正規形をおこない、その属性で１テーブルとする。
　リレーションには、ＩＤをふる。

---

■結果として・・・

ダイアグラムの凡例に描かれる要素は、１テーブルになり、
その要素の周りに書かれる説明などが、テーブルの構成要素になる。
そのほかに、２つ以上の関係を示すリレーションがある場合には、
　　テーブル中に、結びついている要素のＩＤがはいる。

---

次回は、例外とかについて

「VC++のATLの脆弱性により、リモートでコードが実行される」件について

ここ（http://home.att.ne.jp/sigma/satoh/diary.html）の2009年7月29日の話。

どうも、ＶＣ＋＋で使うＡＴＬに問題があるらしい。
マイクロソフト セキュリティ情報 MS09-035 - 警告
Visual Studio の Active Template Library の脆弱性により、リモートでコードが実行される (969706)
http://www.microsoft.com/japan/technet/security/bulletin/ms09-035.mspx
によると、（以下斜体は上記サイトより引用）

ATL を使用してコンポーネントおよびコントロールを作成、配布する開発者はこのセキュリティ情報で提供している更新プログラムをインストールし、このセキュリティ情報で説明している脆弱性の影響を受けないコンポーネントおよびコントロールを作成するためのガイダンスに従い、お客様に配布する必要があります。


じゃあ、いままでの、脆弱性の影響を受けるコンポーネントおよびコントロールを作成しちゃった開発者は・・・？？
影響を受けない形で再配布なの？？

それとも、共有DLLにしていれば、ＯＫなの？
とはいえ、環境の影響を受けなくさせるため、共有ＤＬＬにしないで、スタティックにするか・・
ってか、そんなことは、関係なく、やばいの？ヘッダーだと、関係ナシにやばそうね・・・


で、とにかく、ここ
http://msdn.microsoft.com/ja-jp/ee309358(en-us).aspx
にやばいか、やばくないかの判断基準がある（まんなかのＹＥＳ－ＮＯの図）。

でも、そもそも、VC++で、ＡＴＬ使って書いてないなあ（＾＾；）

画面定義書が２つのパートにわかれるとすると、画面のテストは・・・

この２つのパートが独立に動くことになるので、最低、２次元はある。

---

まず、画面が２つのパートに分かれることは、ここに書いた。

入出力項目、データ関連

　　　と

ボタンなどのイベント、処理関連

の２種類

で、これ、イベントによって、入出力項目の意味合いがちがってくる。

たとえば、

「追加」ボタンをクリックした場合、
　　　住所、氏名は入力必須、入って無かったら、エラー
「編集」ボタンをクリックした場合
　　　住所、氏名は入力任意、入って無かったら、そこは変更なしとみなす

というふうに、ボタン（イベント）によって、項目の意味は違う。

---

そこで、横軸にイベント（●●ボタンおされた等）、縦軸に項目を書き、そのイベントのとき、その項目がチェック対象なら、チェックという一覧表ができる。

　しかし、この場合でも、その項目１項目に対するチェック（字種チェック、範囲チェックなど）と、複数項目が関連したチェック（年齢が１８歳以下なら、趣味：酒はチェックできないなど）、存在チェックなど、その画面レコードだけでは判断できず、既存データとの確認が必要なものとある。


ってことは、テストの次元として、

どのイベントのときに　X　どの項目に対し　X　何をチェックするか？

ということになる。

・イベントとしては
　　画面表示時（表示されているか、いないか、入力可能か、否か）
　　ボタンを押したとき
　　（場合によっては）どこかの値が変わったり、カーソル移動したとき

・何をチェックするか？は
　　１項目チェック＝入力項目の型で字種チェック（フォーマットチェック）
　　　　　　　　　　範囲チェック
　　複数項目チェック＝項目間の関係チェック
　　複数レコード・データチェック＝現在画面レコードと既存レコードとの
　　　　　　　　　　　　　　　　　存在チェックなど

がありえる。

これらが、画面定義から読み取れないと、チェック項目は作りにくい

ただ負荷分散や冗長性ならＩＰＶ６エニキャストでいいわけで・・・

　さっきのＣＤＮの話。
　ＣＤＮをもし、クラウドとしてしまうと、ちょっと違和感。

　というのも、極論すればＣＤＮって、負荷分散や冗長性の話であって、
　それなら、ＩＰＶ６のエニキャストでも、いいわけじゃないですか？


ＩＰＶ６のエニキャストって、クラウド？？
いやー、そりゃ、誰から返ってくるかわかんないって言う意味では、雲の中だけどさあ（＾＾；）


Ｐ．Ｓ　じゃ、ＩＰＶ６じゃないと・・・
っていう話でもなさそう。

ＩＰＶ４でも、

IPv6アドレスの構造 その7 エニーキャストアドレス
http://www.n-study.com/network/2005/08/ipv6_7.html
によると、PIM-SMのRP(Rendezvous Point)の負荷分散と冗長化で、そんなことをしているらしい。

CDNもクラウドに入るのかしら？だとすると、クラウドの実用化はCDNが一歩リード？

コンテンツを分散させて、負荷を減らすCDN（＝オバマ大統領の演説が、すっごいアクセスがあっても世界中で聞けたわけ）だけど、アカマイが有名じゃないですか。

でも、amazonでも、「Amazon CloudFront」っていうサービスがある。

で、ここで思うんだけど、amazonのCDNは、CloudFrontって、クラウドっていう言葉が入ってるよね。そーすると、CDNって、クラウドなの？

だとすると、クラウドの実用化はCDNが一歩リード？
だって、CDNでググると、いろいろでてくるよね。。。

マイクロソフトが減益なのは、Accessの開発ツール化などを行わず、サボってたからだよね！

ここのニュース
米マイクロソフト減収、通期で初…ＯＳ販売不振で
http://headlines.yahoo.co.jp/hl?a=20090724-00000539-yom-bus_all

ま、そりゃーＯＳとオフィスソフトしかやってないで、事業を拡張しなければ、
そのうち、減収減益にはなるわな。
どんなビッグな会社でも、みんなが買ったら、そこでおしまいだからね。

---

マイクロソフトは、Ａｃｃｅｓｓを使った開発ツールビジネスに出るという手があったと思う。

Ａｃｃｅｓｓのフォームで、業務流れ図が書ければ
（つまり、Ａｃｃｅｓｓのフォームに線が引けて、
　プロセスだけでなく、帳票やディスプレイの形をしたボタンをつくり、
　フォーム上に業務流れ図がかけるようにする）

その業務流れ図で、
　　帳票のところは、Ａｃｃｅｓｓのレポート定義と結びつくようにして
　　ファイル、ＤＢのところは、テーブル定義と結びつくようにして
　　プロセスのところは、より詳細な業務流れ図と結びつけるか、
　　　　　または、処理を記述するマクロと結び付けられるようにすれば

Ａｃｃｅｓｓで業務流れ図かがけ、そこから、Ａｃｃｅｓｓベースでプログラムが書けるから、
これをＤＢ部分は、ＳＱＬServerなり、Ｏｒａｃｌｅなりに変換し
プログラム部分は、Ｊａｖａなりに変換できるようにすれば、

Ａｃｃｅｓｓがプログラム自動生成ツールになる
（って、意味通じてるかな、こんど、例を出してかくね　＾＾；）

---

そーすれば、こんどは、その業務流れ図のプロセスに、というよりかは、
プロセスが読み出す「マクロ」のアクションに、クラウドのＷｅｂサービスを
呼び出せるようにしておけば、マイクロソフトは、クラウドでの開発や、
ＳＯＡ開発に一歩先んじることができた。

でも、そのような手を打たないで、ＯＳ販売だけで怠けていたから、
こんな体たらくになったんだよね。

とまあ、こんなことをいくらいっても、マイクロソフトがなんかやりだすことは、ないだろう。
ウィリアムのいたずら様は、マイクロソフト受けたら、「書類審査だけで」落とされたからなあ（＾＾；）・・・
ウィリアムのいたずらのような、おばかなことを考える人には、きっと興味のない会社にちがいない・・・

セマンティックＷｅｂって、ブログのタグに付随情報を入れるようにすれば出来る気がする

　セマンティックＷｅｂを実現しようとすると、RDFのトリプルつまり、主語、述語、目的語をいれなきゃなんない。これを入れるのがめんどっちいし、自動抽出も結構難しい。
　・・・なので、すすまない。

---

　でもねでもね、
・ブログを作成するとき、タグやカテゴリーをつけると思うんだけど・・・
・そのタグ、カテゴリーに関する項目一覧（ダイアログ）を出して、
・値をいれてもらう。

そーしたら、ブログサーバー側は、
　そのブログＵＲＬ＝主語
　項目一覧のＵＲＩ表記＝述語
　入力された値＝目的語
としてＲＤＦのトリプルを作って保存する。

タグに関してはタグごとにＵＲＩもっておいて
　タグのＵＲＬ＝主語
　ブログを意味するＵＲＩ表記＝述語
　そのブログＵＲＬ＝目的語
としてＲＤＦのトリプルを作って保存する。
（データの持ち方は、こうでないほうがいいかも・・・ちょっと考えたほうがいい気がするけど）


そーすると、検索エンジンは（Ｇｏｏとか）その形式で入れてくれたものは、
セマンティックＷｅｂ検索で、検索してくれる

とかすると、ブログでヒット率をあげたい人は、利用してくれるし、
セマンティックＷｅｂも実用化しやすいんでないだろうか？

---

例　カテゴリー「歯医者」とか選ぶと

「診療曜日・時間」
「場所」
　：
　：
などがダイアログ表示され、それを入力する。

そうすると、

歯医者－ブログ（のＵＲＩ）－ブログＡ
ブログＡ－診療曜日・時間のＵＲＩ－ダイアログ入力値
ブログＡ－場所ＵＲＩ－ダイアログ入力値

として保存され、検索時は、
１．タグを入れると、
２．「診療曜日・時間」、「場所」などの検索用語がでて、
３．それを設定すると、セマンティックＷｅｂから検索して結果を出す

っていうかんじ・・・

---

できそうなのに、どこのブログも、検索サイトもやってないのは、
さぼってるから（＾＾；）
それとも、どこかに問題ある？

UML等各種ダイアグラムのエラーチェック体系化（その１３：ダイアグラムをグラフ理論化－４）

　ひさびさに、シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、そのため、まずは、ダイアグラムの構成要素を、ノード、リレーション（エッジ）、属性、属性値に分けようとしています。
　前回までで、その構成要素の分類は終わったので、ここでそのまとめをしたいと思います。
　なお、ここで書いたとおり、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm

---

■構成要素のまとめ

　RDBにいれるため、ダイアグラムを

　　・ノード
　　・リレーション（エッジ）
　　・属性
　　・属性値

の４つにわけます。

　まず、単独に存在しても意味をもつものを、ノードとしました。
　のこりは、単独に存在できないものですが、このとき
　　２つ以上のノードを結びつけて、存在しているものをリレーション（エッジ）
　　１つしか結びついていないものを、属性値

　としました。

　ただし、属性値は、ノードに対してだけでなく、リレーションに結びついている（関連している）ものもあります。
　また、結びついているというのは、物理的に線でつながっている場合もありますが、単に上に乗っている（書いてある）というものでも、関連していれば、結びついていると考えます。
　別の紙に書いてある場合でも、関連していれば、結びついていると考えます。

　そして、属性値を意味的にまとめて、属性とします。

　なお、分類上、

　単独に存在できないもので、１つのノードとも結びついていないもの

　というのがありえます。
　枠の線などがこれにあたります。何も関連していないので、まあ、これはRDBにいれなくていいでしょう（＾＾；）

---

■このあとは

　これで、構成要素がきまったので、その構成要素をRDBにいれます。

　そして、ダイアグラム間の関係を示していきます。
　あるダイアグラムの構成要素から、他のダイアグラムの構成要素を
　　　・select文を使って取り出せる（元の構成要素のほうが情報大）
　　　・select文を使って結び付けられる（関連性がある）
　　　・まったく結び付けられない（関連ない）

　にわけます。

　さらに、プログラムを記述するうえで必要な情報というのがあります。

　これと、上記ダイアグラムを関連付けていき、
　　　・どのダイアグラムは、プログラム記述に必要な情報を持っていて
　　　・どのダイアグラムは、プログラム記述に必要な情報を持っていないか

　をチェックしていきます。

　結果として、
　　　・UMLやDFDは業務流れ図の部分的な情報しか持っていない。
　　　・業務流れ図とその関連性がある図から、プログラムは記述できる
　ってことは
　　　・UMLやDFDは業務流れ図から、プログラムを記述するには、
　　　　必要な情報が欠けている。
　ということを示していきます。

---

　ということで、こんかいはおしまい。

　次回は、RDBにいれる方法について

インターネットを使ったアマチュア無線、D-STARのお話を聞いてきた！（その２：参考サイト）

　インターネットを使ったアマチュア無線、D-STARのお話を、２５日、icomの東京営業所できいてきたので、報告！のつづき
　

---

■ここまでのまとめ
　デジタル通信を利用したアマチュア無線D-STAR、レピータがインターネットにつながっているので、４３０MHｚで東京から沖縄などという、電波だけでは通常届かないところでも通信できる。もちろん、レピータ－内での通信、シンプレックス通信も可能

　で、

自局＝（電波）＝＞レピータ＝＞ゲートウエイ
　　　＝（インターネット）＝＞相手レピータ＝（電波）＝＞相手局

アシスト局を使わないとR1とR2は（設定上、Gがつくけど）同じ局。
という流れになるので、設定は自局（MY)、自局レピータ（R1)、ゲートウエイ(R2)、相手局または相手局レピータ（UR)の４つ。例を示すと

・シンプレックス通信
UR:CQCQCQ
R1:JP1YIU
R2:（設定なし）
MY:JQ1YOL

・相手がレピータ
UR:/JP8YDZB
R1:JP1YIU
R2:JP1YIU G
MY:JQ1YOL

相手指定の場合は、URに相手局そのものを指定する（/はいらない）。
レピータのみ、無線機名がAであれば、/JP8YDZのように、Aを省略できる。
（相手局そのもの、MYの無線機名は省略できない。書かないと、無線機名「なし」と
　判断される。ただし、無線機名「なし」とすることもできる）

---

■その他（ちょっと前回書いたけど）

GPSで位置情報を送り、地図上に出すこともできる
レピータの設置状況
ICOMの無線機紹介（＾＾；）
　新しく出たID-80,ID-880が設定が簡単らしい

---

■参考サイト

・ICOM D-STARサイト
http://www.icom.co.jp/d-starsite/

・JARL D-STARサイト
情報　http://www.jarl.com/d-star/
技術　http://www.jarl.com/d-star/doc1/d-star-index.html

・JARL D-STAR Home PAGE
メインページ
http://www.jarl.or.jp/Japanese/7_Technical/d-star/d-star-ip.htm

管理サーバー登録（登録しないとゲートウエイを越えられない）
http://www.jarl.or.jp/Japanese/7_Technical/d-star/application-rule.htm

・D-STARシステムログ
https://www.d-star.info/usr/usr_login_disp.php

---

■しつもん１

・埼玉、いける？
　埼玉は西東京レピータ、一部OK

・なぞの外国人の質問？ご意見？？（もともとは英語）

１）GPSマイクは高い
　（実際には価格を書いて説明していたんだけど、
　　その値段があとで調べたものと一致しなかったので、
　　価格をかくのはやめときます）

　おこたえ
　・たしかに（＾＾；）
　・そのうえ、ID-80とID-92は（防水が違うため）共用できなかったりします（＾＾；）

２）URはなんでURなの？
(って、yourの略符号がURなんだよ　(-_-;））

３）日本には、１４５MHｚ、４３０MHｚ、１２００MHｚとアマチュアバンドがあるよね
　（いや、もっとあるけど、ここでは省略ってこと）

　で、４３０とかで、

　　432.200 A

　とかいれる、Aってなに？
（ウィリアムのいたずらは、アマチュア無線はやってないので、よくわかんないけど、
　それって、D-STARの設定なの？？？

---

　午前の部（１１：００から）は、ここでおわり
　午後の部につづく

インターネットを使ったアマチュア無線、D-STARのお話を聞いてきた！（その１：設定）

　
　インターネットを使ったアマチュア無線、D-STARのお話を、今日（２５日）icomの東京営業所できいてきたので、報告！

　なななんと、用意された席（４０席？）は満席！！
　ウィリアムのいたずらは遅めにいったので、机のない椅子だけの席だったぞ！
　人気なのですね、D-STAR

---

■D-STARのしくみ

　D-STARは、インターネット（というかデジタル通信）を使って、QSO(＝交信）するシステム。国内の遠くの局や海外局と通信することができる（いや、ローカルで通信してもいいんだけど）。

　しくみは、こんなかんじ

　　Aさん――レピータ局１＝＝＝インターネット網＝＝＝レピータ局２――Bさん

　　　　　　　　　　　　　　（JARL管理サーバー）

Aさんが東京、Bさんが沖縄だとすると、

　　Aさんは、西東京のレピータ局につなぐ。
　　そうすると、インターネット網を使って
　　　　　（この間に、JARL管理サーバーを経由する）
　　Bさんがいる沖縄（宜野湾）のレピータ局に音声などが届き、
　　そのレピータ－からBさんに電波が飛び、通信できる

ただし、アシスト局というのがあって、自分は西東京にアクセスするんだけど、インターネット網は調布からだすということもできる。理由は、西東京と調布が１０GHｚ帯で接続しているから。
　また、レピータ－局１だけで通信する、つまり、インターネット網に出ない、シンプレックス通信というのも可能だそうな。

　通信としては、音声を流すDVと、デジタルデータを流すDDがある。DDの場合、つまり、アマチュア無線を使ってメールなどのインターネットができることになる（128kbps)

---

　

■なにがいるの？
・D-STARトランシーバを買う

・届け出だっけ、申請だっけ。とにかく、電波監理局（？？総合通信局）にだす
　
・JARLの管理サーバーに登録
　（JARL会員でなくても可能。ただし、この登録をしないと、
　　ゲートウエイを超えた通信ができない）

　　 JARL管理サーバー
　　　http://www.jarl.or.jp/Japanese/7_Technical/d-star/application-rule.htm

・D-STARトランシーバの設定

---

■D-STARの設定

　ようするに、設定箇所は４つ

UR　相手（相手レピータ、もしくは相手のコールサインそのもの、またはCQCQCQ)
R1　自分が使うレピータ
R2　自分のインターネットに出るゲートウエイのレピータ
MY　自分のコールサイン

このうち、使用するレピータが同じなら、MY,R2,R1を一度設定してしまえば、
あとは相手に応じてURの設定を変えるだけになる。

で、設定方法は

●UR
・インターネットを使わず、レピータ圏内の通信なら CQCQCQ
・インターネットを使い、レピータからCQを出す場合は、

　　　/レピータのコールサイン無線機名

　例　/JP1YIWB （西東京レピータ、無線機名 B=1.2GHz用）

　　　ただし、無線機名のAは、”レピータ－の場合”は省略できる

　例　/JP1YIW （西東京レピータ、無線機名 A=430MHz用）

　なお、ほかのものも一般に、８けた目が無線機名を示すので、それ以前で終った場合、
　スペースを入れる

　例 /JR3VK B

・相手のコールサインを直接入れることもできる

　例 JR3●●●
　●には、コールサイン

　スラッシュは、うたない。また、JARL登録サーバで無線機名を付けた場合、その無線機名が８文字目に来る＝１つスペースをあけて打つ

　例 JR3●●●　A
●には、コールサイン、この場合、レピータでないので、Aは省略できない
　　Aが付いていないものは、無線機名なしで登録したもののことになる。

●R1

　自分が使用するレピータ。（インターネットを使わなくても）必須

　例 JP1YIU

●R2

・インターネットを使わず、レピータ圏内の通信なら 設定しない
・インターネットを使う場合、
　　リピーターのコールサイン G
　（URと違い、/はいらない。コールサインのあと、スペースをいれて、G）

　例： JP1YIU G
　　　 JR6YZ G （スペース２つでG)

●MY
・自分のコールサイン、必須。
　なお、JARL管理サーバーに登録した無線機名（A、Bなど）をつけること
　（「なし」の場合は付けない）

---

■そのた

GPSも楽しめるらしい。けど、GPSマイクは高いらしい（＾＾；）


・・・つづく！

WiMAXの基地局って、移動して、仮設できないのかしら？

このくらいの大きさなら、移動も簡単そうに思えるけど・・・

もしできるとしたら、地震とかおきたとき、
WiMAXの基地局を被災地に仮設すれば、
ネットで通信できる？

自治体に１個、基地局つくれば・・・（＾＾；）

世界中の脆弱性が登録されているサイト

　このまえ、JPCERTの「C/C++ セキュアコーディング ハーフデイキャンプ」で聞いてきたので、メモメモ

　世界中の脆弱性が登録されているサイト　
　http://osvdb.org/

「プログラム１００％自動生成可能」の論理的根拠－その２

＜前回の話＞
　２００９年７月２２日　日経コンピューターの特集「もっと速く作れる」に、
　「１００％自動生成可能」という話が出てきているが、そのようなことが、
可能なのかどうか、考えています。

　前回までの話で、

１．入力ー処理ー出力だけでプログラムを作ることは出来ない。
　　すくなくとも、
　　入力メディア、出力メディア（デバイスって言うか）は必要

２．これがあれば、入力デバイス、出力デバイスごとに、
　　入出力ライブラリ、フレームワークがあるから、
　　それがＲＤＢに入っていれば、検索して取り出してくることはできる
　　処理内容もＲＤＢにプログラムが入っていれば、取り出せる。

というところまできました。

---

■プログラムは、これだけで、かける？

　じゃ、これだけでかけるか？というと、
　取り出すことは出来たのですが、それを順番に並べないといけません。
　場合によっては（ＩＦ文で書くように）処理をしないということもあります。

　そこで、取り出してきたプログラムたちを、条件を考慮して順番に並べる必要がある。

つまり、

　　・入力データ・メディア
　　・処理内容、順番・条件
　　・出力データ・メディア

が必要になる。ここで書いたことと同じですね。

---

■必要条件を満たす図

　そうすると、この必要条件を記述している図は・・・？
　それについては、ここで書いたけど、業務流れ図が、上記のことに加え、誰をを付け加えて書いている。
　したがって、業務流れ図があると、プログラムがかけそうな気配になってくる。

　しかし、実際には、画面定義、帳票定義、ＤＢ項目定義は流れ図にはかけないので、このへんの定義が別に必要になる。

　そして、これらの外部入出力定義と、入出力フレームワーク・ライブラリ、基本的な処理の間で一貫性があって、それらがＤＢに入っていれば、それを業務流れ図に沿って、検索して取り出して並べれば、プログラムができそうな気配である。

---

■で、１００％自動生成可能？

　その日経コンピューターに載っている例、GeneXusは、

　　業務ルール、画面、データ構造、帳票・バッチ処理

　となっている。

　　　業務ルール＝業務流れ図
　　　画面＝画面定義書
　　　データ構造＝ＤＢ、ファイル定義
　　　帳票＝帳票定義
　　　バッチ処理＝業務流れ図の一部

　と考えれば、これで画面定義、帳票定義、ＤＢ項目定義、業務流れ図がそろっているので、
　基本的な業務のライブラリ、入出力ライブラリがあれば、それを組み合わせて
　プログラム自動生成というのは、論理的に可能な話ではある。

アプリとセキュリティの融合＝NRIセキュリティテクノロジーズ＋ウィリアムのいたずら？

　このまえの、SANS　Future　Visions　２００９　Tokyoで、アプリ開発者とセキュリティ関連の人が協力してセキュリティを実現するとか、アプリにセキュリティを作りこむという話があった。つまり、「アプリとセキュリティの融合」ってこと。

　この実現の話なんだけど、そのSANS　Future　Visions　２００９　Tokyoで、NRIセキュアテクノロジーズの人がISMSの現状の策定方法（リンク先：PDF)と問題点、そしてNRIテクノロジーズが提案する簡略化したリスク分析プロセスを紹介していた。

　この簡略化したリスク分析プロセスは、データ資産の種別ごとに実施する対策をたて、未対策のもののリスクを分析するという話なんだけど、この「データ資産の種別」をどこから出してくるか言ってなかった。

---

　ウィリアムのいたずらの最近のお話、
　プログラム開発には、
　入力＋処理＋出力
　だけではだめで、入力のメディア、出力のメディアが必要っていう話を展開しているけど、まさに、そのメディアに、「データ資産の種別」が相当しますね！

　そして、この話は今後、これらの情報をすべて、提示しているのは、業務流れ図だ！っていう話になるんだけど、ということは、

　業務流れ図における、入力データ、出力データの形式（帳票、画面表示など、業務流れ図における帳票の図形、画面の図形（凡例に書いてある）で示される）から「データ資産の種別」が割り出せるから、そこから、セキュリティ対策に持っていくことができ、そのNRIセキュリティテクノロジーズの簡略化したリスク分析プロセスに持って行けますね。

　とくに、その「リスク分析プロセス」、図で書いてあった・・・ということは、ここから後に話す図の変換によって、業務流れ図からリスク分析に持って行けるわけです。
　まさに、「アプリとセキュリティの融合」ってこと？

---

　でもね、こんなにすごいことでも、たぶん、このブログをNRIセキュリティテクノロジーズのひとは見てないだろうから、あんまり意味ない（＾＾；）・・・

・・・もっとも、ほかのSIerさんでも、できそうな話ではあるが。。。。