25. First, find out use cases by drawing use case diagram. Use case is a description of a
system's behaviour as it responds to a request that originates from outside that
system. The use case technique is used to capture a system's behavioural
requirements by detailing scenario-driven threads through the functional
requirements.
Then, start from one specific use case, identify top level user stories, which follows
the "As a <role>, I want <feature>, so that <motivation>.". Top level user story is too
big to implement, we need to split it into smaller user stories. User story is a
software system requirement formulated as one or two sentences in the everyday or
business language of the user.
29. Then we made :
*Cockburn-style Play Monopoly Main Success Scenario
Use Case Text
10 Player wants to StartNewGame?
20 Player MakeMove?
30 Player PerformsAction?
40 Player EndsTurn? (repeat steps 20-40 until game ends)
EXTENSIONS------------------
30a Player buys property This is only legal if the
property is available and player has enough money 1.
Player gives money to the bank 2. Board is updated to
reflect the change in property
30b Player pays rent This is only legal if the property is
owned by another player 1. System identifies who is the
owner of the field 2. Cash is transfered to the owner
30c Player is using a community card This is happening
in case the player has landed on a field requireging
usage of a community card
40a Active Player receives rent 1. System identifies who
is the owner of the land 2. Cash is transfered to the
owner
* Player sells a property
30. domain model, or Domain Object Model (DOM)
in problem solving and software engineering can
be thought of as a conceptual model of a system
which describes the various entities involved in
that system and their relationships.
31. Acceptance Tests (in Agile Software Development) are usually created by business
customers and expressed in a business domain language. These are high level tests to
test the completeness of a user story or stories 'played' during any sprint/iteration.
32. Activity Diagram
is a loosely
defined diagram
technique for
showing
workflows of
stepwise
activities and
actions, with
support for choise,
iteration and
concurrency.
34. Class Diagram is a type of static structure diagram that describes the structure of a
system by showing the system's classes, their attributes, and the relationships
between the classes.
37. * Having pseudo-acceptance-tests on the wall, it's
time to realize them now. The test automation
framework we used was www.robotframework.org.
which is a keyword-driven framework for
acceptance tests in tabular format.
* Acceptance Test Driven Development (ATDD)
practice drives development from automated
acceptance tests, those executable acceptance
tests. After written those pseudo tests into Robot
format, we got a red FAIL of execution, since there
was no keywords nor production code.
*
39. *Robot Tests
Setting Value
Library MonopolyLibrary
Post Condition: Post
Test IN: IN: Post Condition: Post Condition:
Action All Pieces Condition:
Case rounds Players Actual Rounds Output Trace
Current Square game Stop
Run The Game And
Test1 ${2} ${2} ${2} NOT goSquare TRUE NOT NULL
Check Post Conditions
Run The Game And
Test2 ${17} ${2} ${17} TRUE NOT NULL
Check Post Conditions
Keyword Action Argument Argument Argument Argument Argument Argument
Run The Game ${all pieces
${actual ${game ${output
And Check Post [Arguments] ${rounds} ${players} current
rounds} stop} trace}
Conditions square}
Init The Game ${rounds} ${players}
Run The Game
Get Actual
${testReturn}
Rounds
Should Be Equal ${actualRounds} ${testReturn}
45. * duplicate code or data
* long method
* unclear names
* magic constants
* high coupling (e.g., “data envy”)
* low cohesion
* case logic rather than polymorphism
* data object (record object)
*
* comments that explain what code does
http://en.wikipedia.org/wiki/Code_smell
70. * This work is licensed under the Creative
Commons Attribution-NonCommercial-NoDerivs
2.5 China Mainland License.
* To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-
nd/2.5/cn/ or send a letter to Creative
Commons, 444 Castro Street, Suite 900,
Mountain View, California, 94041, USA.
转载必须注明出处及作者。
本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可
