画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案 その６ DFD

なぜか、シリーズ化してしまった、「画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案」です。

　やろうとしてるのは、
・HTMLで画面を作成し、

・AJAXでサーバ呼び出し、結果はXMLで受け取ったものを利用すると

・画面とサーバーが完全に分離する上に
　画面から、逆にさかのぼって要求仕様にまでもっていける
　→COBOLのシステムをＷｅｂに置き換えたいけど、ドキュメントもソースも無いときなんかに、利用できる

　で、実際、画面から逆にさかのぼった手順をやろうとしています。
　そして、前回までのストーリーは、こちら

●HTMLからサービスを抽出する
（１）画面をHTMLで作成する（ここがスタート）
（２）アクションなど、イベントを拾うところで、
　　　　onイベント=ファンクション
　　　として、とにかく、ファンクションをfunctionでつくってしまう
（３）作った関数について
　　　サーバーアクセスするものは、関数の中に
　　　　　sv_access(呼び出し元、呼び出したいサーバーアプリ,""）
　　　みたいなかんじで、ダミー関数を書く
（４）grepで、（３）のダミー関数（sv_access)を、一覧で取得
（５）検索した内容をファイルに保存し、Excelで読み込み、
　　　WebAPIのサービス一覧を取得する
（６）でてきた呼び出したいサーバーアプリ＝サービスを、
　　　１サービス１シートで、Excelシートにまとめる

●クライアント－サーバー分離
（７）クライアント側の画面と、サーバー側を完全に分離するためのダミーCGIを入れます。

●第二正規形の手法を使って、ER図にもっていく
（８）引数を入力データ項目、返り値を出力データ項目とし、
　　　それらが、一時的なものか、永続的データかを決める。

（９）永続的データをエンティティと属性部分に切り分けます。

（１０）エンティティごとに、属性を書き足していきます

（１１）一意にできるものがあったら、そいつを主キー、
　　　　なければ番号をつけて主キーにして

（１２）エンティティは完成

（１３）この場合、繰り返しがあったら、別エンティティにして第一正規形
　　　　エンティティ内で、ある値がきまったら、必ず他の値も決まった値になる
　　　　という第三正規形があったら、分けたかったら分ける。

（１４）外部のエンティティの主キーを参照キーとして持てば、
　　　　他の値は持つ必要がなければいいやつは、参照キーだけをもちます。

（１５）参照キーと主キーから関係は出ます。
　　　　カーディナリティは、主キーのほうが１、参照キーのほうは、０～N,
　　　　エンティティは（１２）で完成したので、

（１６）ER図がかけます。

●CRUD図を描いてER図とWebAPIの確認をします
（１７）CRUD図を描いて、検算する

（前回１８と書いたのは、１７の間違いです）

　今日は、その後の工程、DFDをだんだんさかのぼって行きます。
　クラス図の場合も書いときます。

---

■一番最下位のDFDを書きます
　一番最下位のDFDを書きます。これは、

１．画面を入力、あるいは出力とし、
２．呼び出した画面のアクションをプロセスとして、
３．そのプロセスでアクセスするDBなどの入出力を、プロセスの入出力として
　　（画面のほかに）追加します

こうすると、アクションをプロセスとして、それに入出力がついた、１プロセスのDFDができます。

---

■その上のDFD、さらにその上のDFD・・・・

　最下位１つ上のDFDは、これは、画面構成が適切な場合なのですが、
　同じ画面の中にあるアクション（たいてい、画面にはいくつかのボタンがついていて、それがアクションになっている）をまとめて、１つのプロセスとします。
　そのプロセスの入出力は、中に入っているアクションのプロセスの入出力を、まとめたものになります。

　さて、その画面のDFDをさらにまとめる。。。には、その画面を呼び出したメニューでまとめることになります。
　メニューの内容（タイトルにたいてい書いてある）が、１プロセスになり、そのメニューで呼び出す画面をまとめることになります。
　そのメニューのプロセスの入出力は、中に入っている画面のプロセスの入出力を、まとめたものになります。

　メニューの上は、そのメニューを呼び出すメニューなんてやっていくと、一番トップがシステム全体になります。

---

■適切な画面分けになっていない場合

　以上は適切な画面分けになっている場合ですが、そうでない場合、つまり画面を恣意的に分けてしまった場合は、運用手順ごと、あるいはER図の関係などからまとめて行きます。

---

■クラス図の場合

　DFDでなく、クラス図を書く場合でも、今回の方法は一緒です。

　今回の構図を図にすると

　　システム
　　　｜
　　メニュー
　　　：
　　　：
　　画　面
　　　｜
　　アクション

という構図になっていますが、クラスもこのような形で考え、
　アクションをメソッドにして、
　画面をクラスにして、
　メニューをクラスを含むクラスにする。。。

　という形もできるし
　アクションをクラスにして（executeメソッドが実行）、
　画面をアクションを含むクラスにして、
　メニューをクラスを含むクラスにする。。。

　という形もできるし。。。と、クラス図の場合は、いろんな形が書き得ます。

---

　ということで、

（１８）アクションを最下位プロセスとし、画面、メニューとさかのぼり
　　　　DFDないしクラス図を完成させます。

でした。次回のこのシリーズは、アクティビティ図などについてです。


　

「ビル・ゲイツ会長の講演にLinux関係者が乱入して大騒ぎ」だって！。。

ここのGIGAZINEの記事
ビル・ゲイツ会長の講演にLinux関係者が乱入して大騒ぎに
http://gigazine.net/index.php?/news/comments/20070421_opensource_billgates/
によると（以下斜体は上記記事より引用）


　中国を訪問中だったマイクロソフトのビル・ゲイツ会長が4月20日、北京大学で講演したわけですが、講演後の学生を対象にした授賞式中に「ソフトを無料化しろ！ソースコードを公開しろ！」というような意味のことを書いた紙を掲げた男が壇上に上がってきて乱入、英語で「マイクロソフトの独占に反対する！」と叫び、警察に連れ出されたそうです。

この男、なんと中国においてLinuxの普及を訴えるNGO団体の中国代表らしい。


ちなみに、上記のURL(GIGAZINEの記事）には、そのときの写真が出てます。


えーっと、こんなのアメリカで報じられたら、
Linuxとかの話はふっとんで。。
中国といい、韓国といい、アジアって。。（－＿－）
って、アメリカの人に思われないかなあ。。。

に、日本は、ちがいますよお。。。

福沢諭吉じゃないけど、「脱亜論」を唱えたほうがいい？？

開発の初めから順番に書いていってみる その３４：詳細設計（１）外部設計との相違

シリーズ「開発の初めから順番に書いていってみる」の続きです。

　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　前回までで、要求分析と、外部設計がおわりました

　いままでのは、
　ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm
　にまとめてあります。

　今回から、内部詳細設計に入ります

---

■内部詳細設計とは

　内部設計、あるいは詳細設計といわれる部分は、どのようなプログラムを書くかということになります。つまり、プログラムに即した設計になります。
　一方、外部設計の段階は、入出力と、プログラムの外側からみたかんじ（書式とインターフェース）になってきます。プログラムに即しているとは限りません。

　具体的に言うと、外部設計の一番下の段階では、

出荷一覧出力
受注マスタデータに、本日分データをマージし、出荷日順にソートし、明日の出荷一覧を出力する。

となっていたとします。

このとき、やることは
１．マージ（受注データ、本日分データ）
２．出荷日順ソート
３．出荷一覧出力

になります。ここで、マージの方法は、言語によって違います。

１．COBOLなどでは、一回ソートして、キーをマッチングしながら出力します。
２．DBにアップデートするなら、
　　　　データ検索してあれば更新
　　　　なかったら挿入します
３．Javaなら、受注データ、本日分データのキーとレコードを
　　ハッシュマップにいれ、putします。
４．perlの場合は、Javaのハッシュマップが連想配列になります。
５．ExcelVBAなら、キーと値のシートをつくって作業するとしやすいかも。。
６．Fortranでやるやつはいないと思うけど、Cobolと同じ
７．Cでやる場合も、COBOLに似てるけど、ソートに関しては関数がある
　　→ただし、qsortは、同じ値のとき、順番が保たれるか？
　　　　　　：
　　　　　　：

　このままかきつづけると、SmallTalkでは、Pascalでは、Lispでは。。と永遠と続きそうなのでやめますけど、とにかく、言語によってやり方は違います。

　詳細設計では、その辺の使用言語への落とし込みが必要になってきます。

---

■逆に言うと外部設計では、言語に依存しないほうがいい

　っていうことは、逆に言うと外部設計は言語に依存しないほうがいいです。
　依存してしまうと、その言語がわかんないと？になってしまいます。

　仮にCobolよりの外部設計を書いてしまうと、COBOLからJavaへの移行で、COBOLがわかんないと、外部設計がわかんない・・詳細設計はもちろんわかんない・・書いてあるソースコードもわかんない・・ってなると、要求分析から、操作している画面までの中身が、まったくわかんなくなっちゃいます。

　言語は永遠でないというより、１０年もしないで流行すたりがあるので（昔はCOBOL全盛だったんですよ。。Cも、今よりもずっとはやってたし。。VBは、今後どうなるかわかりませんね。。）、外部設計は、言語に依存しないほうが、後々のためにいいような気がします（といっても、まったく依存しないで書くのはむずかしいんだけどね。。）

---

　次回は、詳細設計のドキュメントについてです。

アジャイルは、「修正すると、よくなる」という信念に基づいている

シリーズ化してる？「オブジェクト指向分析（開発）の存在理由」のつづき。

　DFDやDOAは、データ構造が決まらないと、プログラミングに入れない、なので、大きいシステムや未知のシステムはなかなか作れないのに対し、オブジェクト指向はある程度きまれば（エンティティレベルで）プログラム可能という話を書きました。
　で、そのように、あんまり決まってない状態で開発に入る場合、
　アジャイルとテストファーストという考えが導入されやすいということを前回かきました。

　そして、前回の最後に、、「オブジェクト指向、アジャイル、テストファースト」に流れる、一つの信念について考えます。
　というのを書きました。
　今回は、その信念についてです。

---

■アジャイルは、「修正すると、よくなる」という信念に基づいている

　アジャイルは、リファクタリングなどで、現状のものを修正しているように、「修正しているとよくなる」という考え方に基づいています。

　仮に、修正すると、悪くなるんなら、プログラムを一回書いてOKにならないといけません。どんどん悪くなっちゃうから。でも、これはウォーターフォールです。アジャイルにはなりません。
　なので、アジャイルの考え型は、「修正すると、よくなる」と考え、それに基づき、テストをしながら、どんどんよくしていくと考えないと、へんです。

---

■でも、「修正すると、よくなる」かあ？

　でも、これ、本当でしょうか。。

　たしかに、あるところまでは、正解です。
　ただ、システムは、あるところまで行くと、崩壊してしまいます。複雑すぎて、良くわかんなくなります。

　「もう、手を入れないで！」というプログラムが出てきたり、
　「初めから作り直しましょうよ！」というプログラムが出てくる、あれです。

　複雑に、できるだけしない書き方というのはあるものの、
　やっぱ、ある程度の複雑さを超えると、修正することによる限界というのは、ありそうな気がします。

---

■開発の旧来の考え方は、「修正すると、よくなるかどうかわからない」

　で、アジャイルが出る前までの開発の旧来の考え方は、「修正すると、よくなるかどうかわからない」、むしろ、悪くなる危険大と考えます。
　だから、ウォーターフォールだし、デグレードしないため、回帰テストを行います。

　これが、リファクタリングしようとする、若い人たちと対立します。
　リファクタリングは、「修正すると、よくなる」という考えなので、修正しようとします。でも、一般的には、よくなるかどうかわかんないので、回帰テストをしないといけません。なので、テストが終わったものは、修正してほしくありません。

　そこで、リファクタリングなんていう、回帰テストしなきゃいけない手間が増え、デグレードする危険のあるモノは、やってほしくありません。

　これについて。。。でも、実際デグレードすることあるしねえ。。
　え、ウィリアムのいたずらの周りだけ？デグレードするのは（＾＾；）

---

■仮に「ある一定のところで、修正すると、崩壊する」とすると

　でも、”仮に「ある一定のところで、修正すると、崩壊する」”としても、オブジェクト指向には、価値がある。
　それは、ベンチャーや新規事業の一部などで、あんまり良くわかんないときに、とりあえずシステム化する、でも、そんな大きなシステムにはならないはずというような、Webシステムでは、有用な手段である。
　この場合、規模が大きくなければ、修正するほうがよくなるだろうし、全体像が分からないので、DOAより、オブジェクト指向のほうがいい。

---

　で、このシリーズの次回では、DOA,オブジェクト指向を位置づけ、大きなシステムでは、どーすればいいことになるのか？について考えてみたいと思います。

「グーグル・アース」規制か－テロリストに使われ脅威深刻

ここのニュース
「グーグル・アース」規制かテロリストに使われ脅威深刻
http://news.goo.ne.jp/article/facta/world/20070422-01-00-facta.html
によると、グーグルアースが

「見えすぎちゃって困るの」

らしい
（すみません。若い人にはわからないかも　＾＾；
昔のCM(たしか、マスプロアンテナ）です）。

それによると、いろんな実例が書いてあるんだけど、
（以下斜体は上記サイトより引用）

マンチェスターに住む容疑者が核施設を含む発電所の機密構造の画像を収集していることが判明した。


うーん、たしかに原子力発電所とか、標的にされたら、やばそうだよね。
大きい建物だろうから、はっきり写っちゃってるかもお。。
で、


グーグルのスポークスマンは、映し出される画像は様々な形で一般公開されているもので、過去の映像であるとしているが、「悪用される可能性がある」ことは認める。「もちろん政府の要請に従う方針で、軍とも連絡を取るようにした。準備はまだ整っていないが、要請を受けてきちんと対応するつもりだ」と述べている。


そうな。日本も要請にむけて。。。？？
北朝鮮とかは。。。いろんなところを要請しそうだ（＾＾；）

NTTデータ、「日の丸勘定系」計画始動、富士通はまずは差異を明確にすべきだよね！

日経コンピューター２００７年４月１６日号（特集「ＩＴがあってこそ」の号）１３ページのＨＯＴ　ＮＥＷＳに”ＮＴＴデータが「日の丸勘定系」計画を始動”という記事があります。
　それによると（以下斜体は上記記事より引用）

　ＮＴＴデータが、開発中のオープン勘定系パッケージ「Ｏｐｅｎ　ＢｅＳＴＡ（仮称）」を銀行業界の標準製品に育てているプロジェクトを進めていることがわかった。勘定系システムの開発実績がある富士通や日立製作所、ＮＥＣに、銅製品に取り扱いを強く働きかけている。


　そうな。キーポイントは、約２０の地銀から勘定系の開発・保守を受け持っている富士通がどう動くかだそうな。。

　こーいうのって、現行システムと、その標準化しようとするものとの差異を、まずは、明確にすべきだよね。。
　まあ、もし、同じであれば、パッケージに載ってしまえば、富士通は逆に、そのパッケージ上で動く付加価値システムを作成していままでの顧客＋それ以外の顧客に販売するという手もあるし、逆に、差異があれば、その点をユーザーに強調して。。っていうことができる。

機能面で大差ないとされる

っていう話だけど、実際には、処理スピードとか、微妙なデータの持ち方の差異とかがあるだろうし、そこが致命的な差ということもあるので、機能といった、動詞的な世界だけでなく、名詞的、副詞的世界の部分もチェックしないといけない（まあ、そこまで世の中のフィットアンドギャップ分析の理論が進んでいるのかという話もあるが。。）
　

---

でもこれって、ＮＴＴデータはギャンブラーじゃないのかなあ。。

パッケージみたいなものは、完璧なものは結局作れない。
だからＡとＢという２つがある場合、ＡでうまくいかないとＢ，でもＢでもうまくいかないとまたＡと顧客は漂流し、結局、いいパーセンテージのところでとまる。その際、ＡでやっていることをＢで、ＢでやっていることをＡでやれば、ずっとバージョンアップが出来るので、どちらも儲けることができる（これが、マイクロソフトが、Ａｐｐｌｅをつぶさない理由だと思う。。もし、マイクロソフトがＡｐｐｌｅをつぶしちゃったら、自分で全部開発しないといけない）。。

　でも、もし、Ａパッケージで業界全部のシェアを取ってしまったら、短期的には、ぼろもうけだろうけど、結局不満のあるユーザーは、満たされない気持ちをどこかで引きずっている。
　そこで、新たな新興勢力が出てくると、一気にシェアがひっくり返されてしまう。
（印刷における写研→ＤＴＰのようなかんじ）。

　今回のケースでも、これで、もし、「日の丸勘定系」っていうのが出来た後で、地銀になんらかの不満が出た場合、ＩＢＭとかユニシスあたりが、地銀向けシステムを出されたら。。やばくない（＾＾；）？

Hello World程度のデータベース（その１６：内部スキーマ（４）テーブル作成）。

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

　今、三層スキーマ構造（概念スキーマ、内部スキーマ、外部スキーマ）の内部スキーマをやっています。
　で、いままでの話で、内部スキーマは

　　　テーブルは、いくつかの項目をもっていて、項目には型がある
　　　インデックスという早く検索できるしくみをつけることができる。
　　　　　　これは１ないし、複数の項目からなり、Ｂ木とハッシュがある

　ということをかきました。

　で、きょうは、実際にこれを宣言して見ます。

---

■テーブルを作成する
　テーブルを作成するには、テーブル作成をするＳＱＬというのを書いて、実行するのですが、ＭｙＳＱＬだと、その前にデータベースというのを作成します。
　ＳＱＬについては、外部スキーマ編でくわしく書きます。

　いや、それまで待てないという人は、
JavaでHello World ＞ JDBC(MySQL)編
http://www.hellohiro.com/jdbcmysql.htm
を見てください。

　ＭｙＳＱＬの場合、以下の手順で、テーブルを作成します。

１．ＭｙＳＱＬをインストールします（これは１回でいい）

２．ＭｙＳＱＬデーモンを立ちあげます（サーバーを立ち上げるたびに行う）
　　mysqldコマンドを打ちます。オプションも付けられます。詳しくは上記サイト参照

３．データベースを作成します（あらたなＤＢを作りたいたびごとに）
　　mysqladminコマンドで作成します。オプションも付けられます。詳しくは上記サイト参照

４．対話型MySQLクライアントを起動します
　　mysqlコマンドで起動し、３でつくったデータベースを選択します
　　（引数から指定して選択できるし、use データベース名;で、mySQL内でも切り替え可能）

５．テーブルの作成
　　テーブルを作成するＳＱＬ文を実行します。
　　ＳＱＬ文の内容は、以下に話します。

---

■テーブル作成のＳＱＬ文
上記のＪａｖａでＨｅｌｌｏ　Ｗｏｒｌｄに、テーブル作成の例があります。

CREATE TABLE HELLO_WORLD_TABLE (
  NO INTEGER NOT NULL,
  LANGUAGE VARCHAR(50),
  MESSAGE VARCHAR(100),
  PRIMARY KEY(NO)
); 

こんなように、

CREATE TABLE テーブル名 (
　　項目名　型　制約(Not NULLなど）があれば。。（なければかかない）,
　　　　　：
　　　　　：
　　PRIMARY KEY(主キー項目）
);

というかたちで書きます。
なお、主キーが２項目以上の場合は、
　　PRIMARY KEY(主キー項目１,主キー項目２,・・・主キー項目Ｎ）
となります。

ちなみに、

CREATE TABLE HELLO_WORLD_TABLE (
  NO INTEGER NOT NULL,
  LANGUAGE VARCHAR(50),
  MESSAGE VARCHAR(100),
  PRIMARY KEY(NO)
) TYPE=InnoDB;

というように、最後にInnoDBとかつけると、InnoDB形式でＤＢをつくります。
InnoDBは、トランザクション処理が可能になります。

CREATE INDEXの書き方のちゃんとした説明はここ
6.5.3. CREATE TABLE 構文
http://dev.mysql.com/doc/refman/4.1/ja/create-table.html

---

■インデックスのつくりかた

　で、インデックスについて。
　インデックスは、CREATE TABLEの中にもかけるし、あとで、
ここ
http://homepage2.nifty.com/sak/w_sak3/doc/sysbrd/mysql_06.htm
に書いてある

create index KEY_NAME on testm (
  key1,
  data1
);

のように、
CREATE INDEX インデックスの名前 ON テーブル名(項目１,・・・,項目Ｎ）
のかたちで、あとからつけることができる。

CREATE INDEXの書き方のちゃんとした説明はここ
6.5.7. CREATE INDEX 構文
http://dev.mysql.com/doc/refman/4.1/ja/create-index.html

---

■Ｉｎｄｅｘの形式は？
　インデックスが、Ｂ＋かハッシュかについてですが、
ここ
5.4.3. MySQL でのインデックスの使用
http://dev.mysql.com/doc/refman/4.1/ja/mysql-indexes.html
によると、以下のように書かれています。

MySQL インデックスのすべて（PRIMARY KEY、UNIQUE、および INDEX）は、B ツリーに格納されます。

とかかれています。（４．１のマニュアルですので、現在はちがうかもしれません）

なお、HEAP テーブルは、ハッシュインデックスを使用するのですが、メモリ上に作成し、テンポラリとしての利用がすすめられています（つまり、ＤＢとして永続性をもつようなものを意図しているわけではない）
くわしくは、以下を参照
7.4. HEAP テーブル
http://dev.mysql.com/doc/refman/4.1/ja/heap.html

---

■なお。。
　富士通のＤＢ、ＳｙｍｐｏＤＢでは、ちょっと書き方が違うというか、領域設定など、いろいろとあります。これは、別の機会にかきます（このシリーズではなく）。今、手元に資料がないので。。

---

　で、今回で、内部スキーマは終わりです。次回から、外部スキーマについてです。

ＤＴＰの構造を考える－その４：ライブラリ

　土日シリーズ「ＤＴＰの構造を考える」です。
　いままでは、本をトップにして、その下の物理構造、論理構造と組版規則について書きました。
　今回から、本という概念をこえ、ＤＴＰ全体でもつものについて、書きます。

　今回はまず手始めにライブラリ

---

■ライブラリとは
　ライブラリは、複数の本（文書ファイル）で、ある部分のデータ（小組やイメージなど。毎回使う図とか）を共通に使う場合、その部分のデータをいれておくところです。

　基本的な使い方は、このように、週刊誌のような定期的に本を作成するとき、決まりきった部分をこのライブラリに入れておいて、貼り込むというものです。

---

■ライブラリの使い方応用－自分の担当分をライブラリに入れて、集版する

　で、他の使い方としては、
　たとえば、本やチラシなどで、ここの部分はＡさん担当、ここの部分はＢさん、ここはＣさんなどというふうに、いくつか担当をわけたときに、みんな担当部分が出来たら、そのデータをライブラリに入れて、最後に、集版して、ライブラリからできたものをとりだし、貼りこむというものです。このばあい、ＡさんＢさんＣさん同じライブラリにアクセスできないといけません。


　この応用で、自動組反するとき、作成した小組みを一時的に入れておき、最後に読み込むという方法が考えられます。とくに大量データを作成するとき、ここの部分の自動生成は、マシンＡ、ここはマシンＢなどと割り振れるので、利用しがいがありそうですけど。。こういう使い方はみたことないなあ。。あるのかなあ。。

　さらに応用として、データをメールで送って、メールがきたら自動的に自動組版して、その結果をライブラリに入れたら。。って思うかもしれませんが、たぶん、そうするより、メールを人が貼り込んじゃったほうが早いです。
　

---

■ライブラリの注意点－作成時と利用時で環境が違う場合

　ライブラリの注意点としては、作成時と利用時で環境が違う場合です。
　作成時にあったフォントが、利用時にないとか・・・

　あと、バージョンが違う場合です。
　貼りこんだ直後には、変化ないけど、なにかちょっと触れただけで、新しいバージョンの組み方になり、文字あふれがでるとか。。そーいうのが危険です。
　また、貼りこんだ直後には、変化ないように画面で見えたけど、印刷したら、新しいバージョンの組み方になり、文字あふれがでるとか。。っていう危険もないとはいえません。
　あふれは、ほんのちょっとの差（誤差程度）でも、おこるので、ちょっとした丸め誤差が新しいバージョンでおきると、再度組反しなおし、文字あふれになるということは、あり得るのです。

　また、当然ですが、組版規則が違うところに貼りこめば、文字おきはかわります。
　このとき、ただ貼りこんだだけで、なにもさわらないと。。
　新しい組版にならないで、前のまま貼り込んでしまう可能性もないとはいえません。
（一字でもいれれば、新しい組版になる。このとに、その文字を削除しても、前と同じ組版になるかどうかはわからない）

---

　ってことで、ライブラリは、こんなかんじで、簡単に触れるだけとし、次回のこのシリーズではフォントと外字、合成文字等の話を書きたいと思います。

コンテンツといいながら外側の話だけしてる方が問題！知財本部のコンテンツ専門調査委員の話

　ただ、さっきブログにかいた
「ゲームで感動は難しい。ゲームなんて文化じゃない」と知財戦略本部コンテンツ専門調査会メンバー発言
http://blog.goo.ne.jp/xmldtp/e/af87dcea0e06dac891ac06f55813f285
で、本当に問題なのは、

　コンテンツって、中身のことじゃないの？

いや、辞書に、そう書いてあるとか、そーいう言葉遊びの問題ではなく、「涼宮ハルヒ」とか、「電車でＧｏ！」とか、その中身、まあ、せいぜい、大きくくくっても「宮崎アニメ」とかいうかんじの一連の作品の中身や、蛯原友里さんという人物、こういう中身がコンテンツであって、

　映画とか、アニメとか、ゲームとかはメディアというか、外側のパッケージに相当するものじゃないの？

　つまり、映画産業やアニメ産業の作品だから、知的財産になるんじゃなくって、「涼宮ハルヒ」というコンテンツが知的財産なんであって、それを、映画やアニメやゲームに展開するのに、どうしたらいいかっていうのを考えるのが戦略なんじゃないのかあ？？

　たとえば、「電車でＧｏ！」は、海外の鉄道版を作って売り出せないか？とか。。
　「涼宮ハルヒ」をキャラクター化して、世界的にグッズ販売するには？とか。。
　そーいうための知的財産の整備をするのが、本来大切な仕事なんじゃあ。。

---

　そーいう意味では、「クレヨンしんちゃん」が中国で、出版元がだしたものが、商品撤去させられるというのが、知的財産における問題なのであろう。

　でも、今の委員たちの発想で行くと、映画なんかを、どんどん輸出しようとしている。

　そんなことしたら、結局、中国で偽物キャラクターをばんばん作られ、逆に、日本からグッズを売りに行こうとしても、「それは偽物、撤去せよ」っていわれて、中国企業を儲けさせるだけだろう。

　日本のコンテンツビジネスとしては、グッズが売れず大失敗になる（アニメだけでは、限度があるだろう。儲けにも）

---

　こういう、キャラクターをどのように保護していき、多様なメディアやグッズを海外で出来るようにするためには、どうしたらいいかっていうのを考えるのが、本来一番大切なはずなのに、映画がどーのこーのだの、ゲームはどーのこーのだ。。って言っているのでは、発想が逆（外側から考えていて、コンテンツからの発想がない）だろう。

　だから、コンテンツとして、一番重要なキャラクターという分野がぬけてしまう。

　世界的に通用するコンテンツとしては、「キティちゃん」というキャラクターもあげられるが、キティちゃんに物語は、基本的にない。なので、キティちゃんで、あんまり感動はしない（もちろん、キティちゃんがいなくなる日（キティちゃんは、「なかよし」を意味しているので、なくなる日は２つある。１つは世界中が戦争になって、なかよしなんていってられなくなる日、もう１つは、世界中のみんなが仲良しになって、キティちゃんが必要なくなる日）に感動したり、キティちゃんの社会貢献（キティちゃんは、難病の子の病院に行って、訪問している）に感動する人はいるかもしれないけど、それは、「キティちゃんに感動している」というわけでは。。）。
　でも、重要なキャラクターで、日本を代表するコンテンツと言えるだろう。

　ドラゴンボール、セーラームーンも、アニメ自体より、キャラクターとして、グッズ化した部分のほうが、ビジネス的には成功しているといえよう。

---

　うーん、知財というなら、中身から、外側のパッケージ（メディア）展開を考え、それの整備をすべきなのに、外側から入っていくという、まったく方向が逆のアプローチを取っているわけで。。

　これでは、スタートラインにたっても、ゴールに向かって逆方向に走ってるんじゃないか？
　結局、がんばればがんばるほど（映画を輸出すればするほど）、結果は遠ざかる（知的財産を守るどころか、偽物ばかり作られて、他国が儲かる）気がするぞ（＾＾；）

「ゲームで感動は難しい。ゲームなんて文化じゃない」と知財戦略本部コンテンツ専門調査会メンバー発言

っていうより、 東京大学大学院の浜野保樹教授が発言って言ったほうが、インパクト大きいか。。

ここの痛いニュース
「ゲームは時間を奪う。ゲームで感動は難しい。ゲームなんて文化じゃない」… 内閣知財戦略本部コンテンツ専門委員会
http://blog.livedoor.jp/dqnplus/archives/960439.html
によると（以下斜体は上記サイトより引用）


「人気あるコンテンツを切り込み隊長として、日本ブランドを確立して、
産業振興を図るべき」と主張する浜野保樹氏

「ゲームについては、ぼくは異論がある。アニメや漫画は感動をもたらすけれど、ゲームは、お金だけ持っていって、子供の時間奪ってますね。その人生にプラスアルファがない。宮崎さんとか他のアニメ見て、人生変わったという人はいると思います。心ふるえるほどの感動とか、ゲームは若干難しい。


おいおい。。
まず、「ゲームはアニメにくらべ、心ふるえるほどの感動が若干難しい」って言い切れるか？
感動するゲームをやった人って多いんじゃないかなあ。。意外と。。

アニメなどは見ているだけなので、積極的な関与がないから、感動しにくいけど、
ゲームだとクリアしたときの感動があるから、むしろ感動はしやすい気がするんだけどなあ
（当たり前だが、すべてのゲームで感動するわけではない）

それと、「子供の時間奪って」っていうのは、それ以上おもしろい物がないからだろう。。
もし、アニメのほうが面白ければ、アニメを見ると思うけどお・・・
その痛いニュースの４３６番目の発言に

伊集院光の発言

「そんな、ゲームなんてやっても時間の無駄じゃん」
とか言う人に対して
「いや、何怒ってるか知りませんけど、僕はその時間を楽しくつぶしたいんで」
と思うわけですよ。
“たかがゲーム”って言い方は合ってるんですよ。ゲーム好きから言うと。
http://tuneari.fc2web.com/radio/ijyu060515.html


のほうが、なっとくいく。。

そもそも、感動与えないと、コンテンツじゃないのかねえ。。
あんまり、Linuxで感動する人って、少ないと思うけど。。。
え、Ｌｉｎｕｘはコンテンツではない？？

じゃあ、知財がコンテンツといっていて、対象にしてるものから選ぶね！
ここ
知はうごく：コンテンツ力（７－３）日本の戦略
http://www.sankei.co.jp/culture/enterme/070320/ent070320001.htm
に、その発言の元ネタがあるんだけど。。


日本も米仏に倣った戦略を採る。平成１５年に内閣の知的財産戦略本部にコンテンツ専門調査会が設置され、日本ブランドの振興という目標が掲げられた。アニメ、コミック、食、ファッションなどで日本のブランドイメージを高めようという戦略だ。


ってことは、ファッションは、コンテンツ？
ファッションは、「かわいい」とは、思われるが。。感動するかなあ？？
え、「メイド服」で感動するって！？
それは、ゲームで感動するより、はるかに特殊なケースです（きっぱり！）

。。。でも、メイド服もコンテンツとして保護するのかあ（＾＾；）
そもそも、ファッションは「なまもの」なので、アニメやコミックとかなり違うものだと思うけどなあ？？（つまり、今日かわいいものでも、２、３週間後に、保護対象になったときには、ただの布着れ、ゴミにしかすぎないものもある。だから洋服はＳＰＡとか毎日配送とかやっているのね）

---

ただ、ゲームを知財からはずしてくれるというのは、賛成！
下手に国が保護してなんかやったら、利権とかが絡んで、
急におかしくなってきちゃう。。。
規制とかでて、一部のゲームが禁止になったりしても困るし。。

って言う意味で、ゲームをはずしてくれたことは、プラスかも。。
ゲームはゲームでお役所にかかわ自由にやったほうが、発展するでしょ！

画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案 その５ CRUD図

　なぜか、シリーズ化してしまった、「画面定義をHTMLで行い、呼び出しをWebAPIでやる設計手順の試案」です。

　やろうとしてるのは、
・HTMLで画面を作成し、

・AJAXでサーバ呼び出し、結果はXMLで受け取ったものを利用すると

・画面とサーバーが完全に分離する上に
　画面から、逆にさかのぼって要求仕様にまでもっていける
　→COBOLのシステムをＷｅｂに置き換えたいけど、ドキュメントもソースも無いときなんかに、利用できる

　で、いままで、以下の手順で、画面からWebAPIを割り出し、ER図まできました。

●HTMLからサービスを抽出する
（１）画面をHTMLで作成する（ここがスタート）
（２）アクションなど、イベントを拾うところで、
　　　　onイベント=ファンクション
　　　として、とにかく、ファンクションをfunctionでつくってしまう
（３）作った関数について
　　　サーバーアクセスするものは、関数の中に
　　　　　sv_access(呼び出し元、呼び出したいサーバーアプリ,""）
　　　みたいなかんじで、ダミー関数を書く
（４）grepで、（３）のダミー関数（sv_access)を、一覧で取得
（５）検索した内容をファイルに保存し、Excelで読み込み、
　　　WebAPIのサービス一覧を取得する
（６）でてきた呼び出したいサーバーアプリ＝サービスを、
　　　１サービス１シートで、Excelシートにまとめる

●クライアント－サーバー分離
（７）クライアント側の画面と、サーバー側を完全に分離するためのダミーCGIを入れます。

●第二正規形の手法を使って、ER図にもっていく
（８）引数を入力データ項目、返り値を出力データ項目とし、
　　　それらが、一時的なものか、永続的データかを決める。

（９）永続的データをエンティティと属性部分に切り分けます。

（１０）エンティティごとに、属性を書き足していきます

（１１）一意にできるものがあったら、そいつを主キー、
　　　　なければ番号をつけて主キーにして

（１２）エンティティは完成

（１３）この場合、繰り返しがあったら、別エンティティにして第一正規形
　　　　エンティティ内で、ある値がきまったら、必ず他の値も決まった値になる
　　　　という第三正規形があったら、分けたかったら分ける。

（１４）外部のエンティティの主キーを参照キーとして持てば、
　　　　他の値は持つ必要がなければいいやつは、参照キーだけをもちます。

（１５）参照キーと主キーから関係は出ます。
　　　　カーディナリティは、主キーのほうが１、参照キーのほうは、０～N,
　　　　エンティティは（１２）で完成したので、

（１６）ER図がかけます。

　今回は、前回の（１０）でサービスに番号を振っておいて、属性を書き足したとき、そのサービス番号も書いておくと、後述する、検算のとき便利です。と書いた、検算についてです。

---

■CRUD図を作成し、矛盾を確認する

で、次の作業は、エンティティの属性の生成、書き出し、読み込み、削除が、WebAPIで矛盾なく行われているかを確認するため、CRUD図を描きます（っていっても、属性までやるのはめんどっちかったら、エンティティレベルでもOKだし、これ自体省略しちゃうことも多いと思うけど。。）なので、（１８）は、

（１８）CRUD図を描いて、検算する

　で、CRUDとは、イラクの。。って、今日２度もしょーもないギャグを書いてもなんなので、まじめにかくと、
ここ　http://www.ne.jp/asahi/ikeda/home/PCword/word/CRUD_Diagram.html
にあるような図です。

　横のテーブルのところにエンティティ（ないしはエンティティの属性）、
　縦の機能のところがWebAPIになります。

　ここで、R＝読み込みときている場合、C＝生成の機能が、順番的に前に呼び出されないとへんです。また、C＝生成がない場合は、DBにあらかじめ、データが登録されているマスター項目の内容のはずです。

　マスターで初めからデータがはいってもないし、かつ、だれも作らないのに、読み出したり、更新したら、それはへんです。

　削除は、ないってこともあります。
　１つは、手作業で削除するケース、
　他には、絶対件数が増えない（たとえば、各テーブルの件数を持っているなど）ので削除する必要はないケースです。
　なので、削除がなくてもOKなのですが、あったほうがいいかどうかを考えます。なお、Cする前にDしたらおかしいですし、Cして、Dするだけも変です（つまり、まったく読むことがないのに削除する）Cだけもへんです（つくるだけ、だれもよまない。。いらないジャン＞＿＜！）

---

　てなことで、矛盾を考えます。
　矛盾してたら、たいてい、WebAPIで引数がたりないか、サービスが足りないか、エンティティが間違っているので、なにが悪いか考えて直しましょう。

---

で、このシリーズの次回は、DFD（相当）を作ります。

開発の初めから順番に書いていってみる その３３：外部設計（１０）作成ドキュメント。

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　今、外部設計の段階で、前回までで、やることについては、一通り書きました（１個だけ書いていないことがあり、それは今回書きます）。
　なので、今回は、その成果物として作成するドキュメントの話題を中心に書きます。

---

■外部設計の成果物
　外部設計が、入出力＋詳細までの落とし込みである以上、ドキュメントも入出力の部分と詳細までの落としこみの両方があります（それ＋αがあります）

●入出力のドキュメント
　入出力については、入出力の種類ごとに、定義書があります。

　　画面があれば、画面定義書
　　帳票があれば、帳票定義書
　　DBがあれば、テーブル定義書（データベース定義書でもいいけど）
　　ファイルがあれば、ファイル定義書
　　　　：
　　　　：

　などなど。。
　で、これらの定義書の形式は、だいたいおなじ。
　

　・目次代わりに、画面／帳票。。。などの一覧があります。

　・どの手順でそれらの入出力を行うかを書いたものがあります
　　　　画面だと画面遷移図
　　　　通信だと、シーケンス図などなど。。
　　ただし、帳票やDBでは、順番もないので、ここが省略されます。
　　　　でも、テーブルの場合、代わりにCRUDやER図をいれることもあります。
　　　　CRUDとは、イランなどに住む民族（クルド人）のことです
　　　　。。っていうのはうそで、生成（C)、参照（R),編集（U),削除（D)
　　　　されるタイミングをしめすため、
　　　　　　　行か桁のどちらかにテーブル、
　　　　　　　どちらかにモジュール名（クラスでも、プログラムでもOK)
　　　　を書いて、直行するセルに、上記C,R,U,Dを記入した図です。
　　　　（後述の「UI08ユースケーステーブルマトリクス」がそれにあたります）

　・各画面、帳票などの説明です
　　　　はじめに、レイアウトやフォーマットなどの図がきます
　　　　次に項目説明です
　　　　アクションがある場合、アクションの説明があるときもあります
　　　　（項目の一種として説明し、ないときもあります）
　　　　DBの場合、インデックスについて書かれるなど、その入出力固有の情報
　　　　が付け足されることもあります。

　と、こんなかんじです。

---

■詳細までの機能について

　機能関係のドキュメントとしては、機能定義書（機能設計書）として、
　　　DOAの場合、DFD、最終的にはミニスペックまで
　　　オブジェクト指向の場合、クラス図＋シーケンス図など
　までかかれます。

　あと他に、プログラム間のデータのやり取りを示すため、
　　　データ定義（インターフェース定義）
　　　データタイプ定義
　などが必要になる場合があります（とくにDOAの場合。オブジェクト指向は、受け渡しデータもクラスなので、クラス図になってしまう）。

　ただし、前回、共通部分ということで、ライブラリのほか、メッセージやコード定義などがあるという話を書きました。
　これらの定義書もまとめます。

---

■ユースケースシナリオを書く場合もある
　で、今日の初めに、ひとつ説明してなかった話というのが、これになります。
　ユースケースシナリオは要求分析段階でもできているかもしれませんが、画面をちゃんと定義した形っていうのは、ここになります。

　このとき、ユーザーに画面定義をみてもらっても？？？になるかもしれません。
　そこで、ここで、ユースケースシナリオを作成し、文章で、どういう手順でなにを入力すると、どーなるかを書くことがあります。

---

■まとめると、外部設計の成果物はこんなかんじ

　ここで、画面と帳票とDBがある場合、結局外部設計でできる成果物は、こんなかんじです。

●入出力関係
　　　・画面定義書（画面遷移図、項目、アクション、一覧）
　　　・帳票定義書（帳票レイアウト、項目、一覧）
　　　・テーブル定義（テーブル定義、一覧、ER、CRUD等の関連図）

●機能関係
　　　・機能定義（DFD＋ミニスペックまたはクラス図+シーケンス図、データ定義）
　　　・コード定義
　　　・共通メッセージ定義

●ユースケースシナリオ－作りたければ。。

---

■富士通の公開されている作業標準との比較

　で、ここでいつも、富士通の公開されている作業標準、
1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
と比較しているので、今回も比較しましょう。

SSドキュメントとUIドキュメントが、これにあたります。
うち、SSドキュメントは機能関係の「機能定義」にあたるのですが、さっぱり意味不明になるとおもうので、まあ、そーいうことで、UI定義書とのこりの上記ドキュメントとの関係を見てみます。

　実は、「富士通の公開されている作業標準」の場合、「UI02 ユースケース機能記述」に、多くのドキュメントがまとまってしまっています（UI02のなかに、いくつものドキュメントがある）。そのため、これを崩さないと対応関係が見れません。以下、くずして、その対応関係を書きます。

●入出力関係
　　　・画面定義書
		UI02-01	画面遷移図
		UI02-02	画面レイアウト定義
		UI02-03	画面項目定義
		UI02-04	アクション総括記述
		UI02-05	アクション定義　遷移元
		UI02-06	アクション定義　遷移先
		UI03	画面一覧
　　　　　　（UI02-04～06は、機能関係のほうがいいかも？？）

　　　・帳票定義書
		UI02-09	帳票レイアウト定義
		UI02-10	帳票項目定義
		UI04	帳票一覧

　　　・テーブル定義
		UI05	テーブル関連図
		UI06	テーブル一覧
		UI07	テーブル／ファイル定義
		UI08	ユースケーステーブルマトリクス
	　　　（UI05はER図、UI08はCRUD図です。UI08は、機能関係のほうがいい？）

●機能関係
　　　・機能定義
		UI01	ユースケース一覧
		UI02-07	バッチ機能概要
		UI02-08	バッチ統括記述
		UI02-11	出力データ処理定義
		UI02-12	入力データ処理定義
		UI10	システム間インターフェース一覧
		UI11	システム間インターフェース定義
		UI14	データタイプ定義
		SSxx	各種SSドキュメント
	　　（画面の場合は、UI02-04～06の内容がここにも入ります）

　　　・コード定義
		U13	コード定義

　　　・共通メッセージ定義
		U14	業務メッセージ定義

●ユースケースシナリオ－作りたければ。。
		U15	シナリオ記述
		U16	業務サービス仕様

　となっています。ウィリアムのいたずらとは、ちがった観点から、ドキュメントをまとめているみたいですね（もちろん、どちらが正解ということはないので、こういうまとめ方でもOK)
　詳しい内容や書き方に関しては、ダウンロードしてくると、書いてあるので、興味がある人は、そっちをみてください。

---

　ということで、外部仕様に関しては、おしまいで、
　次回のこのシリーズでは、内部詳細設計について入ります。

「日産とドコモが携帯GPSを用いた交通事故低減技術を開発」って、画像処理のほうが？？

ここのニュース
日産とドコモが携帯GPSを用いた交通事故低減技術を開発
http://slashdot.jp/mobile/07/04/18/1445245.shtml

うん？ＧＰＳって、そんなに反応早かったっけ（宇宙の衛星からの電波利用するんだよね）？
飛び出したら？（飛び出すのが危ないんだよねえ。。）
まあ、そもそも、ケータイ持ってない人は？とか、いろいろ問題ありそうだけど。。

そもそも、人だけじゃなく、電信柱だろうが、建物だろうが、なんでも、ぶつけちゃいけないわけだから、車からレーダーを発射して帰ってくるのを見たほうが（＝魚群探知機の原理）。。。はやくない？？

っていうか、たしか、無人走行の車のレースっていうのをアメリカでやってたような。。
あれはたしか、先のほうの写真をとって、画像処理していた気がする。。
技術的にいまや、画像から人の抽出とかできるわけだから。。。
っていうか、それ、レースでやっているくらいだから、
そっちのほうが実用性高いんじゃないかなあ。。
暗視カメラとか使えば、夜中でも大丈夫そう。。。

---

それよりも、ＧＰＳ情報を集めるって、プライバシー的にどーなんだろう。。
もし、ＯＫなら、ドコモやauって、探偵さんができるとおもうんですけど。。
こっそりと、ご主人や恋人のいどこを追跡して教えます。。。

芸能レポーターとか、欲しそうですよね。
追いかけているタレントが、どこにいるか。。。とか。。。

。。。そんなもん、あつめて、いいんだろうか（＾＾；）

やっぱ、個人を特定しちゃまずいのかな（＾＾；）

外部設計の「見える化」が、大事かも？

前に書いた、「生物の構造と、要求から、プログラムまでの階層を比較すると、わかりやすいかも！」というところで、ソフトの場合は、基本操作からアクティビティまで、ソースコードとしてかきます。この問題や発展の可能性は、今後、別の回で書きます。ってかいていたので、その話についてかきます。

---

■なんでもソースに落としてしまうところに問題がある

　結局、ソフトの場合、入出力もライブラリも、足し算引き算も、ソートやマージといったある程度まとまった話も、さらには受注票作成といった業務も、全部、ソースコード上に落とされる。

　っていうことは、「ソースを見れば分かる。JavaDocに入出力はすべてかかれるから便利」って主張する人もいるだろうけど、現実問題、なんでもごちゃごちゃ、恣意的にかけてしまって、何がなんだか分からなくしてしまう危険がある。

　たとえば、ある人は、StrutsのActionの中で、JDBCのドライバから呼び出して、ユーザー名、パスワードをリテラルで設定して、SQLを発行することができる。
　その一方で、ある人はDBアクセスライブラリを作成し、それは、モデルからのアクセスに限定し、Actionでは、モデルをアクセスするという形にもできる。
　このとき、モデルをPOJOにしておけば、モデル単体でのテストや再利用ができる。

　このどっちも書くことが可能というか、混在させることすら可能である。
　実際には、ここまでひどくはないにしろ、やはり、恣意的に分けられる部分があって、そのことが、バグを招いたりしてしまっている。

---

■いっそのこと、外部仕様は、全部見える化＝＞自動生成にしてしまえば。。

なんで、外部仕様は、
・全部見える化してしまい、
・ドキュメントから自動生成したコードをリンクする、
・修正時は仕様書を直して再度リンク、
・個別プログラミングは、外部仕様書から呼ばれる関数部分のみ

ってできると、楽になってくると思う。

入出力部分に関して、ドキュメントから関数自動生成という話は、まあいいとおもう（というか、いつか、自動生成については、まとめて書くので、そのときに）

　問題となるのは、ライブラリや入出力、詳細設計で書かれる関数をよびだすところを書く部分。

　１つの考えとしては、Accessのマクロ画面のように、かけるというもの。
　他には、詳細のドキュメントのように書く方法。。
　フローチャートを書いてしまう方法。。。

　いろいろありそうだが、このへん、つまり、図でもってプログラミングできるという分野が、今後発展する可能性がありそうな気がする。

　そうして、外部設計が見える化してくると、あとは詳細部分のコーディングになるので、ある程度はなしが見やすくなるし、図式化することによって、（図の制限があるから）恣意的にやれる部分が減り、品質の安定にも役立つと思う。

---

　っていうのが、問題の発展と可能性。

　で、この話は、その前の要求から、プログラムまでの階層を考えないことが、開発の混乱を招いているを受けた話で、さらにその話の中で、アスペクト指向における横断的関心事の切り出しの問題や、デザインパターンの活用の話なんかは、月曜日からはなすこととして、と書いておきながら、書いてないので、このシリーズ？の次回は、その辺の話を書きます（って、いつ書くか分からないけど。。）

開発の初めから順番に書いていってみる その３２：外部設計（９）詳細までの落とし込み

シリーズ「開発の初めから順番に書いていってみる」の続きです。
　今、外部設計の段階で、要求仕様から、詳細設計までの間（ここを外部設計と、ここでは読んでいるわけですが）の手順は、以下の手順で行うと、流れに飛躍がなく説明がつくということを書きました。

（１）入出力の媒体をきめる。
（２）その媒体ごとにフレームワークを決定する。
　　　なければ、入出力方法を決定する。
（３）そのプロセスの起動方法を考える
　　　なければ、起動モジュールを考える。
（４）起動モジュールから、（２）の呼出し手順を考える
（５）その処理部分をどうするか、考える。
（６）そうすると、細分化された入出力、処理部分ができる。
　　　ここで、あわせたいものは、あわせる
（７）処理部分を、ワーカーさんに渡せるまで落とし込む。

だけど、実際にやられるのは、こんなかんじだと書きました。

（あ）フレームワークの確認から、全体的なプログラムの書き方を決める
（い）画面の設計をする
（う）ＤＢの設計をする、（その他外部の設計をする）
（え）プログラムを適当に詳細化し、詳細設計に持っていく

　で、前回までで（う）をやりましたので、今回は「（え）プログラムを適当に詳細化し、詳細設計に持っていく」です。

---

■外部設計の機能分化でやること

　要求仕様から詳細まで、機能を落としていくという作業をやるのですが、これについて、月曜日に「生物の構造と、要求から、プログラムまでの階層を比較すると、わかりやすいかも！」っていう題で書いた内容と照らし合わせて考えます。

そこの例だと、

　　　　　　　　　　細胞 ＝＝＝ アクティビティ 
（細胞小器官・細胞骨格） 　｜ （ライブラリと入出力） 
　　　　　　　たんぱく質 ＝＝＝ 基本操作群 

っていう部分がそれにあたります。
アクティビティが、
要求仕様で出ているアクティビティ（ユースケース、プロセス）
　　　　→同じアクティビティ名（たとえば受注）でも、顧客ごとに微妙に異なる
　　　　　個別性がある

で、

基本操作群が、詳細設計ででているところ
　　　　→ソート、マージなど、あんまり個別性がない言葉で表すべき
　　　　　つまり、明日急遽プログラマ増員で他社の人が来て、その仕様書を
　　　　　渡したとしても、理解できるくらい普遍的なレベル

そして、ライブラリと入出力といった、個別性ではないが、普遍的でもない
まとまり（プロジェクトレベルでは共通）とかをつかって、アクティビティを
基本操作＋ライブラリと入出力にまで落とすのが、外部設計でした。

　で、このとき、細胞の骨格を作る細胞骨格のように、プログラムの骨格をつくるのがフレームワークということでした。

　なので、フレームワークをもとに、ライブラリと入出力をつかって、基本操作にまで、アクティビティを落とし込めばいいわけです。

---

■機能分化の手順

ということで、こういう手順できめます。

１．プロセスの骨格を決める、フレームワークを決定します。
　おおもとになるフレームワークです。
　　　画面を使うフレームワークと、
　　　バッチのフレームワーク、
　とかになるのかな。。
　でも、この作成基準がないので、実際には帳票出力用、DBアクセス用。。などなど、いっぱいできちゃったりします（－＿－；）

２．フレームワークをカスタマイズします。
　プロジェクトごとに、以下の観点について考えないといけません
　　・DBを使うとき、トランザクション処理はどのように行うの？
　　・ログはどうするか→デバッグ情報もふくむ

３．入出力のフレームワークを決めます
　プロセスの骨格ではないが、共通な入出力処理（DBアクセス、ファイルアクセスなどなど）をフレームワーク化、ライブラリ化し、できれば仕様書からの自動化をします。

４．共通部分を決定します
　システムで、共通に使うモジュール、つまりライブラリを切り出し、作成します。
　ただこれ、恣意的にやられることが多いです。
　それと、他の共通部分も、抜き出します。他の共通部分には
　　　　　共通で使うコード
　　　　　共通で使うメッセージ
　　　　　共通で使うデータタイプ（クラス・構造体）
　などがあります。

５．１アクティビティに対し、
　　　２のどのフレームワークを使い（これは１プロセス１つ）
　　　３のどの入出力を、どのタイミングで使い（これは複数）
　　　４のどの共通部分モジュールなどを使う（これも複数）かを
　　決定した上で、
　　アクティビティを、基本操作＋３＋４で表現します。

---

■バグや仕様変更、設計不可能になる余地

ここでバグがはいったり、仕様変更が頻発になったり、設計不可能になるのは、
（あ）そもそも、どんなことをしても、アクティビティが基本操作には落ちない
（い）要求が間違えている（要求分析者が、間違ったことを書いている）
（う）要求の解釈を、設計者が間違えている
（え）要求から基本操作までの落とし込みを設計者が間違えた
（お）共通部分、入出力の作り方を勘違いあるいは見落としている
（か）詳細設計を書いたら、設計者とプログラマで意図が違った。

　つまり、「はじめっからできない」、「想定外」、「勘違い・誤解」です。

---

■バグや仕様変更、設計不可能を減らすには

　想定外をへらすには、想定をふやす、つまり、似たような経験があったら、それと比較するということで、これは、ナレッジベースの問題になるので、話はおおきくなってしまいます。

　しかし、「はじめっからできない」と「勘違い・誤解」を防ぐ方法は、もすこしかんたんです。

　中ぬきにすればいいのです。
　つまり、プログラマが分かる基本操作＋入出力＋ライブラリで、要求（具体的には名詞と動詞）を定義してしまう。

　たとえば、「ピッキングリストを作成する」という場合、

・リストを作成するとは、帳票を、指定された帳票形式（リスト形式という形式がある）でプリンタから紙で出力することである。

・ピッキングリストとは、ピッキングしやすい無用心な家のリストである

　。。。っていうのはうそで、

　ある出荷する箱にいれるべき商品の名前、数量、コードを書いたリスト形式で書かれた紙である（これは、会社によって、定義は違います）

　のように、特に動詞について、入出力とか、基本操作とかでぜーんぶ説明して、その用語集を作っておけば、誤解はすくなくなります。

　けど、現実的にはそんなのをやるのはたいへんなので、
　実際には、「おいおい、それって、どーやってやるんだよ（＾＾；）」とか、
（３日前の在庫数量を出力する＝持っているのは入出庫テーブルのみ。。
　おいおい、会社創業時からの入出庫をたしこむのかあ？？）

　方法があいまいで誤解や漏れを招く（キャンセル処理をする＝いろんな状況のキャンセルがあり、時と場合でやるべきことが違うため、詳しく考えないと漏れが出る）っていうことになったりします。

---

　ってことで、次回は、外部設計で作成する成果物についてです。