astah*を使って、ICONIX風一気通貫システム開発 その１１（終）：コントローラー

　「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定で、

（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す


　前回、（９）書いて、のこり１個「（１０）コントローラーを書き直す」なので、
今回、これを書いて、このシリーズをおわりにしてしまいましょう。

---

■概要と位置づけ

　（８）により、画面部分を書きました。
　（９）により、エンティティ部分を書きました。

　画面はViewであり、このViewは、さかのぼるとユースケースと結びついています。
　でも、あるユースケースにおいて、利用するエンティティはさまざまです。
　また、違うユースケース間で、同じエンティティを使う場合もあります。

　つまり、ユースケースとエンティティ間には、ミスマッチがあります。
　これを解決するのがコントローラーで、

　コントローラーは、View（＝エンティティ）のデータを受け取って、エンティティやビジネスモデルを操作して、
　その結果を受け取って、ビューに値を返します。

---

■結局

　Viewとエンティティ、ないしはビジネスモデルを呼び出す部分をコーディングすることになります。
　Strutsだと、Action部分を作ることです。

　ただ、Actionの実装において、ビジネスモデルをどこまでアクションに入れるか、入れないか？
　の問題があります。Actionは、値の引き渡しだけで、ロジックはすべて、ビジネスモデルにいれてしまうか、
いや、多少の計算は、Actionでやってもよくね？と考えるか・・・

　このへんは、現場の偉い人の考え方になってきます。

---

　ってことで、一通り開発の流れを書きました。


　このシリーズ、これにて、おしまい。

年賀状で縦中横をやるとき－Word２００７で

　年賀状を書くとき（って、今書いてんのかよ、とツッコミがありそうだが）
　住所を、縦書きで、書くんだけど、その中で、１２３号室とか、１－２３－４５番地などというとき、
　縦で数字を並べるとみっともないから、１２３とか、２３とか、４５とかを並べたいとき、ありませんか？

　これを（縦書きの中に横書きが現れるから）縦中横っていうんだけど、
　これをやるのに、Word２００３までなら、見つけやすかったんだけど、
　Word２００７になって、どこどこどこ！と探してしまったのでメモメモ。

ここ
Word2007で組み文字は？：Word ワードの使い方-文字書式
http://www.relief.jp/itnote/archives/003013.php
に「組み文字」の例があるけど、それと同様。

［ホーム］タブ
　－［段落］グループ
　　－［拡張書式］
　　　－［縦中横］をクリック

そこのサイトに、図がでてるけど、その［拡張書式］のアイコンがわかりにくい。
Aの上に、左右に小さな矢印があるやつ。
って言ってよくわかんなかったら、上記サイトをみてね。図が書いてある。

利用直前に決めるのが、トレンド？

遅延評価っていうのがある。利用するときになったら評価することで、
無駄な評価を減らすというもの。

DIも、依存性を、あとで注入するという考え。

PRINCEモデルも、要求を、あとで決める手法。

って考えると、ウォーターフォールのような初めに全部決めてしまうのではなくて、
利用直前に決めるのが、トレンドのようだ。

スーパーのケータイ利用は、今後のカギになると思う

スーパー行って、いくら買ったか、よくわかんなくなる（＾＾；）
ってこと、ありませんか？

　いや、いつもは、ないんです。自分の分なんので、そんなに買わないから。
　このまえ、知人でパーティーするとき、買い出しにでて、買い物かごにバンバンいれてって、
「いま、いくらくらい　（＾＾；）」
ってことになり、みんなで、

　　４０００円？５０００円？６０００円ってことは、ないでしょう・・・いや、あるか？

ってことになったんですよ。

　ってことは、週末、家族まとめ買い！なんていう家庭では、そーいうことって、
多くあるんじゃないかなあ？いま、いくら買っただろう？って思うこと・・・

---

　こーいうときに、ICタグで、購入金額が、一気にわかる！っていうのもいいんだけど、
そこまでいく、環境にないから、

　ケータイでバーコードを読み取り、そこから、ネットで価格を問い合わせて、
　現在購入価格を表示するアプリ

なんていうのが、できるといいかもしれない。

そこまで来ると、

１．買い物に行く前に、「今日はこれを買う！」とメモできて
２．買い物するときには、それが、どこにあるかを示してくれて
３．買った物を、バーコードスキャンすると、ネットで価格を問い合わせ、
　　現在価格を表示（わからないときは、価格を手入力）
４．清算のときは、おサイフケータイに
５．家計簿的にも、利用できる（いつ、いくらかったか、おサイフケータイで記録）

なんていう、一連のアプリをスーパーが揃えれば、顧客囲い込みにもなる。
あ、もちろん、そのアプリで、今日のお買い得情報などを載せると・・・

---

　顧客の観点から見た、このような、ケータイによる広告＆囲い込みアプリっていうのは、
　今後、どんどん考えられそうな気がする（広告代理店もまだ、手をつけてないんじゃないかな？）

　で、その手始めとして、スーパーのケータイ利用は、今後のカギになると思う。

Zendでのセッションの使い方

なんか、まとめて、ちゃんと書いてないので、ちょこっとめも。

Zendでセッションを使うには、次のことを行う。

（１）Zend/Session.phpをrequire_onceする
（２）Zend_Session::start();
（３）セッションを使うところで、 new Zend_Session_Namespace（ネームスペース名）

たとえば、はじめのページにアクセスしたら、カウントアップするというのをつくるとすると
（セッションでやっているので、セッションが切れたら、０に戻ってしまうので、アクセスカウンタの役は、しない）

index.phtmlで、

＜html＞
＜head＞
＜title＞回数表示＜/title＞
＜/head＞
＜body＞
＜?php echo $this-＞escape($this-＞kaisu);?＞回目
＜/body＞
＜/html＞

（＜　＞　は、本当は半角）
なふうに、kaisuという言葉を表示するとして、

コントローラーのindexController.phpで、

＜?php
require_once 'Zend/Controller/Action.php';
require_once 'Zend/Session.php';

Zend_Session::start();

class IndexController extends Zend_Controller_Action
{
    public function indexAction()
    {
      $myNamespace = new Zend_Session_Namespace('indexPage');
      $myNamespace-＞kaisu++;
      $this-＞view-＞assign('kaisu',$myNamespace-＞kaisu);
    }
}

（＜　＞　は、本当は半角なので、置換しないと、コピペしても動かない）

なふうに、indexPageのkaisuに値を保存して、それを表示する。

---

なお、このように行うと、
ZendFrameworlkでZend_Sessionがつかえません
http://oshiete.goo.ne.jp/qa/3644632.html?order=asc
にあるように、

Fatal error: Uncaught exception 'Zend_Session_Exception' with message 'Session must be started before any output has been sent to the browser; output started in

というエラーになることがあるようだ。
（xamppでインストールすると、なる？？）
そのときは、そこにあるように、php.iniのoutput_bufferingの行を、
output_buffering = 4096
にすると、直る？？（まだ、未確認）

PRINCEモデルは、アジャイル開発の論理的根拠になるかもしれない・・・

　筑波大（東京の大学院のほう）の中谷先生が提唱する、PRINCEモデルっていうのがある。

　ここ(PDF)に詳しく書いてあるけど、超簡単にまとめてしまうと、

　・要求獲得は、すべて、はじめの段階に獲得できるわけではない
　　　→すべての獲得がそろうのは、開発の中期になったり、後期になったりすることもある。

ってことだ。

---

　これ、考えてみると、確かにそうだ。

　たとえば、「移植性を高める開発を行う」という要望があったとしよう。
　でも、移植性が高まるかどうかは、

　　　・なんに、実装するのか（OSは、フレームワークは？）
　　　・何に対する移植なのか？

　が決まらないと、移植性を高めるといっても、お題目や判断基準にすぎなくなり、なにをすればいいかは、わからない。
　ところが、OSやフレームワークが決まるのは、理論上は、要求仕様のあと、外部設計ないしは詳細設計の一番初めまでの、いずれかの時点になる（もし、要望の段階で決めた場合、それは制約になる。制約なので、細かく決めなくてもいい。OSはLinuxっていう程度でいい。カーネルやｇｃｃのバージョンまで決まってなくてもいい）。

　ってことは、移植性の詳細は決められない（Linuxやｇｃｃはバージョンによって、動きが違う。これを要望段階で検討することは、決まってないので、できない）。

　だから、要望をすべて、取得することは、開発初期においては、不可能だ。

---

　そう考えると、開発初期に全ての要望を決めてしまう、ウォーターフォールは、現実では、不可能ということになる。開発中に要望が出てきて、その要望を、随時取り入れないといけない。そのような開発方法・・・となると、アジャイルしかない。

　という結論になる。

　ということで、

PRINCEモデルは、アジャイル開発の論理的根拠になるかもしれない・・・

美女がLinuxコマンドを紹介するサイト

ここ
美女がLinuxコマンドを紹介する美女Linux
http://slashdot.jp/linux/10/12/24/0818242.shtml
によると(以下斜体は上記サイトより引用）


手書きのボードを持った美女がLinuxコマンドを紹介するという美女Linuxというサイトが公開された。


みてみましょう。

ここ　http://bijo-linux.com/

らしいけど・・・
・・・うーん、makeというボードを持たれても・・・なあ・・（＾＾；）

フレームワークを理解するには

　前の、デザインパターンとフレームワークで、結論をかきわすれた。

　で、結論。
　デザインパターンの場合は、いろいろ覚えないといけないが、

　フレームワークは、結局、どんなものでも
　３つくらいのことを覚えればいいことになる。

（１）フレームワークの範囲
　　　→何をしてくれるフレームワークで、本体はどこで、カスタマイズできるのはどこか？

（２）設定ファイルは何で、どんなふうに記述すればいいか

（３）どこに、何をプログラミングするか？

　処理の細かいことは、フレームワークがしてくれるので、気にしないでいい。
　ちなみに、これだけだと、
　・Eclipse 3ではじめる Javaフレームワーク入門 Seasar2/Struts 2対応とか
　・PHPフレームワーク入門とかで
　だいたいのことは間に合うという話になる。

SpringAOPフレームワーク

■SpringでAOPをやるには！
・ポイントカット：XMLにかく
　　→便利なポイントカットも用意してくれているよ！

・アドバイス：インターセプタという

---

■ほかのAOPとの比較
・Springだと、プロキシベース,ポイントカットはBean定義ファイル、インターセプタは、Javaクラス
・しーさー、JBossは、aroundしかないお
・AspectJは、特殊な言語で書くお、バイトベースだお
　→バイトコードレベルとか、プロキシとか：ウィーブするところをさしている

---

■やり方の例

０．もともと、書きたいプログラムがあったとする
（MyAopDiImpl.java これ以外に、IAopDi.javaも存在する）
・インターフェースになっていないと、できない。インターフェースにしてることだいじ

package sample;

public class MyAopDiImpl implements IAopDi {
	  private String name;

	  public String getName() {
	     return name;
	  }

	  public void setName(String name) {
	     this.name = name;
	  }
}

１．インターセプションしたいクラスをかこう！
(MyBeforeAdviceInterceptor.java)

import java.lang.reflect.Method;

import org.springframework.aop.MethodBeforeAdvice;

public class MyBeforeAdviceInterceptor implements MethodBeforeAdvice {

    public void before(Method arg0, Object[] arg1, Object arg2) throws Throwable {
      System.out.println("Hi!!");
    }

Before用にMethodBeforeAdviceみたいに、アドバイスのクラスがいろいろ用意されている

２．getBeanするところを書く
(sample.java等、mainメソッドの中）

        WebApplicationContext context = WebApplicationContextUtils
                                         .getRequiredWebApplicationContext(getServletContext());

        IAopDi obj = (IAopDi) context.getBean("myFactoryBean");
        out.println(obj.toString());

３．設定ファイルを書く
（applicationContext.xml等、設定ファイルのxml）

  ＜bean id="myFactoryBean" class="org.springframework.aop.framework.ProxyFactoryBean"＞
    ＜property name="proxyTargetClass"＞＜value＞false＜/value＞＜/property＞
    ＜property name="proxyInterfaces"＞＜value＞sample.IAopDi＜/value＞＜/property＞
    ＜property name="target"＞＜ref local="obj"/＞＜/property＞
    ＜property name="interceptorNames"＞＜value＞myAdvisor＜/value＞＜/property＞
  ＜/bean＞
  ＜bean id="myAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor"＞
    ＜property name="advice"＞＜ref local="myInterceptor"/＞＜/property＞
    ＜property name="pattern"＞＜value＞.*get.*＜/value＞＜/property＞
  ＜/bean＞
  ＜bean id="myInterceptor" class="sample.MyBeforeAdviceInterceptor"/＞
  ＜bean id="obj" class="sample.MyAopDiImpl"/＞

（＜　＞は、本当は半角）

これで、実行すると、いいらしい・・・

---

■Autoproxy書くと
　設定簡単！なんだって・・・

デザインパターンとフレームワーク

　GoFのデザインパターンは、昔は実務をやっているSEさん、プログラマーさんでも、よく言われたけど、今は、「生産性向上」という文脈では、アカデミックの人はまだ使っているけど、実務の人は、そういうことは言わないと思う。

　もちろん、SE、プログラマさんでも、教養や趣味として、勉強することはあるかもしれない。
　しかし、「デザインパターンに沿ってプログラミングすると、生産性が向上したり、再利用性が向上するので、どんどん利用しましょう！」とは、言わないと思う（アカデミックでは、まじ、言うんだよ、いまだに、これ・・・）。

　その代わり、実務では、フレームワークを使って、とくに、一部（あるいは全部？）を自動化することによって、生産性向上、場合によっては再利用という話は、非常に良く聞くというより、アーキの仕事って、その選択が全てかもお・・・って思うくらい。。

　で、なぜ、そうなったのか？について、ちょっと説明したことがあったんだけど、せっかくなので、そのとき話した内容をメモメモ

---

■生産性向上の流れ

　生産性向上の流れから、まず、デザインパターンとフレームワークを位置づけてみたい

（１）まず、生産性向上のための手法としては、
　　・同じ処理部分を切り出す
　　　　→同じ処理部分＝共通部分をライブラリ化
　というライブラリによる手法がはじめに出た。

（２）さらに、それをメタな形にして、
　　　・同じようなことをやるところを切り出す
　　　　　→同じコトをやっている＝パターン

　という考えが生まれた。これは、ライブラリの場合もあるけど、
　ライブラリ以外の分野でも、パターンは考えられる。

　　たとえば、将来、オブジェクトが変更されるコトが見込まれる場合、
　　つまり、現在、MyClassVer1だが、数年後にはMyClassVer2になるようなとき、
　　現在のクラスのメソッドは将来にもあって、そこは、互換性をとるとしたら、
　　すべてのクラスをMyClassVer1からMyClassVer2に書き換えるのは面倒なので、
　　MyClassというインターフェースをつくり、すべての操作は、そのMyClassで
　　行って、生成部分だけ、MyClassVer1かMyClassVer2かを切り分ける。

　　このようなインターフェースの使い方は、パターンであるけど、
　　やり方、考え方なので、ライブラリではない。

　そして、とくに、パターンの中でも、GoFのデザインパターンが有名になった。

　　パターンだと、さっきの生成部分、MyClassVer1かMyClassVer2かを切り分ける
　　ところ、どうやってもいいんだけど、ただnewで書かれると、すべてのnewを
　　書き換えないといけないからこまる。

　　そこで、newさせないために、Factoryクラスを作成し、そのFactoryクラス
　　からインスタンスを受け取り、Factoryクラスの中で、MyClassVer1か
　　MyClassVer2か、どちらを生成するかを切り分けるようにすると、生成が
　　局所化され、利用者は、バージョンの違いを意識しなくていいというように
　　なる。これが、GoFのデザインパターンのFactoryパターン

（３）ところが、パターンの場合、なにも決まりのない、自由なところから、
　パターンを利用することになる。そうすると、パターンを利用したり、
　利用しなかったり見たいな感じで、統制がとれない。
　　パターンを利用するにも、かなりの技術がいるのだ・・・

　　そこで、プロジェクト全体で、統制を取る開発方法が必要になった。
　　つまり、自由を規制し、「ここだけ、コーディングしてね！」という形で、
　他は、共通のノウハウを使うという、「パターンのノウハウパッケージ化」
　みたいな感じのことが必要になった。

　これを実現したのがフレームワーク。

　　　さっきの生成の例で言うと、生成する部分は、設定ファイルに書いて、
　　　生成は、getBeanでしてね・・・（SpringDI）みたいなかんじ。

---

■デザインパターンとフレームワークの関係

　なので、デザインパターンだと、全部自由に書けるところから、パターンを使って書くという形になる。

　フレームワークは、もう、書くところは決まっていて、そこだけ書くということになる（ハリウッドの法則）

　ということなので、フレームワーク作成者は、デザインパターンを使って、フレームワークを作るかもしれない。しかし、フレームワークが出来てしまえば、あとは、そこに何を書くかは決まっていて、それだけを書けばいい。
　フレームワークによって、書く場所が限定され、その部分の書き方が固定化できるようになったから、自動化できる可能性が広がったともいえる。

DIとSpringについて

・まーちんふらいあー（M. Fowler）が、IoC（Inversion of Control：制御の反転）を整理したところからはじまり

・オブジェクトの依存性をあとから注入する
　　→アスペクト指向のAroundでも実現できる

・実現方法：DIコンテナ

---

■DIとは？

　　AがB（抽象クラス）を使っていて、Bのインスタンスは、B1,B2であるというとき

　　Aがインスタンスかされるには、B1,B2のインスタンスを実装しないといけない
　　　　　→AがB1,B2を知っている（依存性がある）

　　これでは、AとB1、B2の依存性が高くなる

　　そこで、

　　　　Aは、Bを使う
　　　　Aは、DIコンテナさんに、インスタンス化頼む
　　　　DIが、B1か、B2かを決めて、インスタンス→設定ファイルに書いてある：局所化した

　　とする、これがDI
　　こうすると、アプリケーション立ち上げ時に、何を使うか決定できる。
　　DIコンテナの上にPOJOを置いておく

---

■DIの種類：なにをインジェクションするの

・インター・フェースインジェクション

・セッター・インジェクション

・コンストラクタ・インジェクション

---

■DIとAOP

　AOPのほうが、実現できることが広い
　AOPのポイントカットに特化したといえる。
　DIはインスタンス生成に特化＝目的にあっていれば使いやすい

---

■Springフレームワーク
　　・DIコンテナ
　　・MVCフレームワーク
　　・JDBC抽象化フレームワーク
　　・AOPフレームワーク
　　・Webインテグレーション
　　・ORMインテグレーション

　以下の話は、Tomcat＋Springをやる
　（ロギングは、/WEB-INFにlog4j.xmlを置く事で可能）

Springは、プレゼンテーション層 ,ビジネス、データアクセスすべて対応してる。
　　→もちろん、プレゼン層にStruts、データアクセスにHibernateを入れてもOK

---

■Spring　DIコンテナ
・Bean定義ファイル（デフォルトapplicationContext.xml）に、JavaBeansの構成
　　　→beans
　　　　　bean id=オブジェクト名　class=パッケージ.クラス
　　　　　　　property　name=変数名
　　　　　　　　　　value 値
　　　　　　　　　→setter,getterがある→プロパティがある
　　　　　　　　　→propertyのref beanで、オブジェクトをプロパティに代入可能

・DIコンテナ
　　Beanファクトリ
　　（Applicationコンテキスト：Beanファクトリの上位）

---

■Eclipseで・・・
・プロジェクトを作成する
・Sample.javaっていうかたちで、メインのクラスをつくったとする。

・そこに、こんなかんじで、サンプルをつくるお（sampleパッケージにあるとする）。

package sample;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.Resource;


public class Sample {
	public static void main(String[] args) {
		Resource resource = new ClassPathResource("/sample/sample.xml"); 
		BeanFactory beanFactory = new XmlBeanFactory(resource);
		MyClass taro = (MyClass) beanFactory.getBean("obj1");
	}
}

・MyClassクラスをつくるお
　　→getter,setterがあればいい

・Bean定義ファイル（ここでは/sample/sample.xml）をつくるお
　　その中には、beanでid=obj1,classにMyClassが定義されているはずお

・プロパティを開いて、Spring→BeansSupportで、Bean定義ファイル（xml）を指定してから

・Javaアプリケーションとして実行する

---

■こうすると・・・

Bean定義ファイル（ｘｍｌ）をかえるだけで、
→プロパティを開いて、Spring→BeansSupportで、Bean定義ファイル（xml）を指定をかえるだけで、
実行するものが変えられる。

---

■EclipseのTomくんにかんして
・ウィンドウの設定、Tomくんのバージョンとか、ホームを設定すること。
・あと、Tomcatで、対象プロジェクトを右ボタンクリックしたあとで、これやってね

---

■AOPに比べた欠点
　同じ値を返す、複数のクラスとか（モックでNullを返すとき）を作る場合、
　DIだと、みんな作んないといけない
　（アスペクトなら、クラス名、メソッド名に＊を使って、いっぱつでいける）

---

こんかいつかった、すぷりんぐ

astah*を使って、ICONIX風一気通貫システム開発 その１０：DAO作成

　「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、

（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す

前回、（８）をやったので、今回は、「（９）エンティティをDBのテーブルと、DAOに書き直す」についてです。

---

■方法

　といっても、エンティティのクラス図は、DB構造そのままなので、別に対してやることはなくて、

１．DB構造を元に、create tableする

２．そのテーブルのアクセスロジック部分を作成する

３．場合によっては、元となるデータをセットしたり、Viewを作ったりと、
　　アクセスするための作業をする

ことになります。とくに、２は、手作業でやるのではなくって、
HibernateとかiBATISとか、アクセスするためのDAO,O/Rマッピングがありますので、
それらを使って行います。

クラス図が出来ているということは、型と項目名は書いてあるので、それをもとに作成します。

それらのツールを使わない場合でも、たいてい、アクセス部分は、なんか、自分たちでフレームワークを作って、それにしたがって、DAOを作成するのが普通でしょう。

---

■位置づけ

　詳細設計＆コーディングの、DB作成部分になると思います。

---

あとのこすは、１個

QMLを、はじめたい！ その５ 画面切り替え

　シリーズ「QMLを、はじめたい！」。前回は、画面の部品について取り上げました。ということで、１画面については、これでOK。

　あとは、複数画面の切り替えになります。今回は、その話。

---

■概要

　画面切り替えは、stateを使って出来ます。

１．画面全体にstateを用意しておき
２．画面を切り替えたいときに、１のstateに各画面のstateをセット
３．全体のstates:で、切り替わったときに出す画面の対応を記述

するとできます。

---

■ソースコード

こんなかんじ。

import Qt 4.7

Rectangle {
    id:rectangle1
    width: 200
    height: 200
    property int i: 0
    state:"state1"

    Item {
        id:text1
        visible:false
        anchors.fill: parent
        Text {
            x: 16
            y: 23
            text: "Hello World"
        }
        Image {
                id: image1
                x: 35
                y: 35
                source: "http://doc.qt.nokia.com/4.7/images/declarative-qtlogo.png"
        }
        MouseArea {
                        property int j: 0
                        id: mouse_area1
                        anchors.fill: parent
                        onClicked:{
                            if (rectangle1.state == "state1")
                               rectangle1.state = "state2"
                            else
                               rectangle1.state = "state1"
                            console.log(rectangle1.state)
                    }
         }
    }

    Text {
        id:text2
        visible:false
        x: 66
        y: 93
        text: "another world"
        MouseArea {
                    property int j: 0
                    id: mouse_area2
                    anchors.fill: parent
                    onClicked:{
                        if (rectangle1.state == "state2")
                           rectangle1.state = "state3"
                        else
                           rectangle1.state = "state2"
                        console.log(rectangle1.state)
                    }
        }
    }

    Text {
        id:text3
        visible:false
        x: 66
        y: 93
        text: "new world"
        MouseArea {
                    property int j: 0
                    id: mouse_area3
                    anchors.fill: parent
                    onClicked:{
                        if (rectangle1.state == "state3")
                           rectangle1.state = "state1"
                        else
                           rectangle1.state = "state3"
                        console.log(rectangle1.state)
                    }
        }
    }

    states: [
        State {
            name: "state1"
            PropertyChanges {
                target: text1
                visible:true
            }
        },
        State{
            name: "state2"
            PropertyChanges {
                target: text2
                visible:true
            }
        },
        State{
            name: "state3"
            PropertyChanges {
                target: text3
                visible:true
            }
        }
    ]
}

---

■せつめい

３つ画面があって、

・第一画面（ID　text1 State state1）は
　　　QTのロゴと、Hello　World

・第二画面（ID　text2 State state2）は
　　　another　World

・第三画面（ID　text3 State state3）は
　　　new　World

が表示される。これを、順次切り替えていく

---

■方法

１．画面全体にstateを用意しておき

　　Rectangleに

　　　　state:"state1"
　　を用意（"state1"は初期値。これがないとはじめに全部でてくることも！

２．画面を切り替えたいときに、１のstateに各画面のstateをセット

MouseAreaのonClicked部分

if (rectangle1.state == "state1")
	rectangle1.state = "state2"
else
	rectangle1.state = "state1"

のように、「自分のステータスだったら、次のステータスセット、
そうでなければ、自分のステータスセット」と書いておく。

３．全体のstates:で、切り替わったときに出す画面の対応を記述

   states: [
        State {
            name: "state1"
            PropertyChanges {
                target: text1
                visible:true
            }
        },
　　　　　　：
（以下省略）

のように、statusの中に、各ステータスを書き、
その中で、nameとPropertyChangesを書く。
ターゲットは自分の画面名。

---

■注意！！

・states: のあと、[であって、｛ではない。

・statusの区切りは,であって、:や;ではない。

i*とKAOSの違い

書いたっけ、これ？ま、いいや・・・

i*とKAOSの違いを考えると、

外見的には、

KAOSは、ゴールがひし形で、そいつを詳細化していき
　ツリー上に広がっていく感じだけど、

i*は、ソフトゴールとゴールを図形的に分けて、そこにタスクとか書いて、
　その間に線を引いて、華やかにやっている

なかんじの違いが見えてくると思う。
しかし、これが、利用上では、大きな違いがあると思う。

---

　まず、あるタスクがあるとき、
　　・このタスクに関する(同じレベルの）タスクをあげて、入出力などの関係を見ていく、
　　　　横の広がりを見る方法
　と、
　　・あるタスクは何から構成され、さらにそのタスクは何から構成され・・・
　　　と、詳細化していく、「縦の広がり」を見る方法

　がある。一般に。

　もし、横の広がりと、縦の広がりを、同時に展開すると、状態爆発してしまう。
　そこで、同じレベルのものを比較して考える、横の広がりを見るものと、
　詳細化していく縦の広がりを見る図にわかれる。

---

　KAOSは、詳細化していき、縦の関係を見るのに適している。
　これを、関連する情報は何か？と考えて、横の方向に見ていくと、「たいへんなことに！」なってしまう。

　一方、i*は、いろんな線が交差するところからみても、明らかなように、横の方向に見ていく図であり、これを、詳細化していくと、「たいへんなことに！」なってしまう。

　よって、さまざまな案を「ソフトゴール」により、比較、検討するときには、i*が適していて、逆に、だいたい状態が決まっていて、ゴールまで見通しがあるようなときは、KAOSを使って、詳細化したほうが、きれいにまとまる。

FF14、バージョンアップすると→動かないコンピューター

ここの痛いニュース
ＦＦ14のバージョンアップでパソコンクラッシュ続出
http://blog.livedoor.jp/dqnplus/archives/1578051.html

FF14って、
和田社長がクソゲーであることを認め
　　　↓
無料期間を延期して
　　　↓
「一日一回、ゲーム内で『私はFF14を続けるよ』と言いましょう！」キャンペーンしたけど・・・
　　　↓
結局新開発チームになって、
　　　↓
その結果バージョンアップでパソコンクラッシュ続出

日経コンピューターさーん！「動かないコンピューター」の取材ネタ、ありますよおー！！