デジタルサイネージで、対象や場所を選んで配信するサービス

ここのニュース
filmoサイネージ――ネット上のクリエイターが商品映像を作成、街中に配信
http://headlines.yahoo.co.jp/hl?a=20090908-00000006-zdn_ep-sci
（以下斜体は上記サイトより引用）


インターネット関連のマーケティングを手掛けるエニグモは9月7日、デジタルサイネージ（電子看板）に特化した動画コンテンツの制作や企画の立案などを一括で提供するサービスを開始した。

　商品やサービスの動画コンテンツを専用のクリエイターが複数本作成し、商品を届けたい対象や場所を選んで配信できるのが特徴。動画コンテンツの作成に要する期間は約2カ月。価格は170万円から。

　提供するサービス名は「filmoサイネージ」。


ここまでくると、これから、
　　広告代理店と
　　不動産業、商店、デパートなどなど
がお金がなくなってくると、

　デパートとか、目立つビルとか、そーいうところに電子看板をつけて、そこに、広告代理店が宣伝を流して、ビルオーナーも、広告会社も、広告主からお金を受け取るっていうような、
（ある意味、昨日書いた、動画アフェリエイトみたいなものが）出てくるんでしょうね。。

Strutsの要素技術の基本的構造（その６ 複数ボタン 素直な方法と問題点）

Strutsの要素技術の基本的構造の話で、前回、複数ボタンの方法として、
　本などでは、LookupDispatchActionを使うのが、多いけど

（１）submitのname(property)を変えてしまい、値が入ってくるかどうかで見る
（２）javascriptを使って、Ａｃｔｉｏｎ等を切り替える
（３）LookupDispatchActionを使う

どれでも出来ると書いた。

　しかし、それ以前に、

　strutsでなければ、これは、ボタンを、あるForm内に、submitボタンでつくり、その場合、nameを一致させて、ボタンのvalueをかえることによって、処理を切り分ける。

　と書いておきながら、この方法で、Ｓｔｒｕｔｓでは、できるのかどうかということについて、書かなかった。まず、今日は、そこから。
　なお、この方法を、「素直な方法」と名づけます。

---

■素直な方法でもＵＴＦ－８なら、問題なく出来る。

　まず、この「素直な方法」でも、すべてＵＴＦ－８で扱うなら、問題なく出来る。
　すなわち、前回の問題について、表示画面であるindex.jspで

＜%@ taglib uri="http://struts.apache.org/tags-bean" prefix="bean" %＞
＜%@ taglib uri="http://struts.apache.org/tags-html" prefix="html" %＞
＜%@ taglib uri="http://struts.apache.org/tags-logic" prefix="logic" %＞
＜%@ page contentType="text/html; charset=utf-8" %＞
＜html:html＞
＜HEAD＞＜TITLE＞足し算＜/TITLE＞＜/HEAD＞
＜BODY＞
＜html:form action="/tashizan" focus="parm1"＞
＜html:text property="parm1" size="6"/＞と
＜html:text property="parm2" size="6"/＞を＜BR＞
＜html:submit property="zikko"  value="足す"/＞
＜html:submit property="zikko" value="引く"/＞
＜/html:form＞
＜/BODY＞
＜/html:html＞

(上記＜　＞は、本当は半角）
と、valueの値を変えて、Ａｃｔｉｏｎ(tashizanAction.java)のほうで、

package tashizan;
import java.io.IOException;
import java.sql.SQLException;
import javax.servlet.ServletException;
import javax.servlet.http.*;
import org.apache.struts.action.*;

public class tashizanAction extends Action {
	 public ActionForward execute(
		     ActionMapping mapping,
		     ActionForm form,
		     HttpServletRequest request,
		     HttpServletResponse response) {

	        tashizanActionForm myForm = (tashizanActionForm)form;
        	HttpSession session = request.getSession();
	        
        	String nextStep="success";	//	次画面

        	try
	        {
	        	int	i1	=	Integer.parseInt(myForm.getParm1());
	        	int	i2	=	Integer.parseInt(myForm.getParm2());
	        	int	f	=	0;
	        	
	        	String zikko = myForm.getZikko();
	        	if (zikko == null)
	        	{
		        	session.setAttribute("kekka", "処理不明");
		        	nextStep	=	"error";
	        	}
	        	else if(zikko.equals("足す"))
        		{
        			session.setAttribute("kekka", String.valueOf(i1+i2));
        		}
        		else
        		{
        			session.setAttribute("kekka", String.valueOf(i1-i2));
        		}
	        }
	        catch(Exception e)
	        {
	        	session.setAttribute("kekka", "数値を入れてください");
	        	nextStep	=	"error";
	        }
        	return (mapping.findForward(nextStep));
	 }
}

というように
　　　zikko.equals("足す")
で、どのsubmitボタンを押されたかを切り分けても、何の問題もなく動く。

---

■じゃ、何が問題か？

じゃ、何が問題かというと、

（１）ＵＴＦ－８以外だったら、これはできない
　　　ま、変換すればいいんだけどね（＾＾；）

（２）リテラルを入れているので、I18nできない。
　　　でも、国際的にばら撒かないけど・・・

（３）ボタンの処理を１つ１つ独立（１つ１Ａｃｔｉｏｎ）にしたい
　　　たとえば、再検索は、どこにでも出てくるので、このＡｃｔｉｏｎを共通にしたい
　　　ため、ボタンの処理を１つ１Ａｃｔｉｏｎにしたいとか・・

っていうときに問題になる。
このときの場合、上記の３つが考えられるという話（ただし、（３）に関しては、できないものもある）。
だから、ＵＴＦ－８でやってるなら、この問題は関係ない。
それを書き忘れておった（＾＾；）

---

ってことで、次回から、ほんとうにこの３つのケースについて。

UML等各種ダイアグラムのエラーチェック体系化（その２６：ＵＭＬ、構造化設計間の関連）

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

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、前回、ユースケース図とアクティビティ図の関連を
　やりました。

　そのとき、

より多くの情報を持っている図→その一部分を抜き出した図（つまり部分集合）の関係にあるものは、その対応関係を記述できれば、変換可能といえます。


と書きましたが、では、いままでやった図
　　・クラス図
　　・ＥＲ図
　　・アクティビティ図
　　・ユースケース図
　　・ＤＦＤ
さらにそれと
　　・プログラム
は、その関係で見ると、どんな位置づけになるのかを見てみたいと思います。

---

■アクティビティ図とユースケース、ＤＦＤの関係
　昨日、アクティビティ図から、ユースケース図が導けると書きました。
　で、今度はアクティビティ図からＤＦＤを導くことを考えます。

ＤＦＤは、ここにあるように

　プロセステーブル（プロセスＩＤ，プロセス名）
　データ発生・吸収テーブル（発生吸収ＩＤ,元名）
　データストアテーブル（データストアＩＤ，データストア名）
　データフロー（データフローＩＤ、元データＩＤ，先データＩＤ、フロー情報内容）

なので、アクティビティ図の

　　レーンテーブル
　　エッジテーブル
　　エッジコネクタテーブル
　　動作ノード（アクション）テーブル
　　オブジェクトノードテーブル
　　制御ノードテーブル＊
　　コメントテーブル

　と比べると、まず、動作ノード（アクション）テーブルがＤＦＤのプロセステーブルに対応するというのはまずいいとして、ＤＦＤのデータ発生・吸収とデータストアが、オブジェクト（ノード）にあたると思います。
　そうすると、これらやプロセスを接続するＤＦＤのデータフローは、エッジまたはエッジコネクタになってきます。

　ここで、ＤＦＤのデータ発生・吸収とデータストアを、アクティビティ図で区別できるかということですが、アクティビティ図の場合、データは、オブジェクトノードということで、データ発生・吸収（システム的には画面や帳票になる）とデータストア（システム的にはファイル・ＤＢ等）を明確に分けていません。なので、この辺の対応ははっきり出来ないと思います。

　ここからわかるように、ＤＦＤには、アクティビティ図の制御ノードに関するものがありません。それもそのはずで、ＤＦＤはデータの流れを書いてるだけで、どういうプロセスが、どう動くかというものを記述したものではないです。


　まとめると、ＤＦＤも、ユースケースもアクティビティ図と違い、制御情報は、入っていない。一方、アクティビティ図には、オブジェクトの種類（メディア＝帳票、画面、ＤＢなど）は書いていない。

---

■アクティビティ図、ＤＦＤとＥＲ図の関係
　ＥＲ図は、データを表現したものなので、データ記述のない、ユースケース図については、ここではおいておきます。

　アクティビティ図において、データはオブジェクトノード、
　ＤＦＤは、データ発生・吸収とデータストアで

　表現されています。しかし、ここには、項目内容（アトリビュート）やデータ関連については書かれていません。そりゃーそうです。どちらも、データの処理、流れを書いているので、とまったデータを記述するものじゃないです。野球（動く球を打つ）とゴルフ（止まった球を打つ）ぐらいちがいます。なんのこっちゃ（＾＾；）

　ただし、これらと、ＥＲ図のエンティティ間に関連を持たせれば
　つまり、

　アクティビティ図のオブジェクトノード（の一部）とＥＲ図のエンティティ、
　ＤＦＤのデータストアとＥＲ図のエンティティ

を一致させて、詳細化を記述するということはできます（ＤＦＤにおいては、これを使ってエラーチェックもできるかも・・）。

　まとめると、
　ＥＲ図のエンティティは、アクティビティ図のオブジェクトノード（の一部）、ＤＦＤのデータストアを詳細化している。

---

■クラス図と、そのほかの図の関係

　オブジェクトは、事象を表現したものであり、オブジェクトを抽象化したのがクラスで、クラスを図にしたのがクラス図・・・だとすると、クラス図は、事象を表現していることになります。
　事象とは、事物と出来事を指すと、ここでは考えます（数学だと、後者だけなのかしら）。
　で、事物は、モノですので、データになります。
　出来事は、プロセスになります。

　ってことは、クラス図では、データもプロセスもなんでも表現できるということになります。

　となると、

　　ユースケース図のプロセスも、クラス
　　ＥＲ図のエンティティもクラス
　　ＤＦＤのプロセスもクラス
　　　　　：

　つまり、ノードになるものは、全部クラス
　で表現でき、その間をエッジでつなぐというかんじで、
　全部クラス図で表現できることになります。

　ところが、事象の出来事は、たしかにクラスになるのですが、同時に、メソッドとすることもできます（受注クラスというのも考えられるし、あるお店クラスで受注するというメソッドを考えることも出来る）
　となると、プロセスに関する、

　　　ＤＦＤのプロセス
　　　アクティビティ図の動作ノード（アクション）＝アクティビティ
　　　ユースケース図のユースケース

　はクラスにもなりえるし、メソッドにもなりえます。
　これは、どちらになるかは、決められません。

　つまり、クラス図は、すべてのダイアグラムをクラス図にすることは可能なんだけど、
　どのようなダイアグラムにするかは決められないということになります。

---

■ダイアグラムとプログラムの関係

　実はクラス図の上記の話はある意味当たり前で、
　クラス図から、プログラムのクラスを書くことが出来るので、言い換えると

　すべてのダイアグラムから、プログラムのクラスを書こうと思えば書けるけど、
　どうやって書いたらいいかは決められないということになります。

　そりゃそうです。もし、決まっていたら、自動変換しておしまいです。

　では、ここでもし、

　どうやって書いたらいいかを決めてしまったら、ダイアグラムからプログラムは書けるのか？

という問題を考えてみたいと思います。

---

■ＵＭＬ，構造化設計の図でプログラムは書けるか？

　プログラムを書くためには、プログラムを書くための必要な情報がないといけません。

　プログラムを書く必要な情報は、ここに書いたように

　　・データ（メディア、型、値＝変数と定数）
　　・プロセス（入力データ、出力データ、起動順序・条件）

にあるように、データの型とメディア、プロセスの起動順序・条件がわからないといけません。
　ＤＦＤ、ユースケース図、クラス図は、プロセスの起動順序・条件がわかりません。
　なのでここからプログラムはかけません。
　ＥＲ図は、プロセスについて、書いていないのでかけません。

　のこり、アクティビティ図ですが、たしかに、データは、オブジェクトノードにあるのですが、データの型、つまり、帳票なのか、ＤＢなのかはわかりませんし、データの値もわかりません。
　データの値に関しては、アクティビティ図とＥＲ図が結びつけば、ＤＢに関してはわかりますが、ＥＲ図では一般に書かない、ＪＯＩＮしてできる帳票などについての、項目並びとかは、ＥＲ図だけではわからないので（でもプログラムをつくるのには必要）、ここからつくることはできません。

　じゃあ、アクティビティ図がＥＲ図、画面、帳票と結びつけば・・・

　っていう話になってくると思いますが、それについては、もう、話が長くなりすぎたので、次回です。

透明なケータイの中に雨や雪の、Window Phone

　Windows Phoneではないよ、
　Window Phone！！

これ
Window Phone gives you a look at the weather outside
http://www.gearlive.com/news/article/q309-window-phone-weather/

さっきSolive Asiaでやってたんだけど、すげー！！

透明ななかに、雨や雪っぽいデザイン！
かっちょいー

けど、これ、電話になるのか？？（＾＾；）