プロフをしたことがないウィリアムのいたずらは、情報弱者なのかも？

ふと思った。
昔は、デジタルデバイドっていうと、パソコンを使える人と使えない人の格差であり、
情報弱者とは、パソコンを使えないような高齢者をさした。

でも今の若者（１０代＆２０代前半）と、３０代以降５０代くらいまでの間にも差があって、
今の若者のインターネットっていうと、ケータイだと思う。
メールといったら、ケータイのメールのことをさすのかもしれない。。

とすると、今後は、ケータイが主流になるかも。。
もしなったとしたら、ケータイを早く打てるような今の若者と、
パソコン文化の３０代後半以降の人たちには、格差が出てしまうかも。。

現にウィリアムのいたずらは、プロフとかやったことがない。。
うーん、将来、ケータイが情報機器の中心になったら、
こーいう、プロフもやったことない、パソコン文化で育った
ウィリアムのいたずらは、情報弱者になってしまうのかもしれない。。（＞＿＜！）

要求から、プログラムまでの階層を考えないことが、開発の混乱を招いている

　っていう表題にしたけど、その具体的な混乱、つまり、アスペクト指向における横断的関心事の切り出しの問題や、デザインパターンの活用の話なんかは、月曜日からはなすこととして、今回は、その階層についての内容。

---

プログラムを考えると、普通プログラムする人が扱えるのは、

　・言語が用意する関数、クラス
　・ＯＳのＡＰＩ
　・入出力のドライバ

である。これより下（ハード寄り、ファーム寄り）は、業務アプリの範疇ではない。

　まあ、これを、「ＯＳ／言語提供モジュール」とでもいいましょうか。。

　そして、ソート、マージ、帳票出力、ＤＢ入出力、ファイル入出力といった、基本的なプログラミング可能な機能がある。これを、「入出力と、基本操作群」とよぼう。
　基本操作に関しては、ここの「Javaで基本操作」に挙げた。

　そして、本来はこの基本操作を利用して、アクティビティ図のアクティビティ、ユースケース図のユースケース、ＤＦＤのプロセスは構成されるはずである。これを、「アクティビティ層」とよぶ。

　そして、業務は要求仕様において、アクティビティないしは、プロセス（＝アクティビティ層）に分解される。

　これを図式化すると、こうなる

業務
　｜＊１
アクティビティ層（＝アクティビティ等）
　｜＊２
入出力と、基本操作群（＝外部設計の世界）
　｜＊３
ＯＳ／言語提供モジュール


　ここで、重要なのは、「基本操作群」で、これに要求が落とし込めるか（つまり、受注というのは、ソート，マージ、編集、入出力を使って表現できるか）ということになる。

　なお、図に＊１、＊２、＊３と書いたが、この変換作業（＊にあたるところ）が、開発の作業になる

＊１：　業務をアクティビティに落とし込むのが要求分析
＊２：　アクティビティを入出力と基本的な操作に落とし込むのが、外部設計
＊３：　入出力と基本的な操作をプログラミングするのが、内部設計＆プログラミング

　で、プログラミングテクニックは、主に＊３のところに関係する。
　ワーカーさんに渡すレベルとは？で書いた、”ワーカーさんに教えておく”という部分は、上記の「基本操作群」部分ということになる（昔はおそわったんだけどね）。

　自動化の場合、＊２の自動化と＊３の自動化は全然意味が違い、＊３はやりやすいけど、＊２は難しい。再利用も同じ。

---

　ってことで、月曜日から、これをもとにしたお話をしようかと思ってます。

ＤＴＰの構造を考える－その３：組版規則など。

土日シリーズ「ＤＴＰの構造を考える」。
　前前回は、「本－ページ－枠－文章、線画（絵）、イメージ」という、見た目の物理構造についてやりました。
　前回は「本－見出し・・・などなど」の論理構造というのをやりました。
　で、本などには、この２つの構造（見方）があって、論理構造と物理構造は結びついているという話です。

　ただ、これ以外に、本は情報を持っています。
　それが、組版規則などなんですけど、今日は、その話をします。

---

■本－組版構造データ

　日本語の本を出す場合、文頭に。がこないなど、禁則とよばれる規則があります。
　それと、ワープロソフトではやってないのですが、ちゃんとしたＤＴＰソフトでは、「（のように、カッコが２つ続くとき、全角ではなく、半角にしたり（ＡＳＣＩＩコードの半角ではなく、全角文字の文字送りをつめる。そもそもＤＴＰでは、半角といわず、２分（にぶん）といったが、最近は半角といわないと通じないかも　＾＾；）。。。
　などなど、いろんな規則があります。

　この規則は、本ごとにちがいます。
　句読点といったとき、　、と。をさす場合、,と.をさす場合、,と。をさす場合など、いろいろです。それにともない、記号とみなすもの、上記のような２分処理をするもの、また、アキについての処理など、本ごとに違います。

　厳密に言うと、おこしのカッコが二つ続いた場合。。。などというのは、ＤＴＰのアルゴリズムとしてコーディングされている（あるいはコーディング可能）なのですが、そもそも、おこしのカッコになにを使うのかは、本によって（横組みの本、縦組みの本）違うので、これをデータでもたないといけません。

　ＤＴＰソフトの中には、この情報を指定できるものもあります。
　（どれだけ、指定できるかは、ＤＴＰソフトによって違うと思います）

　この場合、システムでデフォルトを持っていて、本単位に変更できるのが普通だと思います。
　また、ＤＴＰソフトは、すべての組版規則に対応しているわけではありません。

　とくに、和文と欧文が入っている横書きにおいて、欧文はハイフンで区切るか分離禁止になります。ここで、ＵＲＬは分離禁止になるので（ハイフンを入れると違うＵＲＬになる）、その前後などで、文字を目いっぱい広げてしまうことがありますが、これは、和文欧文間の文字間の規定（ある一定以上広げてはいけない）に違反します。こういうことがあります。
（ちなみに、上記の場合は、本来、ＵＲＬに長体をかける（これも４０％まで）ことによって、追い込む。欧文だけで無理なら、和文も長体をかける。。。などなどの手を使うと思う）

---

■イメージの場合

　イメージの場合、組版規則のように、イメージを調整するものはあるか？というと、あります。
　それは、トランスファー関数とか、ハーフトーン関数とかのデータになってくるのですが、これは、イメージごとの問題（つまり、PhotoShopでイメージを作るときの問題）となるので、まあ、ちょっと置いておきます。

　カラーマネージメントの話は、このシリーズのあとの回で、します。

---

■ＯＬＥを貼り込まれた場合の問題

　ここで、昔はあり得なかったんだけど、WindowsのＤＴＰになって、あり得る話になったのが、ＯＬＥを貼り込んじゃう場合です。

　ＯＬＥを貼り込まれると、ＤＴＰは、こちらから制御できません（イメージと同じ）。なので、そこの物に対して組版規則は適用できないことはもちろん、品質的に満足なものを返してくれるか（じゃぎじゃぎになったり、予想していたものと違うものを返す。。なんていうことがないで、こちらの想定どおりに返してくれるか）は正直、わかりません（＾＾；）

---

次回は、本の枠組みを超えてある、ライブラリ、フォントと外字、色（ＣＭＹＫ指定、ＲＧＢ指定、特色）とカラーマネージメント、などの話になるとおもいます。