FLATzブログ

[プロジェクトマネジメント]の記事一覧

[symfony][UML]ユースケース図だけで作るシステム開発

2008年01月18日(金)18:09|nasu|FLATzブログ, PHP, プロジェクトマネジメント, 技術情報このエントリをdel.icio.usに追加このエントリをはてなブックマークに追加

那須です


皆さんは開発をする際、きちんと仕様書を書かれていますか?私は、普段開発をする際、きちんとしたドキュメントを作る機会が少なくなっていたのですが、現在手がけているプロジェクトがそこそこの規模を持っており、使い捨て前提のフリーハンドで書いた仕様書だけでは仕様の理解が追いつかなくなっています。


そのため、最近JUDEでユースケース図を描くようにしました。個人的にはユースケース図というと


  • クライアントと認識をあわせるためのツール
  • エンジニアに全体の理解を促すためのツール

という印象で、ユースケース図からユースケースを作り、そこからクラス図などをおこしていくものと考えていました。ですが、今のプロジェクトでは、ユースケース図を使い、そのまま実装レベルで使えるような工夫をしています。今回は、そのことをちょっとまとめておきたいと思います。


前提


応用がきかない場合もあると思いますので、あらかじめ前提を述べておきます。似たような環境でしたら、大丈夫とは思いますが。


  • プログラミング言語: PHP5
  • フレームワーク: Symfony
  • 開発エンジニアは、全員Symfony経験者

ユースケースからプログラム設計へ


ユースケース図


さて、↑のユースケース図は、トラックバック機能を模したユースケース図です。特徴として、ユースケースをパッケージで囲んでいます。このパッケージは、そのままSymfonyのモジュールとなります。そして、ユースケースが アクション(メソッド)となります。と、これだけです。まあ、大したことはないのですが、モジュールとアクションで処理が分別されるようなWebアプリケーションでは、これだけでもかなり有用と考えています。


記号の意味


記号 実装上の意味 備考
パッケージ
(タブのついた長方形)
モジュール
ユースケース
(楕円)
アクション
ユースケース同士の誘導可能関連
(矢印)
Webのリンク TB一覧にTB削除処理に
リンクするボタンがある等を示唆する
ユースケース同士の誘導未定関連
(直線)
関連 ノートなどで関連の意味を示唆し
意味づけをする
依存
(破線矢印)
そのパッケージを利用するアクターを示唆する ※ホントは普通に関連(直線)でやりたかったのですが
アクターとパッケージは関連付けができないための代替策

最後に


とまあ、勝手にユースケースを拡張してWebアプリケーション開発に使いやすいようにしているのですが、いかがでしたでしょうか。他にもモジュール間で”継承”記号を使ったりしているのですが、Symfonyでは、モジュールを継承することがないため、あまり意味を成していません。まだまだ不完全な形ではありますが、現在私が行っている試みとして、ここまでを紹介したいと思います。
超短期開発を求められる場合でも、この程度のドキュメントであればそれほど時間を使わず作ることができるため、これをもっともっと洗練させることで、クライアントとの認識のズレを最小限にしつつ、エンジニアにそのまま開発をしてもらうということができるようにしていきたいと考えています。

続きを読む


アジャイル開発の学習者にやさしいプレファクタリング

2007年07月05日(木)20:04|amakata|FLATzブログ, プロジェクトマネジメント, 技術情報, このエントリをdel.icio.usに追加このエントリをはてなブックマークに追加

プレファクタリングのお勧めの対象者


前回、プレファクタリングについて扱うと告知しましたので、今回は、プレファクタリングについてご紹介したいと思います。


プレファクタリング―リファクタリング軽減のための新設計
プレファクタリング―リファクタリング軽減のための新設計


すばり、この本をお勧めしたい人は、「アジャイル開発を学びたい新入社員」、「ウォーターフォール開発のプロジェクトでアジャイルの恩恵を受けたい開発者」、「アジャイルの教育をしたい教育者」です。アジャイル開発についての基礎知識は知っているけれど、実際の現場の中で、どのようにアジャイルを適用していいのかわからない、プロジェクトをどのように進めればよいのかわからないといった人に、ちょうど良い本です。


プレファクタリングは、書籍の副題にもあるとおり、ソフトウエア開発を行う上での設計手法について扱った本です。


新入社員にとっては設計手法というと、若干敷居が高いようにも思えますが、この書籍の場合は、一貫してプロジェクトの例を通してどのようにするかという点を扱うため、初学者でも理解しやすくなっています。また、実務経験が半年程度ある人であれば、自分との比較の中で、よりよい指針を得ることができ、新入社員のスキルアップなどにもよいと思います。


プレファクタリングとは


前置きが長くなりましたが、肝心のプレファクタリングとはいったいどんな設計手法を扱っているのでしょうか。


まず、プレファクタリングという言葉ですが、これは著者が作り出した造語で、XP(エクストリーム・プログラミング)で有名になったリファクタリングを意識した名前となっています。


リファクタリングでは、コードの振舞いを変化させずに、コードの内部構造を変えて、改善を行うプラクティスを扱いますが、プレファクタリングでは、リファクタリングを減らすために、自分や他人の経験を収集し、その知識を用いて設計を改善することを目指します。


プレファクタリングでは、次の3つの設計原則を特に重要としている点が、それまでの同様の指針との大きな違いです。


  • 極度の抽象化(Extreme Abstraction)
  • 極度の分離(Extreme Separation)
  • 極度の読みやすさ(Extreme Readability)

「極度の」と言っているのは、従来から重要だとされている指針「抽象化・分離・読みやすさ」をより過激に推し進める形で指針としているためです。


リファクタリングを行わないための開発手法と聞くと、従来の開発手法の焼き直しなのではないかと考えてしまいそうですが、プレファクタリングは、アジャイル開発を強く意識した指針となっていて、アジャイル開発の指針を具体的に示したものといえます。また、プレファクタリングは、アジャイルの持つ柔軟性から、従来のウォーターフォール型開発にも適用することができます。


プレファクタリングが柔軟である理由は、決まった指針の組み合わせをプロジェクトに適用することを強制するかわりに、いくつかの指針を提示して、それらをプロジェクトのシチュエーションに合わせて適用していくことを勧めている点です。これは、すでに開発指針が存在しているような現場にもプレファクタリングが導入できることを意味しています。そういう意味で、ウォーターフォール開発での開発は決まっているが、アジャイルの恩恵も受けたいという開発者でも、プレファクタリングの知識は役に立つことがあると思います。また、直感的に、プレファクタリングの指針に近い指針を持っている人は、より自分の方法に自信がつきルールが明確化することでしょう。


では、プレファクタリングの指針の中でも特徴的な指針について数点ご紹介します。


  • 抽象化する際には、すべてに対して抽象化する。極度の抽象化を代表する指針のひとつです。この指針では、要件定義や設計時に、値段や、郵便番号、電話番号などの値を組込み型(intdouble等)やString型で定義せず、抽象データ型(Abstract Data Type)を定義してそれを使うことを勧めています。

    例えば、電話番号であれば、TelephoneNumber型を、通貨であればCurrency型を定義することになります。要件定義の時点から、このような抽象データ型でドメインを分析することにより、ここのパラメータの制約や特徴を明確に把握することができます。また、設計以降では、抽象データ型に、妥当性検証を実装することにより、入力以外では、正しい形式の値が保持されている電話番号が入っていることが保証されている前提で他の処理を設計できるようになります。

    この指針を導入することで得られるメリットは抽象化を行うことによるメリットそのものですが、具体的な指針とすることで、開発者がこの指針を適用した際に、混乱を最小限に抑えつつ効果をえら得るようになっています。
  • クラスへのメソッドの配置は、メソッドが何を必要としているかに基づいて行う極度の分離を代表する指針のひとつです。この指針では、メソッドは、そのメソッドが操作するインスタンス変数を持つクラスに配置することとしています。この考え方は、リファクタリングの「メソッドの移動」を行う際の指針でもありますが、リファクタリングより前に行うという点が違います。こういった判断は、オブジェクト指向初学者が迷いやすい点ですが、書籍では実際のコード例を示することで、わかりやすく指針を説明しています。
  • コードでの意思疎通極度の読みやすさを代表とする指針のひとつです。この指針では、コードの読み手を分析し、
    • コードがどのように動くかを伝えたいのはコンピュータ
    • コードが何をしているか、なぜそのような処理をしているかを伝えいたのは、プログラマ
    であるとした上で、プログラマに対しては、「意図と目的を伝える」ようなコードを記述すべきだとしています。

    具体的には
    if (a_customer.can_buy(a_product)) {
    a_cart.add(a_product);
    }
    のように、処理の意図と目的が明確なコーディングになるようにし、can_buy()の処理がどのようにに行われているかはメインのコード上に記述しないようにするようにします。また、このコード上での意図がわかるようにクラス名、変数名、メソッド名をつけることが重要です。

    このような指針は、 熟練のプログラマにとっては、当たり前のように聞こえるかもしれませんが、初学者にとっては、言われるまでは気がつかない視点を早い段階で与えてくれます。

今回は、どういったものが指針になるのかを、簡単に上げてみました。プレファクタリングの書籍では、指針が60件ほど登場します。もちろん、すべてを覚える必要も、すべてを適用する必要もありません。


まとめ


いかがでしたか?すでに気がつかれている方もいらっしゃると思いますが、この書籍は、アジャイルで言う守破離の「守」を扱った本ですが、同時に、プレファクタリングそのものは指針をシチュエーションによって選べといっているため「離」の要素を持っています。そういう意味で、アジャイルの守破離を実践するための本として設計されているといってもよいでしょう。アジャイルの実践により興味のある人はぜひ書籍を手に取ってみてください。

続きを読む


Page 2 of 3«123»

このページの先頭へ