トーストを焦がして印字するプリンタ、イベントの貸し出し用にいいかも？

今川焼きでも、たこ焼きでも、お好み焼きでも、
なんでも、つかえそうですね！
いろんなデザインで。。。

観光地のお土産や、イベントによさそう！！

ここのＧＩＧＡＺＩＮＥの記事
トーストを焦がして印字するプリンタ
http://gigazine.net/index.php?/news/comments/20070426_toast_printer/
に（以下斜体は上記記事より引用）


高温の熱風を出すホットエアガンを使ってトーストに文字や絵をプリントしています。一定の柄だけプリントできるトースターと違って様々な図を色々な素材にプリントできるようです。


上記の記事では、きれいなヒマワリをプリント？したのがでてますよ！！

複雑なキャラクターとか、
即席縁日で、図柄をちょくちょく書き換えたい

とかいうときによさそう。。
こういうのを貸し出す会社とかできて、イベントのときだけに
登場するとか。。（そのイベント用のプリントで）

バーコードをケータイで撮影して、価格.comで比較っていうの。。

　前田アナのトレンドたまごでやっていた
価格バーコードサーチ
http://www.tv-tokyo.co.jp/wbs/toretama/070425.html
どういうのかというと（以下斜体は上記サイトより引用）


インターネットで価格情報を提供する価格.comの携帯電話版サービス。携帯のカメラ機能で、店頭の商品の価格表示についたバーコードを撮影すると、最安値情報や口コミ情報が得られる。


これ、「どこよりも安くします」っていうお店の場合いいけど、
（もし、高ければ、その価格.comの結果を店員に見せて、交渉できるので）

そーじゃないお店の場合、
ケータイで、とった後に。。
「あ、このお店高いや。。。」
っていって、出て行かれてしまうわけでしょ（＾＾；）

これ、お店の人、ケータイを出したとたんに、警戒されたりして。。
「お客様、店内でのケータイの利用は禁止されております！」
とかいって、バーコードを撮影されるのを阻止するとか。。（＾＾；）

むしろ、「どこよりも安くします」っていうようなお店の場合、
価格.comの、その商品のサイトを開いてＰＲしたほうが、効果的？
「ほら、どこよりも安いでしょ！」ってわかるので。。

富士通の汎用ＯＳとＬｉｎｕｘ並行稼動、通信はCORBAとＡＩＭをあわせるの？どーなの？？

ここのスラッシュドットニュース
OSⅣ/XSPとLinux/Windowsが同居するIAサーバー
http://slashdot.jp/hardware/07/04/29/0418205.shtml

ちょっとまって。。。
ＯＳはたしかに同時にうごかせるかもしれないけど、そのマシンの通信はどうなるの？
ＴＣＰ／ＩＰとＨＤＬＣを同時にやるって無理そうだよねえ。。

そーすると、ＴＣＰ／ＩＰ共用で、ＩＰアドレスは１つだよねえ。。
そーすると、ＩＰアドレス１つで、２つの通信を切り分ける？
VTAM-G TISPを使うの？
でも、同期とらないといけないやつは、まずいよねえ。。

そーすると、もう一段奥にいって、ＸＳＰのＡＩＭの部分を、INTERSTAGE/AIMApplicationDirectorをつかって、ＣＯＲＢＡにあわせて、ＣＯＲＢＡベースでぜんぶやるの？

　これだと、画面部分、帳票定義部分は、Interstageのフォームコーディネーター（ごめん、英語のつづり忘れた）の形式におとせるか、じゃなかったら、HTML(XHTML）に落とせて、PFキーとかのアクションをAJAXにするか、JAVAで画面帳票を自動生成するとか。。
　なんかやるってこと？

　まあ、画面部分、帳票定義部分はいったん、ＰＳドキュメントにすれば、そこから自動生成することは可能だろうけどお。。

　うーん、なぞじゃあ（＾＾；）

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

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

　今までで、三層スキーマ構造（概念スキーマ、内部スキーマ、外部スキーマ）の外部スキーマ、内部スキーマをやってきました。

　今日から外部スキーマです。

---

■外部スキーマとは

　外部スキーマは、データベースをプログラムからみたカタチになります。
　実際にデータベースをプログラムから操作するわけですが、その際、実際にあるテーブルとは、ちがったカタチで扱いたいわけです。

　というのも、もともとのプログラムであつかうデータのカタチを、概念スキーマの正規化でばらばらにされてしまったので、それを、プログラムで扱うカタチに戻したいわけです。
　また、内部スキーマで、インデックスと、データに分けましたけど、そんなの意識しないで、検索をかけたいわけです。

　そこで、プログラムから扱いやすいように、テーブルを集めて、必要な情報だけまとめたいわけです。

---

■ビューとデータベース操作言語

　そこで、テーブルをいくつかまとめて、プログラムで使いやすいようにしたものが、ビューになります。
　で、プログラムで操作するには、操作言語というのが必要になります。
　このデータベース操作言語がＳＱＬになります。

　なお、ＳＱＬでは、検索、挿入、更新、削除などの操作ができますが、この検索selectの操作で、ビューと同じようにテーブルの必要な部分を取得することが出来ます。
　なので、ビューを作らなくてもＳｅｌｅｃｔだけで間に合ってしまうっていうこともよくあります。

---

■ＳＱＬとＪＤＢＣ，ＯＤＢＣ

　ＳＱＬでデータベースは操作できるのですが、それは、データベースが提供しているツールから操作できるというものであり、プログラムからＳＱＬを発行するには、ちょっとその間に必要なものがあります。

　データベースとプログラムの間に、Ｊａｖａであれば、ＪＤＢＣ、ＶＣ＋＋などでは、ＯＤＢＣと呼ばれるものをいれ、たとえば、Ｊａｖａであれば、ＪＤＢＣのクラスを生成し、指定の処理をして、そこから、ＳＱＬ文をデータベースに送り、処理をするという流れになります。

---

ということで、次回はまず、ＳＱＬについてです。

みんなのひとりごとサイト、twitterとそのＷｅｂＡＰＩ

みんなの独り言？をどんどん載せていくサイト
twitterってのがあるみたい。

ここ　http://twitter.com/

リドローすると、たいてい毎回変わってく。
日本人だけでないので、英語のメッセージもおおいけど、
日本人のひとも多いみたいで、けっこう日本語の独り言もある

ふーん。。
でも、すごいのは、こーいう独り言の世界にまで、
アダルト業者？（たぶん）が、侵食していることだ。。

ちなみに、そのＡＰＩは、
http://groups.google.com/group/twitter-development-talk/web/api-documentation
にあるみたい。
たとえば、
http://twitter.com/statuses/public_timeline.xml
で、最新のをＸＭＬ形式で入手できるみたい

ＤＴＰの構造を考える－その５：フォント その１

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

---

■フォントとフォントメトリクス

　フォントは、文字の形であって、それをドット（ビットマップ）で表現するビットマップフォントと、線で表現するベクトルフォントがあり、線で表現するものの中は、ベジエを使うＰＳのフォントと、スプライン曲線で表現するＴｒｕｅＴｙｐｅのフォントがあります。

　ってことはいいんですけど、このような、ドットや線で、文字のカタチ（グリフ）がわかっただけで、文字が表示できるかというと。。。そうでもないんです。等幅なら、問題ないんですけど。

　プロポーショナルフォントの場合、文字送り幅が違ってくるので、そのような情報を取得しないといけません。このようなフォントをどこに置くか？という情報が、フォントメトリクスというのですが、このフォントのグリフとフォントメトリクスがそろうと、文字を置いて表示できます（厳密には、欧文文字の場合、ペアカーニングっていうのもあるんだけどね。。）

　ただ、このフォントメトリクスの扱い、欧文と和文で違うんです。。。

　ていうまえに、欧文フォントと和文フォントの話をしないといけませんね。

---

■欧文フォントと和文フォント

　フォントには、欧文フォントと和文フォントがあります（あと記号類をわける場合もあるが）。
　欧文フォントはアルファベットが入ってます。
　和文フォントは、ひらがなカタカナ漢字すべて入っているフォントと、
　かな書体（かなフォント）という、かな文字だけのフォントがあります。
　　例えば、おニャン子クラブの永田ルリ子さんの直筆書体、ルリールは、かな書体です。
　（ただし、写研フォントですけど）。まーねー、永田ルリ子さんが、漢字部分まで書くってことは（＾＾；）

　で、実際には、欧文のところは、欧文フォント、和文のところは和文フォントを使うのが普通だと思います（和文フォントにも欧文が入っては、いるが）
　で、この場合、欧文フォントと和文フォントで、よく使われる組み合わせがあります。ＤＴＰソフトでは、その組み合わせになるようになっている（ただし、変更も可能）と思うけど。。どーかな（＾＾；）

---

■欧文フォントと和文フォントの位置あわせ

　で、欧文フォントと和文フォントでは、位置の合わせ方が違います。
　欧文フォントはベースラインというラインが合って、それに対して、どこに持ってくるかというようになっています。
　和文フォントは、ベースラインという概念はないです（プロポーションで幅はちがうのですが、字母の高さは、標準では同じです）

　そこで、和文の字母のどの位置に、欧文のベースラインを持ってくるかっていう話なんですけど、これは標準は決まっていて、微調整できるものもある気がした（ベースラインシフトという）。。
　

---

■フォントファミリ

　フォントは、文字を大きくするとき、単純に拡大すれば、よいわけではないです。
　そうすると、貧弱にみえる（っていうけど、そんなにかんじないけどなあ　＾＾；）ので、太字用のフォントを作ったり、細字用のフォントを作ったりします。

たとえば、MS-Wordなどで、ちょっと文字のアクセントを変えたいときに使う、
ＨＧ創英角ゴシックＵＢ、

この創英角ゴシック書体には、ＵＢ（うるとらぼーるど＝ちょー太い）以外にも、もっとあります
ここ
http://ohkadesign.cool.ne.jp/wabunfont/souei/souei.html
にのってるのだと、
　創英角ゴシック体 L
　創英角ゴシック体 M
　創英角ゴシック体 B
　創英角ゴシック体 EB
　創英角ゴシック体 UB
とあります。

このとき、それぞれがフォントなのですが、「創英角ゴシック」という意味ではみんな同じなので、「創英角ゴシック」の部分を、フォントファミリといいます。
　ただし、ふつう、フォントファミリは、同じ作者が手がけるものなのですが（でないとびみょーにちがってしまうので）、創英角ゴシックは、２人の作者がいるので「それで、ほんとにファミリーなのかよ！」っていわれると（＾＾；）。。（詳しくは、上記リンク先参照）

---

　なんか、肝心なことを書こうと思う前に、こんなに長くなってしまったので、
　今回はここで切って、肝心なことは、次回のこのシリーズでかきます。

ＭｙＳＱＬのＣＥＯ，ＩＰＯ計画やＯｒａｃｌｅがＭｙＳＱＬの買収を試みたことを語る。

　ここにも書かれているけど、
　ＣＮＥＴの以下の記事
MySQLのミコスCEO、ついにIPO計画を語る
http://japan.cnet.com/news/biz/story/0,2000056020,20347926,00.htm
によるとアメリカのＭｙＳＱＬが、株式公開を目指しているそうな。

まあ、それは、「へー」で終わってしまう話なんだけど。。

その先の２ページ目
http://japan.cnet.com/news/biz/story/0,2000056020,20347926-2,00.htm
によると（以下斜体は上記サイトより引用）


　Mickos氏は2006年、OracleがMySQLの買収を試みたことを明らかにした。


おお、やっぱり狙ってきましたか（－＿－；）

掲示板の中傷を放置したってことで、管理者が書類送検

ここのニュース
＜ネット掲示板＞中傷書き込み放置の管理人を書類送検　大阪
http://headlines.yahoo.co.jp/hl?a=20070427-00000053-mai-soci
によると（以下斜体は上記サイトより引用）


　インターネットの掲示板に書き込まれた女子中学生（１３）に対する実名中傷を放置したとして、大阪府警南署は２７日、掲示板を管理する大阪市内の材木卸会社役員の男（２６）を名誉棄損ほう助の疑いで書類送検したと発表した。書き込んだのは、小学校時代に同じ塾に通っていた別の私立中学校の女子生徒（１３）で、同署はこの生徒を名誉棄損の非行事実で児童相談所に通告した。


掲示板の管理者は、忙しくても放置して置いちゃダメってことっすね。。
たいへんそうだ。。

って、それって、ブログの掲示板もかなあ。。
ウィリアムのいたずらの本家のブログに掲示板が、たしか？あって、
放置しっぱなし。。
つーか、見てないんだけど。。（＾＾；）

Webサービスとデータマイニング、データウエアハウス

　昔、データマイニングとか言うので、顧客と売り上げの関係とかをいろいろ掛け合わせて分析するのがはやった。

　そのとき、たとえば天候と売れ筋商品との関係なんていうのを知りたい場合、天気といった、会社とは関係ない情報まで、データウエアハウスでもたなきゃいけなくて。。

　でも、最近はWebAPIがあるので、今後、それらが発達してくれば、自社でしか収集できない商品情報とかだけ持っていればいいようになるかもしれない。
　天気なんかは、そーいうAPIを誰かが提供してくれるかもしれない。
　提供してくれたら、別に自分たちのサーバーでもつ必要はないし。。

　地域の行事と売れ筋なども、お弁当などでは重要だけど、日付と地域の行事を提供するサービスがでてくれば、分析対象になりそう（ただ、そんなサービスはでないかも。。）
　
　それと、データウエアハウスではないが、商圏などは、自社に顧客の住所（メンバーズカードなどから）と、グーグルマップがあると、あとは、住所から緯度経度への変換サービスがあれば、おおよそ図示できそうだ。

　なんて、ちょっとおもった。
　単なる与太話＆メモ

高出力電子タグシステムの一部が心臓ペースメーカーに影響

スラッシュドットの以下の記事
高出力電子タグシステムの一部が心臓ペースメーカーに影響
http://slashdot.jp/hardware/07/04/26/0431232.shtml
によると（以下上記サイトの記事を、４月２６日１８：２８分現在、”原文のまま”引用－もう直ってるかも　＾＾；）


総務省は、電子タグシステムのうち高出力型の一部機種が心臓ペースメーカーに影響することが分かったと発表したという。影響が確認されたのは利用届出が必要なUHF帯(950GHz)を使う据え置き型の電子タグシステムで、現在倉庫などで約200システムが使われているという。


あ、そーっかあ、確かに電子タグ、ペースメーカーだと危ないかも。。
って、そこがポイントなんだろうけど、
ウィリアムのいたずら、違うところに目が行ってしまった。。（＾＾；）

(950GHz)

って、９５０”ぎが”ヘルツっすがあ（＠＿＠！）
そんな高い周波数、使ってるんですかあ？？
そこって、赤外線とか光じゃなかったっけ？？

と思って、元ネタ
電子タグ：ペースメーカーに一部機種が悪影響
http://www.mainichi-msn.co.jp/science/medical/news/20070425k0000m040097000c.html

みたら、やっぱ、メガヘルツでした（＾＾；）

でも、これって、わざと。。強烈な皮肉？？
つまり、光を発光するとか、反射するタイプのタグ（＝って、それってバーコードだけど）っていうものを考えたら、心臓のペースメーカーにも影響ないのに。。って。。
洋服なんかの場合、電子タグより今までどおり、バーコードのほうが安全？？

ただ、９５０GHzっていったら、いわゆるテラヘルツ波なわけで、たしかにテラヘルツ波のバーコード応用って。。うーん、高そうだぞ（＾＾；）

開発の初めから順番に書いていってみる その３６：詳細設計（３）詳細設計書

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

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

　外部設計までは、
　ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm
　にまとめてあります。

　現在から、内部詳細設計で、前回は成果物を説明しました。今回はそのうち、詳細設計書です。

---

■詳細設計書の構成

　詳細設計書の構成は、

　　１．外部設計書との関係を示す表紙の部分
　　２．ひたすらプログラム内部を書く

　にわかれます。
　１の部分は、JavaDocの内容と同じで、そのプログラム名と、関数、クラス、メソッドの書式、概要説明が入ります。

　２の部分は、処理内容をことばで書きます。
こんなかんじ

１．トランザクションファイルから１件データを読んでくる
２．マスターファイルから１件データを読んでくる
３．トランザクションファイルのデータがなくなるまで、以下の処理を繰り返す

３－１．トランザクションファイルのキー＞マスターファイルのキーのとき
３－１－１．マスターファイルのレコードを出力する
３－１－２．マスターファイルからレコードを１件読む
３－１－３．３へ戻る

３－２．トランザクションファイルのキー＝マスターファイルのキーのとき
３－２－１．トランザクションのレコードを出力する
３－２－２．マスターファイルからレコードを１件読む
３－２－３．トランザクションのレコードを１件読む
３－２－４．３へ戻る

３－３．トランザクションファイルのキー＜マスターファイルのキーのとき
３－３－１．トランザクションファイルのレコードを出力する
３－３－２．トランザクションのレコードを１件読む
３－３－３．３へ戻る

４．マスターファイルのレコードが残っていたら、全部出力する

５．トランザクション、マスタクローズ

　で、そーでない場合、決定表による書き方というのがあります。

---

■決定表による書き方

　ここにあるようなやつです。

http://club.pep.ne.jp/~yama.ok/FE/H14AutamnFEAM/H14A_q14.htm

　上に条件が書いてあって、下にアクションが書いてあって、それが表になっているもの。

　で、これ、プログラムの仕方によっては、えらい汚くなり、バグの宝庫になってしまいます。逆にきれいに組むと、すっごい拡張性が高くなります。

　ジョブチケットっぽく組むといいんですけどね。
　これについては、また今度、別の機会に書きます。

---

■インターフェース記述とサンプルソース

　で、中の部分はあんまり必要ないんだけど、表紙のJavaDocのようなものは、そのソースを使う人以外でも必要です。
　そこで、Javaでない場合でも、インターフェース記述（関数定義書）として、イロイロ書きます。

　で、それだけなら外部設計の話なのですが、実際には、それだけでは、うまくくんでくれません。
　サンプルコードが必要になってきます。
　そこで、詳細設計の２のところのかわりに、
　呼び出し方やサンプルコードをつけたものを、インターフェース記述として、公開することがあります。

---

　てなかんじの話で、次回は残りのコーディング規約について。

Web2.0というバズワードが問題なのではなく、WebAPIで提供する中身が重要。。

えー、まとめますと、

「Web2.0というバズワードが問題なのではなく、
　WebAPIで提供する中身が重要である。

　WebAPIで提供するサービスがゴミだったら、
　それを集めて、いくらマッシュアップしても、
　ゴミにしかならない（GIGO）」

ってことですかね。。
（ある人から聞いた話をまとめてみた。。）

”ブログ界は「不快」で「危険」なコンテンツだらけ”なんだってさ（＾＾；）

ここのスラッシュドットニュース
ブログ界は「不快」で「危険」なコンテンツだらけ
http://slashdot.jp/security/07/04/25/0954234.shtml
によると（以下斜体は上記サイトより引用）


Ars Technicaの記事より。ウェブセキュリティ企業のScanSafeが最近発表したリポートによると、企業顧客からの70億以上ものウェブリクエストを分析した結果、80パーセント近くのブログには「不快な」コンテンツが含まれていることが分かった。ここで言う不快(offensive)とは、下品な言葉遣いからわいせつ画像まで千差万別のようだ。また、同リポートによると、ブログの約6%は何らかの種類のマルウェアで汚染されていて危険だと言う。


だそうな・・・

ほー、

ブログが危険っていうのは、あるのかも。。？？

でも不快のほうは、不快の定義によっては、
どーなんでしょー

もし、ブログで著作権違反をしているものも、企業から見たら不快っていうことで、定義したら。。もっと不快が上がる？？

横断的関心事の切り出しと自動生成

なんとなーくシリーズ化してしまった、要求から、プログラムまでの階層を考えないことが、開発の混乱を招いているの話。
　で、書く、書くと書きながら、書いていなかった、


アスペクト指向における横断的関心事の切り出しの問題


について。。

　世間話の与太話なので、まじめに反論とかしないでね（＾＾；）
　ギャグの一種として聞いてください
（ただ、途中から出てくる自動生成の話は、そこまで進んでいて実際に使っているけど、今回は書かないです）

---

■featureと関心事と、階層について

　ここで書いたように、

業務
　｜
アクティビティ層（＝アクティビティ等）
　｜　ライブラリと入出力
基本操作群
　｜
ＯＳ／言語提供モジュール

って考えられます。
で、業務から、アクティビティに落とすのが、要求分析になります。

横断的関心事: Crosscutting Concern
http://netail.net/aosdwiki/index.php?%B2%A3%C3%C7%C5%AA%B4%D8%BF%B4%BB%F6

で書いてある話でいうと、featureは、要求仕様層でいう、アクティビティになると思います。

　したがって、関心事というと、入出力それぞれも、関心事になるし、ライブラリ化する機能も関心事になったりすると言うことになると思います。
　つまり、「ライブラリと入出力」、「基本操作群」のそれぞれが、関心事たりえるということになり、上の図にあるように、それらは階層化されています。

---

■横断的関心事とライブラリと雛形について

　横断的関心事とは（以下斜体は上記横断的関心事より引用


相互に関連しあっていて，何か機能変更などがあった場合に同時に変更されるものは，できるだけ１つのモジュールにまとめておきたい」という要求がありますが，何らかの理由でモジュールとしてまとめられない関心事のことを横断的関心事と呼んでいます．従来，ソフトウェアの機能に基づいてモジュール分割を行うことが多いため，性能向上のためのコードや，ログ取得などの付加的な処理は横断的関心事になりやすいといわれています（ソフトウェアファクトリーでは，機能特性に対して運用特性という表現も使われています）．


とあります。
たしかに、コーディング最中に、そーいう部分はちょくちょくある。
あるんですけど。。。

横断的関心事の話って、たいていその後、アスペクト指向と結びつき。。
で、たいてい、こんな例（ログの例が、なぜか多い）がでてる。。


ここでは、あなたが大規模なソフトウェア・システムを保守する立場にあると仮定しよう。このシステムは、所属する組織の給与計算と人事の機能を管理する。ここで、従業員データに対する変更をすべてログに記録するように経営者側から要求されたとしたらどうするか。これには、減給、昇給、残業手当など、給与計算に関する変更が含まれる。また、従業員の肩書きや個人データなど、従業員のあらゆる情報に関するあらゆる変更が含まれる。この要求を満たすには、どうしたらよいだろうか。


でも、こうかかれると。。。

いやー、入出力のところは、すべて、自動生成してるから、従業員データアクセスの雛形を書き換えて、もう一度従業員データを自動生成すると。。全部ロギングできる。。。けどお（＾＾；）

終了。。。

って、思ってしまいませんか。。？

---

■いやー、あとから結合点を抜き出すのって、たいへんじゃない？

　つまり、横断的関心事になるようなところは、たいてい雛形がつくれて、雛形があるところは、自動生成している（現実的に、コーディングするような人月数は、もらえないので）から。。。自動生成の雛形を修正するだけでOK、

　一方、当初からまったく予定しないような横断的関心事は、自分１人でコーディングするなら差は出ないけど、そうでない場合、人によってかき方が違うので、結合点が必ずしも見つかるとは限らない。。気がするんですけど。。

---

■具体例で。。

　具体的に、さっきの例だと（以下斜体は上記のこんな例より引用）

　AspectJでは、結合点をポイントカット（pointcut）としてグループ化することによって、結合点を定義する（AspectJの構文は豊富であり、ここではそのすべてについては説明しない）。まず初めに、2つのポイントカットを定義する。1つはEmployeeクラス内の結合点をグループ化するためのものであり、もう1つはIEmployeeFinanceコンポーネント内の結合点をグループ化するためのものである。これらを定義するコードは次のようになる。

pointcut employeeUpdates(Employee e):
call(public void Employee.update*Info()) && target(e);

pointcut employeeFinanceUpdates(Employee e) :
call(public void update*Info(Employee)) && args(e);

　employeeUpdatesという名前の最初のポイントカットは、updateという文字列で始まり、Infoという文字列で終わる、引数を持たないEmployeeオブジェクトのメソッドを呼び出しているすべての結合点を表している。また、このポイントカットは、target指定子によって、Employeeクラスで定義されたメソッドを明確に指定している。2番目のポイントカットである


ってあるけど、自由に書かせると、「updateという文字列で始まり、Infoという文字列で終わる」ように、更新をみんな書いてくれるかというと。。びみょーだし（こー言う決まりを守らない変なやついるんだよ、俺か　＾＾；）

　逆に、コーディング規約で、「こう書きましょう！：っていう風に決まっているなら、雛形を書いて、自動生成をかけてしまう（この辺の話については、別の機会で、自動生成についてまとめて書くので、そこで触れます）。

　なので、雛形プログラムを書き換え、たとえば、従業員アクセスだけは、書き換えた雛形を使い、それ以外は元の雛形をつかうとすると。。。

　簡単にできてしまう。。

---

■雛形とライブラリ。。。

　雛形で、入出力自動生成の場合、

　　パフォーマンスが出ないときにSQL全部を書き換えたり、
　　SQLインジェクション対策みたいなのをする
　　エラーログを全部にいったん入れてみたい

　なんていう対応が、まさに横断的関心事っぽくって、こーいうのの場合、べつにアスペクト指向のツールを使わなくても、いつもの自動生成の雛形を書き換えるだけでできてしまう。

　ライブラリや基本操作を使ってる場合も、ライブラリや基本操作の関数、メソッドを書き換えれば、横断的関心事っぽいことに対応できるけど、もともと、そーいうライブラリの話を除いたものが、横断的関心事？？

　逆に、自動生成でなくて、横断的関心事のところを切り出そうとしても、けっこうみんな、いいかげんにかいちゃうからなあ。。切り出せるかなあ？？（だいたいは間違いなく切り出せる。すべてを切り出せるか？たとえば、上記の例だと、本当に、「updateという文字列で始まり、Infoという文字列で終わる」以外の関数が、従業員データをアクセスしていないか？

---

　なーんておもったりもします。。

　与太話です。まじめに反論とかしないでね（＾＾；）
　（って、コメントもトラックバックも受け付けてないのでできないけど　＾＾；）

　次回のこのシリーズは、デザインパターンの話。

開発の初めから順番に書いていってみる その３５：詳細設計（２）成果物

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

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

　外部設計までは、
　ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm
　にまとめてあります。

　前回から、内部詳細設計で、前回は説明でした。今回は成果物です。

---

■詳細設計の成果物

　といいましても、詳細設計の場合、詳細設計書がある。。
　他には、コーディング規約とか、プログラムの命名規約も、成果物？といえば成果物？？

　コードの定義なんかも、外部設計というより、ここっていうこともあるけど。。
　でも、基本的には、詳細設計書ですねえ。。

---

■詳細設計書と自動生成

　で、詳細設計書は自動生成されることがあります。
　１つは、プログラムから自動生成されるケース
　もうひとつは、外部設計書から、詳細設計、プログラムが自動生成されるケース。

　前者のほうは、手順が逆なので、ドキュメント生成のための手段というかんじ。。
　後者のほうも、ドキュメント生成のための手段ではあるけど、これは、手順的には合っていて、手順を自動化しているっていうかんじ。

---

■JavaDoc

　なお、最近の風潮として、詳細設計を詳しく書かず、JavaDocで済ませるっていうケースも多いですね。

　この場合、とりあえず、外側だけ作っておいて、JavaDocを生成し、関連する人たちに配って、後で中身を書くという話もある。。。

---

■コーディング規約とログ、assertなど。。

　一方、コーディング規約についてですけど、まあ、これは本来外部設計のフレームワークに関することなわけなんで、外部設計のドキュメントといえるかもしれません。
　すくなくとも、プログラムに入る前までには決まっていないといけませんが、そこに書かれる内容としては、

・命名規約（これは別にあるかも。。）
・コメントの書き方
・ログのとりかた
・デバッグ用になんかやるときの話（assert、コンパイルオプションなど）
・ロック・トランザクション処理の話
・コンパイル上で、なにかあれば。。
・バージョンの切り分けなどで、何かしていれば。。
・パターン上の注意点
・共通エラー／例外処理・メッセージ処理

などなどです。

---

■富士通の公開しているフレームワークでは。。

で、いつもどおり、富士通の公開しているフレームワーク
標準化規約
1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
で、詳細設計の成果物をみてみます。

PS工程というところがそれにあたります。
ここでは、

　　　　PS01 Webハンドラロジック定義
　　　　PS02 CBSハンドラロジック定義
　　　　PS03 バッチロジック定義

　となっています。ロジック定義とは、一般の詳細設計の内容です。
　で、これは、利用するフレームワークというかパターンというかによって、詳細設計書をわけているので、３種類になっています。
　このように、フレームワークの違いや形式がちょっと違う部分があった場合は、書きやすいように詳細設計をかえるのが、やりやすいですし、自動生成をする場合でも、しやすいと思います。

---

■ということは、言語によって仕様書は変わるということ

ということは、言語によって仕様書は変わるってことです。
COBOLとJavaを一緒の仕様書では。。かきにくいですよお（＾＾）

---

といっても、詳細設計書の中身については、書いていませんね。
次回、これについて書きます。