ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

astah*を使って、ICONIX風一気通貫システム開発 その11(終):コントローラー

2010-12-31 21:04:30 | そのほか


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

(1)作るべきもののユースケースを書く
(2)ユースケースシナリオを書く
(3)ロバストネス分析
(4)バウンダリ(画面)、エンティティ(テーブル等)の属性を埋めていく
(5)バウンダリの項目を元に、画面構成を考える。
(6)(必要があれば)エンティティを正規化して、ER図にする
(7)フレームワークを決定する
(8)画面クラスをソースコードに書き直す
(9)エンティティをDBのテーブルと、DAOに書き直す
(10)コントローラーを書き直す


 前回、(9)書いて、のこり1個「(10)コントローラーを書き直す」なので、
今回、これを書いて、このシリーズをおわりにしてしまいましょう。




■概要と位置づけ

 (8)により、画面部分を書きました。
 (9)により、エンティティ部分を書きました。

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

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

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




■結局

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

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

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




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


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



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

年賀状で縦中横をやるとき-Word2007で

2010-12-30 13:43:04 | Weblog

 年賀状を書くとき(って、今書いてんのかよ、とツッコミがありそうだが)
 住所を、縦書きで、書くんだけど、その中で、123号室とか、1-23-45番地などというとき、
 縦で数字を並べるとみっともないから、123とか、23とか、45とかを並べたいとき、ありませんか?

 これを(縦書きの中に横書きが現れるから)縦中横っていうんだけど、
 これをやるのに、Word2003までなら、見つけやすかったんだけど、
 Word2007になって、どこどこどこ!と探してしまったのでメモメモ。

ここ
Word2007で組み文字は?:Word ワードの使い方-文字書式
http://www.relief.jp/itnote/archives/003013.php

に「組み文字」の例があるけど、それと同様。

[ホーム]タブ
 -[段落]グループ
  -[拡張書式]
   -[縦中横]をクリック

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


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12月29日(水)のつぶやき

2010-12-30 02:25:15 | Twitter
23:53 from web
多摩市に天才少年現る!430MhzFMで、小学2年生がQSOしてる(お手数をおかけしてすみませんとか、難しい言葉も使ってる)コールサインがあるってことは、アマチュア無線の試験に小2で受かったってことで、すごすぎる!私が小2のとき、そもそもマークシートが塗れただろうか?・・・
by xmldtp on Twitter

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2010-12-29 13:26:40 | Weblog

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

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

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

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


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2010-12-28 17:52:28 | Weblog

スーパー行って、いくら買ったか、よくわかんなくなる(^^;)
ってこと、ありませんか?

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

  4000円?5000円?6000円ってことは、ないでしょう・・・いや、あるか?

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

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




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

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

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

そこまで来ると、

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

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




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

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



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2010-12-27 15:31:58 | PHP

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

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

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

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

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
にすると、直る??(まだ、未確認)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2010-12-27 11:50:36 | そのほか

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

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

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

ってことだ。




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

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

   ・なんに、実装するのか(OSは、フレームワークは?)
   ・何に対する移植なのか?

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

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

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




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

 という結論になる。

 ということで、

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


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12月25日(土)のつぶやき

2010-12-26 02:08:40 | Twitter
20:23 from web
村上佳菜子さんって、若いころの松浦 亜弥さんに似てると思う
by xmldtp on Twitter

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2010-12-25 22:53:57 | トピックス

ここ
美女がLinuxコマンドを紹介する美女Linux
http://slashdot.jp/linux/10/12/24/0818242.shtml

によると(以下斜体は上記サイトより引用)


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


みてみましょう。

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

らしいけど・・・
・・・うーん、makeというボードを持たれても・・・なあ・・(^^;)




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2010-12-24 16:30:57 | そのほか

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

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

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

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

(2)設定ファイルは何で、どんなふうに記述すればいいか

(3)どこに、何をプログラミングするか?

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

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12月23日(木)のつぶやき

2010-12-24 02:23:51 | Twitter
21:54 from web
今日わかったこと。光触媒丼、SML http://www.pllab.riec.tohoku.ac.jp/smlsharp/ja/
21:55 from web
今日わからなかったこと。Wiiで、ピーチ姫をどう操作したらよいのか?十字キーとAボタンをテキトーに押せば、バトルしてくれるよ・・・っていわれたけど、うまく動かなかった(>_<!)
21:58 from web
今日の共通意見。日本の新卒の就職率が悪いのは、親のせいである。親から子供を引き離して、自由にさせてあげれば、子供は中小企業に就職できて、就職率は上がるけど、親が大企業に入れさせたがるので、子供は就職できなくなっている。
by xmldtp on Twitter

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12月22日(水)のつぶやき

2010-12-23 02:24:06 | Twitter
11:11 from web
昨日聞いたSpringの話は、参考文献の参照をみると、結局、この本見ればOKってこと?”Spring入門” http://www.amazon.co.jp/gp/product/product-description/4774123412
12:44 from web
興味津々なコトがちゃんとまとめられてる良い記事 メダルの背後にiPadあり 世界バレーで眞鍋監督が使っていたアプリの正体 http://headlines.yahoo.co.jp/hl?a=20101222-00000022-zdn_n-sci あ、 @yukatan の記事だ
by xmldtp on Twitter

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

SpringAOPフレームワーク

2010-12-22 14:25:46 | そのほか

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

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




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



■やり方の例

0.もともと、書きたいプログラムがあったとする
(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;
	  }
}



1.インターセプションしたいクラスをかこう!
(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みたいに、アドバイスのクラスがいろいろ用意されている

2.getBeanするところを書く
(sample.java等、mainメソッドの中)
        WebApplicationContext context = WebApplicationContextUtils
                                         .getRequiredWebApplicationContext(getServletContext());

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



3.設定ファイルを書く
(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書くと
 設定簡単!なんだって・・・



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2010-12-22 10:41:03 | そのほか

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

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

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

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




■生産性向上の流れ

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

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

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

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

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

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

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

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

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

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

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

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

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




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

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

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

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



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

12月21日(火)のつぶやき

2010-12-22 02:25:10 | Twitter
16:17 from web
「ニコニコ動画であゆ…エイベックスが音源許諾」 http://headlines.yahoo.co.jp/hl?a=20101220-00001050-yom-ent
by xmldtp on Twitter

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする