De sign Stor ie s E xplor ing and Cr e ating Code fr om a Nar - PowerPoint PPT Presentation

De sign Stor ie s E xplor ing and Cr e ating Code fr om a Nar r ative Pe r spe c tive Ke vlin He nne y ke vlin@c ur br alan.c om @Ke vlinHe nne y

See http://programmer.97things.oreilly.com (also http://tinyurl.com/97tepsk ) and follow @97TEPSK

An Agile Vie w of De sign � L ook for war d � E stablish a c le ar vision of the whole � Appr oac h de sign in time - dr ive n, inc r e me ntal slic e s � Quantisation as use r stor ie s, use c ase s, othe r sc e nar io style s, fe atur e s, spike s, pr ogr amming e pisode s, e tc . � L ook for fe e dbac k � Be r e sponsive and r e ac tive

Quantum of F low (QoF ) quaff, v . To drink deeply; to take a long draught; also, to drink repeatedly in this manner. quaff, n . An act of quaffing, or the liquor quaffed; a deep draught. Oxford English Dictionary

Slic ing De sign ove r T ime � Str uc tur al de c omposition is one vie w of a syste m's de sign � E .g., a static vie w of c ode str uc tur e � T e mpor al de c omposition c onc e r ns how c ode is de ve lope d ove r time � Build by adding func tionally c omple te c apabilitie s base d ar ound usage goals � F r om use r stor ie s to patte r n stor ie s

Balanc ing Value and Risk � Pr ior ity me asur e s impor tanc e to a stake holde r , not ur ge nc y � Value c an be c onte xt se nsitive � Ke e p in mind that busine ss r isk is some thing to be manage d � It doe s not always manife st itse lf at the same time or in the same plac e as value or othe r me asur e s of pr ior ity

Goal- Str uc tur e d Slic ing � De ve lopme nt ste ps in te r ms of visible , func tionally c omple te slic e s � E .g., use c ase s, use r stor ie s, use r stor y maps, F DD fe atur e s and othe r sc e nar io- base d te c hnique s — e mphasis in e ac h c ase is diffe r e nt, but all ar e r e late d � E ac h slic e is anc hor e d in a goal and wor ks towar ds an outc ome � T he y c an be applie d r e c ur sive ly

"Vin on Point", Joseph D Carney

The new user story backlog is a map Jeff Patton http://www.agileproductdesign.com/blog/the_new_backlog.html

Re quir e me nt- Style d T e sting � It se e ms obvious that te sts should r e late to r e quir e me nts in some way � Also c ode - le ve l r e quir e me nts impose d on one pie c e of c ode by anothe r � But it is anothe r thing to use a r e quir e me nt- base d style for te sts � T e sts should de fine be haviour , not just pr od and poke at it � Applie s to unit as we ll as syste m te sts

public static boolean isLeapYear(int year) Procedural test structured in terms of the function being tested, but not in terms of its functionality: testIsLeapYear Tests partitioned in terms of the result of the function being tested: testNonLeapYears testLeapYears Propositional tests reflecting requirements and partitioned in terms of the problem domain (prefix with test_that if test is required as a prefix): yearsNotDivisibleBy4AreNotLeapYears years_not_divisible_by_4_are_not_leap_years yearsDivisibleBy4ButNotBy100AreLeapYears years_divisible_by_4_but_not_by_100_are_leap_years yearsDivisibleBy100ButNotBy400AreNotLeapYears years_divisible_by_100_but_not_by_400_are_not_leap_years yearsDivisibleBy400AreLeapYears years_divisible_by_400_are_leap_years

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. Refactor (verb): to restructure software by applying a series of refactorings without changing the observable behavior of the software. Martin Fowler, Refactoring

Functional Developmental Operational

class access_control { public: bool is_locked(const std::basic_string<char> &key) const { std::list<std::basic_string<char> >::const_iterator found = std::find(locked.begin(), locked.end(), key); return found != locked.end(); } bool lock(const std::basic_string<char> &key) { std::list<std::basic_string<char> >::iterator found = std::find(locked.begin(), locked.end(), key); if(found == locked.end()) { locked.insert(locked.end(), key); return true; } return false; } bool unlock(const std::basic_string<char> &key) { std::list<std::basic_string<char> >::iterator found = std::find(locked.begin(), locked.end(), key); if(found != locked.end()) { locked.erase(found); return true; } return false; } ... private: std::list<std::basic_string<char> > locked; ... };

class access_control { public: bool is_locked(const std::string &key) const { return std::count(locked.begin(), locked.end(), key) != 0; } bool lock(const std::string &key) { if(is_locked(key)) { return false; } else { locked.push_back(key); return true; } } bool unlock(const std::string &key) { const std::size_t old_size = locked.size(); locked.remove(key); return locked.size() != old_size; } ... private: std::list<std::string> locked; ... };

class access_control { public: bool is_locked(const std::string &key) const { return locked.count(key) != 0; } bool lock(const std::string &key) { return locked.insert(key).second; } bool unlock(const std::string &key) { return locked.erase(key); } ... private: std::set<std::string> locked; ... };

Using Unc e r tainty as a Dr ive r Confronted with two options, most people think that the most important thing to do is make a choice between them. In design (software or otherwise) it is not. The presence of two options is an indicator that you need to consider uncertainty in the design. Use the uncertainty as a driver to determine where you can defer commitment to details and where you can partition and abstract to reduce the significance of design decisions. Kevlin Henney " Use Uncertainty as a Driver"

Patterns � Patte r ns name and r e ason about r e c ur r ing de sign de c isions � De c isions may be implic it or e xplic it, c onsc ious or not � T he naming of a patte r n c ontr ibute s to de sign voc abular y � Patte r ns de sc r ibe d in te r ms of c onte xt, pr oble m for c e s, solution str uc tur e and c onse que nc e s

Inside the Inte r pr e te r Patte r n Context Object : ContextObject Command : Command Context Context Object : Client Composite : Component * Expression Client evaluate Command : Client Context Object : Owner Composite : Client Terminal NonTerminal Expression Expression evaluate evaluate Command : ConcreteCommand Command : ConcreteCommand Composite : Leaf Composite : Composite

Patte r n Usage in Classic JUnit «role» Command TestRunner Processor 1 Double Collecting * Dispatch Parameter Command «interface» Test TestResult run Template * Method 1 Observer TestCase TestSuite run setUp «interface» TestListener tearDown Composite

Pattern Stories � A patte r n stor y br ings out se que nc e of patte r ns in a de sign e xample � Captur e c onc e ptual nar r ative be hind a give n pie c e of de sign, whe the r a syste m in pr oduc tion or an illustr ative e xample � F or c e s and c onse que nc e s playe d out in or de r , e ac h de c ision illustr ate d c onc r e te ly

JUnit Storyboard

History rarely happens in the right order or at the right time, but the job of a historian is to make it appear as if it did. James Burke

POSA4 Warehouse Story

Pattern Sequences � A patte r n se que nc e c aptur e s the unde r lying nar r ative be hind a stor y � A se que nc e c an be de sc r ibe d and applie d inde pe nde nt of a patte r n stor y � Patte r n se que nc e s foc us on inc r e me ntal de ve lopme nt � Patte r n c ompounds ar e e xample s of name d, shor t se que nc e s � E .g., MVC, Pluggable F ac tor y

Inte r pr e te r 's Se que nc e � T he Inte r pr e te r patte r n c an be se e n as a patte r n c ompound � A r e c ur r ing se t of ove r lapping and inte r ac ting r ole s � It c an also be se e n as a se que nc e of patte r n applic ation � I.e ., 〈 Command , Conte xt Obje c t, Composite 〉

JUnit Storyboard Distilled � JUnit stor yboar d c an be summar ise d as a patte r n se que nc e � I.e ., 〈 Command , T e mplate Me thod, Colle c ting Par ame te r , Class Adapte r , , Composite 〉 Pluggable Se le c tor � A summar y of the se que nc e doe s not show how r ole s inte r ac t � E .g., what c lasse s play what r ole s in Composite

Pattern Languages � A patte r n language c onne c ts many patte r ns toge the r � Captur e s c onne c tions and possibilitie s be twe e n patte r ns, inc luding options, alte r native s and ne c e ssar y ste ps � T he r e may be many possible se que nc e s thr ough a language � A lone patte r n se que nc e c an be c onside r e d a nar r ow patte r n language