Article 349 at 10/08/11 18:25:34 From: noreply@objectclub.jp Subject: 【オブジェクト倶楽部： 2010-31号】

Date:  Wed, 11 Aug 2010 18:30:11 +0900
Subject:  【オブジェクト倶楽部： 2010-31号】
X-Mail-Count: 00349

　　　　　　　┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
　　　　　　　┃　　　　　　　　　　　　　　　　　　　　　　　　　■┃
　　　　　　●┃●　●　オ　ブ　ジ　ェ　ク　ト　倶　楽　部　　　■　┃
　　　　　　　┃　　　　　　　　　　　　　　　　　　　　　　　■　　┃
　　　　　　　┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
　　　　　　　　　　　　　　　　　　　　　　　　　　No.339　2010/08/11

■　I　N　D　E　X
┃
┣【Topics】XP祭り2010 参加者募集(9/4)
┣【Topics】ソフトウェアテストシンポジウム2011 東京 論文募集
┣【要件定義】要求とか要件についての四方山話 [5]
┃            ～分析・モデリングで作るもの～
┣【プログラミング】Let's Try 受入テスト [8]
┗ 編集後記

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
　〇　XP祭り2010 参加者募集(9/4)
　　〇 〇━━━━━━━━━━━━━ ━━・　

今年もXP祭りを開催します。今年は「アジャイル学園祭」という名前の通り、
XPに限定したプラクティス、技術ネタに限定せずに、広く多くの知見や体験を
得られる祭りを目指しています。

ライトニングトークスのトーカーも募集しています。

日　時：　2010年9月4日(土)
場　所：　早稲田大学 西早稲田キャンパス (東京・高田馬場)
詳　細：　http://kokucheese.com/event/index/2167/

〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
　〇　ソフトウェアテストシンポジウム2011 東京 論文募集
　　〇 〇━━━━━━━━━━━━━ ━━・　

2011年1月に開催予定のソフトウェアテストシンポジウム2011では、皆様からの
論文を募集しております。ソフトウェアのテストや、品質に関する内容を
「研究論文」「経験論文」「事例発表」の3つのカテゴリで募集します。
なお、2007年度は、オブジェクト倶楽部の懸田がバグレゴでベストスピーカ賞
を受賞しています。( http://jasst.jp/archives/jasst07e.html#speaker )

日　時：　2011年1月25日(火)～26日(水)
場　所：　目黒雅叙園 (東京・目黒)
詳　細：　http://jasst.jp/archives/jasst11e.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┣【要件定義】要求とか要件についての四方山話 [5]
┗            ～分析・モデリングで作るもの～

こんにちは、平田です。
前回は、要件定義を構成するアクティビティについて書きました。あの後、他
の本なども横断的に確認してみました。分割の仕方こそ違っても、内容的には
ほぼあの通りの分割になっていて、決定的な手法がなさそうな要件定義の分野
でも、ある程度の流れがあるんだなと感心しました。

今回はそのアクティビティのひとつである、「要求の分析」で何を作るのか、
ということについて書いていきます。
要件定義について書かれた本などを読むと、分析・モデリング時に作成するも
のについて、次の2つのパターンが多いようです。

  1.総花的に多くのドキュメントを紹介している
  2.要件定義のプロセスを固めていて、その作成物が限定されている

1のような大量のドキュメントを作る余裕はないし、2の場合、そのときのプロ
ジェクトの内容(作るシステムの種類やお客様の参画度合い、契約状況)によっ
てプロセスに従えないこともあるし、結構悩ましいと思っていました。

きっと1のような、ドキュメントを紹介しているようなものでも、その中から適
切なものを選択しろという話なのですが、どのようにして選択すればよいので
しょう？

この疑問に答えるひとつの指針が、エレン・ゴッテスディーナーさんの『実践
ソフトウェア要求ハンドブック』[*1]の中に書かれています。
モデルを4W1H(Who／What／When／Why／How)に対する答えを表現するものと定義
して、どういうビジネス領域の場合にどのモデルを使用するかという指針が書
かれています。

・処理的なビジネス領域、Howモデル(ユースケースやシナリオ)を中心に、Who
  やWhy(アクターやビジネスルールなど)も。
・構造的な領域であれば、Whatモデル(データモデルなど)で、補足としてWhyモ
  デルも。
・動的な領域は、Whenモデル(イベント応答表、状態図)とWhyモデルが向いてい
  る。
・制御指向の領域ではWhyモデル(ビジネスルールや決定表など)が良い。

(詳細は書籍を参照してください)

私個人は最近の仕事で、構造的な領域(データマイニングやレポート作成)を扱
うことが多く、そのような仕事の中で「ユースケース記述」などを書こうとし
ても、なかなかうまく書けないなぁと悩んでいるときに、この本の記載に出会
い、ハッとさせられたことを覚えています。

分析・モデリングで作成するものについては、書籍の他にも社内標準などで指
定されてしまっている方も多いと思いますが、それらは過去の一時点でうまく
いったものの集合体、もしくはそのときの事例単体でしかないと割り切って、
今のプロジェクトでどういうものが必要かを考えてみると、よいのではないで
しょうか？そのときに、今回紹介したような指針を使って考えてみるのは役に
たつと思います。(平田)

[*1]『実践ソフトウェア要求ハンドブック』
     http://www.amazon.co.jp/exec/obidos/ASIN/4798117080/xpjp-22

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ■━
■
┗【プログラミング】Let's Try 受入テスト [8]

● 始めに
本連載は、ツール編に入り、Cucumberについて解説しています。
前回は、Cucumberを使った開発ステップ、インストール、プロジェクトの基本
フォルダ構成について説明しました。
詳細は、過去のメルマガを参照してください。
- http://ObjectClub.jp/ml-arch/magazine/345.html

今日は、Cucumberのサンプルを一部修正、実行しながら、featureファイル、
stepファイルの記述内容について簡単に解説していきます。

● サンプルのコピー
<Cucumberのインストール先>/examples/i18n/en 以下を作業フォルダにコピー
します。

● フォルダ構成の確認
コピーした内容を確認してください
en
├── Rakefile
├── features
│   ├── addition.feature
│   ├── division.feature
│   └── step_definitons
│       └── calculator_steps.rb
└── lib
   └── calculator.rb

cucumberの実行は、
 cd <作業フォルダ>/en
 rake cucumber
です。

● addition.featureの一部修正
features/addition.featureをエディタで開き、Scenarioを追記してください。

== features/addition.feature ======
Feature: Addition
 In order to avoid silly mistakes
 As a math idiot
 I want to be told the sum of two numbers

 # 追記
 Scenario: Add three number
   Given I have entered 1 into the calculator
   And I have entered 2 into the calculator
   And I have entered 3 into the calculator
   When I press add
   Then the result should be 6 on the screen
 # End 追記
...
== END features/addition.feature ======

1つのfeatureファイルには、複数のシナリオ(Given、When、Then)を記述できま
す。
「In order to... As a ... I want to ...」、「Given、When、Then」につい
ては、過去の記事を参考にしてください。
 - 「In order to... As a ... I want to ...」
 -  http://ObjectClub.jp/ml-arch/magazine/330.html
 - 「Given, When, Then」
 -  http://ObjectClub.jp/ml-arch/magazine/338.html

features/addition.feature には、Calculatorの期待する振る舞いを自然言語
の近い形式で記述します。今回は、3つの数字(1、2、3)を足し合わせて合計(6)
が表示されることを追記しました。追記する際は既存のstep定義(後述を参照)
を利用しています。

記述に間違いなければ、「rake cucumber」はパスする予定です。

● stepファイルの確認
addition.featureを実行できるようにするためには、addition.featureで記述
した内容を解釈するためのstepファイルの記述が必要です。
stepファイルに相当するcalculator_steps.rbの記述内容を確認します。

== features/step_definitions/calculator_steps.rb ===
begin require 'rspec/expectations'; rescue LoadError; require
'spec/expectations'; end
require 'cucumber/formatter/unicode'
$:.unshift(File.dirname(__FILE__) + '/../../lib')

require 'calculator'

Before do
 @calc = Calculator.new
end

After do
end

Given /I have entered (\d+) into the calculator/ do |n|
 @calc.push n.to_i
end

When /I press (\w+)/ do |op|
 @result = @calc.send op
end

Then /the result should be (.*) on the screen/ do |result|
 @result.should == result.to_f
end
== END features/step_definitions/calculator_steps.rb ===

Beforeに前処理、Afterに後処理を記述しています。
Given、When、Thenのステップの定義が記述しています。

featureファイルのGiven、When、Thenの記述とstepファイルのGiven、When、
Thenの記述を見比べてください。(例えばGiven)

== addition.feature の一部 ==
   Given I have entered 2 into the calculator
====

== calculator_steps.rb の一部 ==
Given /I have entered (\d+) into the calculator/ do |n|
 @calc.push n.to_i
end
====

calculator_steps.rbの中でaddition.featureで記述した内容がテストのステッ
プとして実行できるように、Given、When、Thenのステップを定義しているのが
読み取れるでしょう。正規表現を使っているのが特徴的です。

addition.featureに追記した内容は、calculator_steps.rbで既に定義済みのス
テップを利用していました。そのため、calculator_steps.rbの修正は不要で、
「rake cucumber」が実行できました。

● featureファイル／stepファイルの一部修正
今度は、featureファイル／stepファイルの一部を修正してみます。
下記の手順で確認してください。

① addition.featureのGivenの記述を一部修正
   calculatorからcalcへ単語を一部修正する
② テストを実行し、Givenのステップが実行されないことを確認
   rake cucumber
③ calculator_steps.rbのGivenの記述を一部修正
   calculatorからcalcへと単語を一部修正する
④ テストを実行し、グリーンになることを確認
   rake cucumber

● おわりに
cucumberのfeatureファイル、stepファイルについて簡単ながら解説しました。
テスト対象のファイルはlib/calucurator.rbに入っています。説明は省略しま
した。
次回も引き続き、featureファイル、stepファイルで、Scenario Outline:と 
Examples:を使った方法について説明します。(IENAGA)

● 参考
   http://cukes.info/

● 過去の連載
1) http://ObjectClub.jp/ml-arch/magazine/316.html
2) http://ObjectClub.jp/ml-arch/magazine/321.html
3) http://ObjectClub.jp/ml-arch/magazine/325.html
4) http://ObjectClub.jp/ml-arch/magazine/330.html
5) http://ObjectClub.jp/ml-arch/magazine/334.html
6) http://ObjectClub.jp/ml-arch/magazine/338.html
7) http://ObjectClub.jp/ml-arch/magazine/345.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記

こんにちは、編集人のナガタユウコです。先日、駅のちょっとした段差に気づ
かず、転んで足を捻挫してしまいました・・・。幸いそれほどひどくはなく、
湿布を貼ってやり過ごしているのですが、捻挫の痛みよりも、周りのみんなの
「もう若くないんだからムリせず休んだら？」「牛乳嫌いだから骨折してるか
もよ？ちゃんと検査したら？」という言葉の方が胸に刺さって痛かったです＞＜
心配するなら素直に心配してください！・・・というのは冗談で、心配してく
ださってありがたかったのと同時に、心配かけないように気をつけて元気でい
なくちゃな、と実感しました。(ナガタユウコ)

*** オブラブスタッフ自己紹介 ***
No.21 伊藤邦彦
( @Kunihiko_Ito817 )
はじめまして、新入社員の伊藤邦彦と申します。私は大学生の時に授業でプロ
グラムに出会いました。自分の書いたものが動くということに感動し、プログ
ラミングの楽しさを知りました。そして、UMLやMDAを知りソフトウェア工学を
学んできました。
今年初めて参加したオブジェクト倶楽部の夏イベントでは、学生時代に研究し
ていた内容を若人セッションで話しました。夏イベントでは、私の知らない話
が多くあり、またその内容も興味深いものばかりで、いい経験ができました。
私もみなさんに興味の持てる内容を発信していきたいと感じました。
まだまだ、未熟ですが多くのことを発信していけるよう努力いたしますので、
よろしくお願いします。(伊藤邦彦)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は         ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は   ⇒http://ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://ObjectClub.jp/
Copyright (c)2010 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.