dSoftArk Noter Q2 2013-2014Mathias Skovgaard Birk, 20116447, DAT2

January 6, 2014

Contents1 Test-driven development 3

1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 TDD Rythm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 TDD Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 JUnit syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Fordele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6 Ulemper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.7 Perspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Systematic black-box testing 62.1 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Testing Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Partitioning Heuristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 EC Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Test Case Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Myers Rules for Valid/Invalid ECs . . . . . . . . . . . . . . . . . . . . . . 92.7 Boundary Value Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8 Conditions/Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.9 Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.10 Perspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Variability management 103.1 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Variabilitetspunkter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Variabilitetshandtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 Kildekodekopiering . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.2 Parametrisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.3 Polymorf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.4 Kompositionel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.4 3-1-2 Processen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 STRATEGY Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1

3.5.1 Roller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5.2 Fordele og ulemper . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6 ABSTRACT FACTORY Pattern . . . . . . . . . . . . . . . . . . . . . . . 143.6.1 Roller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.6.2 Fordele og ulemper . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Test stubs and unit/integration testing 154.1 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Test stub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3 Kommentar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4 Keypoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Design patterns 175.1 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.2 The 3-1-2 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.3 Design Patterns komponenter . . . . . . . . . . . . . . . . . . . . . . . . . 185.4 Roles, Responibility, Protocols . . . . . . . . . . . . . . . . . . . . . . . . 195.5 Pattern Fragility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 Compositional design 20

7 Frameworks 20

8 Patterns 208.1 Konstruktrer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8.1.1 Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208.1.2 Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

8.2 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218.2.1 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218.2.2 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.2.3 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.2.4 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.2.5 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.2.6 Null Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248.2.7 Model View Controller . . . . . . . . . . . . . . . . . . . . . . . . . 24

8.3 Opfrsel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258.3.1 Command-Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 258.3.2 Iterator-Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258.3.3 Observer-Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268.3.4 State-Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268.3.5 Strategy-Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278.3.6 Template-method-Pattern . . . . . . . . . . . . . . . . . . . . . . . 27

2

1 Test-driven developmentEmphasis on applying the rhythm and using/understanding the values and TDD princi-ples.

1.1 DefinitionsDef. Testing Testing is the process of executing software in order to find failures.

Def. Failure A failure is the situation in which the behavior of the executing softwaredeviates from what is expected.

Def. Defect A defect is the algorithmic cause of a failure: some code logic that isincorrectly implemented.

Def. Test case A test case is a definition of input values and expected output valuesfor the unit under test.

Def. Unit under test (UUT) The unit under test is some part of the system thatwe consider to be a whole.

Def. Unit Testing Unit testing is the process of executing a software unit in isolationin order to find failures in the unit itself.

Def. Integration Test Integration testing is the process of executing a software unitin collaboration with other units in order to find failures in their interactions.

Def. Refactoring Refactoring is the process of changing a software system in such away, that it does not alter the external behavior of the code, yet improves itsinternal structure.

Def. Direct input Direct input is values or data, provided directly by the testing code,that affect the behaviour of the unit under test (UUT).

Def. Indirect input Indirect input is values or data, that cannot be provided directlyby the testing code, that affect the behaviour of the unit under test (UUT).

Def. Depended-On Unit (DOU) A unit in the production code that provides val-ues or behaviour that affect the behaviour of the unit under test. NOTE: Detterelaterer sig til Test-stubs, hvor DOUen f.eks. er et ur eller en random generatorder i produktionen giver input der varierer.

Def. Test Stub A test stub is a replacement of a real depended-on unit (DOU) thatfeeds indirect input, defined by the test code, into the unit under test (UUT).

3

1.2 TDD Rythm1. Quickly add a test.

2. Run all tests and see the new test fail

3. Make a little change

4. Run all tests and see them all succeed

5. Refactor to remove duplication

6. (Run all tests again to check refactoring!)

Man tilfjer altsa en test i forhold til sin testliste, krer testen og ser den fejle (forat sikre at ens test rent faktisk tester noget - er man i tvivl kan man altid kre enassertTrue(false) for at se at testen kres). Dernst laves mindst mulige ndringer iproduktionskoden - SMA SKRIDT - for at se at det virker. Herefter kres tests igen,og endeligt refaktoriseres det hele for at opna clean code. Kr sa alle tests igen for atkontrollere at refaktoriseringen ikke har ndret pa kodens opfrsel. Sidste skridt er paen made en del af regression testing, dvs. det at kre alle test cases ofte, for at sikreat systemets opfrsel ikke har ndret sig - det er det der er fordelen ved automatiseredetests over manuelle.

1.3 TDD PrinciplesTest First: When should you write your tests? Before you write the code that is to be

tested.

Test List: What should you test? Before you begin, write a list of all the tests youknow you will have to write. Add to it as you find new potential tests.

One Step Test: Which test should you pick next from the test list? Pick a test thatwill teach you something and that you are confident you can implement.

Isolated Test: How should the running of tests affect one another? Not at all.

Evident Tests: How do we avoid writing defective tests? By keeping the testing codeevident, readable and as simple as possible.

Fake It (Till You Make It): What is your first implementation once you have a bro-ken test? Return a constant. Once you have your tests running, gradually trans-form it.

Triangulation: How do you most conservatively drive abstraction with tests? Abstractonly when you have two or more examples.

Assert First: When should you write the asserts? Try writing them first.

4

Evident Data: How do you represent the intent of the data? Include expected andactual results in the test itself, and make their relationship apparent. You arewriting tests for the reader, not just for the computer.

Obvious Implementation: How do you implement simple operations? Just imple-ment them.

Representative Data: What data do you use for your tests? Select a small set ofdata where each element represents a conceptual aspect or special computationalprocessing.

Automated Test: How do you test your software? Write an automated test.

Test Data: What data do you use for test-first tests? Use data that makes the testseasy to read and follow. If there is a difference in the data, then it should bemeaningful. If there isnt a conceptual difference between 1 and 2, use 1.

Child Test: How do you get a test case running that turns out to be too big? Write asmaller test case that represents the broken part of the bigger test case. Get thesmaller test case running. Reintroduce the larger test case.

Regression Test: What is the first thing you do when a defect is reported? Write thesmallest possible test that fails and that, once run, will be repaired.

Det skal siges, at hvis man bruger Fake It, br man efter brugen skrive en ny testtil ens test list. Denne test skal saledes tvinge implementationen af Fake It til at blivefuldendt. Et eksempel pa sadan en fremgangsmade er Triangulation, hvor man udviderkravet til algoritmen, saledes det at returnere en konstant ikke lngere er godt nok.

Desuden er der to andre vigtige principper, der dog ikke kun knytter sig til TDD,men udvikling generelt:

Break: What do you do when you feel tired or stuck? Take a break.

Do Over: What do you do when you are feeling lost? Throw away the code and startover.

1.4 JUnit syntaxHusk import-statements:import org.junit.*;import static org.junit.Assert.*;

Assertion-metoder:

assertTrue assertFalse

5

assertNull assertNotNull assertEquals

Muligt at bruge String-parameter til beskrivelse, ex: assertTrue(Br vre sandt, true);

Brug @Test til at markere en test-metode

Brug @Before til at markere en opstningsmetode, der kres inden hver eneste test(fixture).

1.5 Fordele Ren (vedligeholdbar/maintainable) kode, som virker (trovrdig/reliable) Hurtigt feedback giver programmren selvtillid (ved fejl ved man altid, at fejlen

ligger i skridtet fr)

Trovrdig/reliable software (pga. testcases) Kun nsket opfrsel programmeres (da vi kun programmerer det testene krver) Ingen driver-kode da vi har testcases Struktureret programmeringsproces

1.6 UlemperHvis interfaces af en grund skal ndres, sa skal alle tests ndres. Tests skal holdessimple, ellers er de vrdilse for lseren.

1.7 PerspektivTDD star i relation til integration testing, test stubs, black-box testing, og god-software (flexible, reliable).

2 Systematic black-box testingEmphasis on applying and understanding equivalence partitioning techniques and bound-ary value analysis.

2.1 DefinitionerDef. Systematic testing Systematic testing is a planned and systematic process with

the explicit goal of finding defects in some well-defined part of the system.

6

Def. Testing Testing is the process of executing software in order to find failures.

Def. Failure A failure is the situation in which the behavior of the executing softwaredeviates from what is expected.

Def. Defect A defect is the algorithmic cause of a failure: some code logic that isincorrectly implemented.

Def. Test case A test case is a definition of input values and expected output valuesfor the unit under test.

Def. Unit under test (UUT) The unit under test is some part of the system thatwe consider to be a whole.

Def. Black-box testing The UUT is treated as a black box. The only knowledge wehave to guide our testing is the specification of the UUT and a general knowledgeof common programming techniques and algorithmic constructs.

Def. White-box testing The full implementation of the UUT is known, so the actualcode can be inspected in order to generate test cases.

Def. Equivalence class (EC) A subset of all possible inputs to the UUT, that hasthe property that if one element in the subset demonstrates a defect during testing,then we assume that all other elements in the subset will demonstrate the samedefect.

Def. Soundness For a set of equivalence classes to be sound, the ECs most uphold thecriteria of Coverage, Representation and Disjointness.

Def. Coverage Every possible input belongs to one of the equivalence classes.

Def. Representation If a failure is demonstrated on a particular member of an equiv-alence class, the same failure is demonstrated by any other member of that class.

Def. Disjointness No input belongs to more than one equivalence class.

Myers rule for valid ECs Until all valid partitions have been covered, define a newEC (and test-case) covering as many uncovered valid partitions as possible.

Myers rule for invalid ECs Until all invalid partitions have been covered, define anew EC (and testcase) that covers one, and only one, of the uncovered invalidpartitions.

2.2 Testing ApproachesNo testing: Meget sma metoder kan ikke betale sig at teste, da deres funktionalitet er

sa simpel at testkoden bliver strre end produktionskoden. Dette drejer sig f.eks.om getters/setters.

7

Explorative testing: Explorative testing gar ud pa at bruge intuition og erfaring tilat teste. Denne stil kan vre meget nyttig ved middelkomplekse metoder og erbl.a. ogsa den mest dominante stilart bag TDD.

Systematic testing: Systematisk testing bruges nar vi har at gre med meget kom-plekse metoder, eller metoder med en meget lav fejltolerance (software til rum-faretjer f.eks.). Her finder vi, pa systematisk vis, kvivalensklasser for de condi-tions der pavirker systemet og bygger vore test-cases op pa baggrund af disse.

2.3 Partitioning HeuristicsBasalt set skal vi blot (re)partitionere ECs hver gang man er i tvivl om hvorvidtReprsentationsprincippet er overholdt. Man deler ofte op i gyldige og ugyldige ECs,afhngigt af gyldigheden af input. Men gyldigt input kan ogsa vre ugyldigt, hvis detfx betyder at metoden bailer ud (fx en if stning i starten af en metode).

En god made at partitionere sine kvivalensklasser pa, er ved at kigge efter betingelser/-conditions i specifikationen af UUTen. Givet en betingelse kan man udlede ECs vedflgende guidelines:

Range If a condition is specified as a range of values, select one valid EC that coversthe allowed range, and two invalid ECs, one above and one below the end of therange.

Set If a condition is specified as a set of values then define an EC for each value in theset and one EC containing all elements outside the set.

Boolean If a condition is specified as a must be condition then define one EC for thecondition being true and one EC for the condition being false.

2.4 EC TableEt eksempel pa en EC tabel ses her:

Figure 1

2.5 Test Case TableEt eksempel pa en test case table ses her:

8

Figure 2

2.6 Myers Rules for Valid/Invalid ECsMan kan danne test cases fra sine ECs ved hjlp af Myers regler.

1. Indtil alle gyldige ECs er dkket, definer sa en test case der dkker sa mangeikke-dkkede gyldige ECs som muligt.

2. Indtil alle ugyldige ECs er blevet dkket, definer sa en test case hvis element kunligger i en enkelt ugyldig EC. Der ma kun vre en for at undga masking.

Herudover er det meget godt at lave tests, som ligger lige pa grnsen, boundaryanalysis tre for hver grnse. Sa der sikres, at der findes dumme programmr-fejl, hvorder fx mangler en = i en if-stning.

2.7 Boundary Value AnalysisBoundary Value Analysis gar ud pa vlge test data pa begge sider af grnserne mellemkvivalensklasser. Hvis en valid EC range gar fra 1-5, sa ville man teste ved 0, 1, 5 og6. Kombineres med systematisk testing, men bruges egentlig ogsa indirekte ved TDDnar man vlger test data.

2.8 Conditions/ParametersDet er ikke nok at kigge pa parameetrene til den metode man tester. Man er ndt til atkigge pa betingelser/conditions fremfor parametre.

2.9 Key points Test ikke pa preconditions. Test ikke pa overdrevet dum software. Partitionering af ECs kan ikke forudsige

dumme programmrer og easter-eggs.

Myers heuristics skal bruges velovervejet og ikke ukritisk.

9

2.10 PerspektivTDD og god-software (flexible, reliable).

3 Variability managementEmphasis on applying the four different techniques for handling variability and analysingtheir benefits and liabilities.

3.1 DefinitionerDef. Change by modification Change by modification is when software changes are

introduced by modifying existing production code.

Def. Code bloat Code bloat is the production of code that is perceived as unneces-sarily long, slow or otherwise wasteful of resources.

Def. Switch creep Switch creep is the tendency that conditional statements becomemore and more complex as software ages.

Def. Change by addition Change by addition is when software changes are intro-duced by adding new production code instead of modifying existing.

Def. Flexibility The capability of the software product to support added/enhancedfunctionality purely by adding software units and specifically not by modifyingexisting software units.

Def. Maintainability (ISO 9126) The capability of the software product to be mod-ified. Modifications may include corrections, improvements or adaptation of thesoftware to changes in environment, and in requirements and functional specifica-tions.

Def. Analysability (ISO 9126) The capability of the software product to be diag-nosed for deficiencies or causes of failures in the software, or for the parts to bemodified to be identified.

Def. Changeability (ISO 9126) The capability of the software product to enable aspecified modification to be implemented.

Def. Stability (ISO 9126) The capability of the software product to avoid unex-pected effects from modifications of the system.

Def. Testability (ISO 9126) The capability of the software product to enable mod-ified system to be validated.

10

3.2 VariabilitetspunkterEt variabilitetspunkt er en sektion af kode der skal variere. Vi bruger dette nar vi skallave en eller anden form for genbrug, enten i form af ekstra krav til funktionaliteten (e.g.algoritmen skal vre anderledes hver lrdag nat) eller hvis nye kunder vil have sammeprodukt med en lille ndring.

3.3 Variabilitetshandtering3.3.1 Kildekodekopiering

Den groveste lsning er at lave direkte source code copy og sa kun ndre det lille stedhvor variationen er nsket. Fordele og ulemper er:

Fordele:

Simpelt Hurtigt Afkobler varianter fuldstndigt (decoupling)

Ulemper:

Vedligeholdelsen af flere systemer er besvrlig - Multiple maintenance problem Besvrligt at ndre fejl i en variant, hvis fejlen er i kode som varianter har tilflles.

Fejlen skal rettes i alle varianter.

Varianterne glider fra hinanden, og ender som forskellige produkter

3.3.2 Parametrisk

En anden lsning er at styre varianterne vha. If eller Switch statements i koden. Fordeleog ulemper er her:

Fordele:

Simpelt Intet Multiple maintenance problem

Ulemper:

Change by modification med stor risiko for at introducere fejl i gammel kode. Code bloat (Hvis der er 43 varianter bliver det meget uoverskueligt) Darlig analysability/readability - ifs pa ifs pa ifs. Cohesion-problem med ansvarstilfjelse - nu far den specifikke klasse pludseligt

ansvar for ogsa at handtere varianter.

11

3.3.3 Polymorf

En tredje lsning er at styre varianter ved at extende klasser og override de metoderman nsker. Fordele og ulemper er her:

Fordele:

Intet Multiple maintenance problem Kun Change by modification frste gang, hvorefter det er Change by addition

for hver subclass

Nemt at lseUlemper:

Forhjet antal klasser Kan kun nedarve fra en klasse (C# og Java), hvorfor genbrug henover varianter er

svrt

Objekter bindes pa compile-time (variant kan ikke ndres pa run-time)

3.3.4 Kompositionel

En fjerde og foretrukken lsning er at styre varianter ved at delegere varianten til sinegen abstraktion i form af et interface, der sttes sammen med produkterne. Fordele ogulemper er her:

Fordele:

Nemt at lse Run-time binding Seperation af ansvar Seperation af tests Variant vlges kun et sted og er nemt at finde Nedarvning mulig hvis behovet opstar Change by addition, palideligt/reliable

Ulemper:

Forhjet antal interfaces og klasser Brugerne skal vre bekendt med lsningen og alle dets forskellige uddelegeringer.

12

3.4 3-1-2 Processen3-1-2 processen er en generel opskrift pa god handtering af variabilitet:

1. Identificer en opfrsel/operation der varierer

2. Udtrk et ansvar der omfatter denne operation, og udtryk den i et interface

3. Udfr nu denne operation ved at delegere opgaven til en konkret implementationaf interfacet, der er en variant af operationen.

Kommer af:

1. Programmer op mod et interface, ikke implementation

2. Vlg objektkomposition over klassenedarvning

3. Overvej hvad der skal variere i dit design, og indkapsl den varierende opfrsel

3.5 STRATEGY PatternStrategy mnsteret er et af de bedste design mnstre til at handtere variationer.

Figure 3

3.5.1 Roller

Strategy: Specificerer ansvaret og interfacet for algoritmen

ConcreteStrategy: Definerer den konkrete operation der udfylder ansvaret

Context: Udfrer arbejdet for Client ved at uddelegere til en strategi

13

3.5.2 Fordele og ulemper

Fordele:

Strategier eleminerer conditional statements Undga subklasser Undga multiple maintenance Change by addition, ikke modification Gr seperat testing af Context og Strategy muligt

Ulemper:

Forhjet antal objekter Klienter skal kende strategierne Et mindre resourcetab uddelegering

3.6 ABSTRACT FACTORY PatternAbstract Factory kan bruges til at samle konstruktionen af varianter et sted og styre detved at lade factories samle komponenter til et samlet produkt.

Figure 4

14

3.6.1 Roller

Abstract Factory: Definerer et flles interface for objektoprettelse

ProductX: Definerer interfaces for et objekt ConcreteProductXY (produkt X i variantY)

ConcreteFactoryY: Er ansvarlig for at oprette Products der tilhrer en variant Y, derer en familie af objekter som er konsistente med hinanden.

3.6.2 Fordele og ulemper

Fordele:

Lav kobling mellem klient og produkter Gr udskiftning af produktfamilier let Frembringer konsistens mellem produkter Change by addition, ikke modification Klientens konstruktrs parameterliste forbliver intakt

Ulemper:

Introducerer ekstra klasser og objekter Understttelser af nye aspekter i variation er svrt - krver ndring i alle konkrete

factories

4 Test stubs and unit/integration testingEmphasis on applying test stubs and understanding the testing levels of unit/integra-tion/system testing.

4.1 DefinitionerDirect input Direct input is values or data, provided directly by the testing code, that

affect the behavior of the unit under test (UUT).

Indirect input Indirect input is values or data, that cannot be provided directly bythe testing code, that affect the behavior of the unit under test (UUT).

Depended-on unit (DOU) A unit in the production code that provides values orbehavior that affect the behavior of the unit under test.

Test stub A test stub is a replacement of a real depended-on unit that feeds indirectinput, defined by the test code, into the unit under test.

15

Figure 5

Unit under test A unit under test is some part of a system that we consider to be awhole.

Unit test Unit testing is the process of executing a software unit in isolation in orderto find defects in the unit itself.

Integration test Integration testing is the process of executing a software unit in col-laboration with other units in order to find defects in their interactions.

System test System testing is the process of executing the whole software system inorder to find deviations from the specified requirements.

Test stub Fa indirekte input under kontrol.

Test spy Indirekte output optages for at kontrollere om UUT giver de rigtige kom-mandoer.

Mock objekt A double, created and programmed dynamically by a mock library, thatmay both serve as a stub and spy.

Fake objekt En hurtig men realistisk erstating (nar UUT-DOU er langsom). A doublewhose purpose is to be a high performance replacement for a slow or expensiveDOU.

4.2 Test stub4.3 KommentarMan skal vide, hvornar man ikke skal teste fx br man stole pa at firmaer som Sun ogMicrosoft selv tester, deres software.

16

4.4 KeypointsMany software units depend on indirect input that influence their behavior. Typicalindirect input are external resources like hardware sensors, random-number generators,system clocks, etc. Test stubs replace the real units and allow the testing code to controlthe indirect input.

5 Design patternsEmphasis on finding the proper design pattern for a problem at hand and applying it.

5.1 DefinitionerDef. Software Architecture The software architecture of a computing system is the

structures of the system, which comprise software elements, the externally visibleproperties of those elements and the relationships among them.

Def. Design Pattern A design pattern is defined by a set of roles, each role having aspecific set of responsibilities, and by a well defined protocol (interaction pattern)between these roles.

Def. Design Pattern (Gamma et al.) Patterns are descriptions of communicatingobjects and classes that are customized to solve a general design problem in aparticular context.

Def. Design Pattern (Beck et al.) A design pattern is a particular prose form ofrecording design information such that designs which have worked well in the pastcan be applied again in similar situations in the future.NOTE: prose form betyder template og denne template indeholder som min.altid: Name, Problem, Solution og Consequences.

Def. Pattern Fragility Pattern fragility is the property of design patterns, that theirbenefits can only be fully utilized if the patterns object structure and protocol isimplemented correctly.

Def. Coupling Coupling is a measure of how strongly dependent one software unit ison other software units.

Def. Cohesion Cohesion is a measure of how strongly related and focused the respon-sibilities of a software unit is.

Law of Demeter Do not collaborate with indirect objects.NOTE: Also called Dont Talk to Strangers

Def. Object Orientation (Nygaard m.fl.) A program execution is viewed as a phys-ical model simulating the behaviour of either a real or imaginary part of the world.NOTE: Desuden kendt som Model-centric focus

17

Def. Object Orientation (Budd) An object-oriented program is structured as a com-munity of interacting agents called objects. Each object has a role to play. Eachobject provides a service or performs an action that is used by other members ofthe community.NOTE: Desuden kendt som Responsibility-centric focus

Def. Responsibility The state of being accountable and dependable to answer a re-quest.

Def. Protocol A convention detailing the expected sequence of interactions or actionsexpected by a set of roles.

Def. Role (Software) A set of responsibilities and associated protocol with associatedroles.

5.2 The 3-1-2 Process3-1-2 processen er en generel opskrift pa at handtere variationer pa forskellig vis. Denlyder saledes:3. Identificer en operation der vil variere1. Skab en responsibility der omfatter denne operation og udtryk den i et interface.2. Udfr nu denne operation ved at delegere opgaven til et underordnet objekt der im-plementerer interfacet.

5.3 Design Patterns komponenterDesign patterns defineres pa flere forskellige mader, men den vi flger her er:

Def. Design Pattern A design pattern is defined by a set of roles, each role having aspecific set of responsibilities, and by a well defined protocol (interaction pattern)between these roles.

Vi bruger patterns til at implementere forskellige best-practice designkomponenterfor at opna en eller anden Quality (typisk fleksibilitet og maintainability). Et designpattern er typisk beskrevet ved minimum 4 ting:

1. Et navn (Name)

2. Et problem patternet lser (Problem)

3. En lsning (Solution)

4. Konsekvenserne af lsningen (Consequences)I bogen indeholder de fleste patterns ogsa en betegnelse af roller (Roles), et UML

diagram (Structure) og en hensigt med patternet (Intent).

18

5.4 Roles, Responibility, ProtocolsPatterns er bygget op af Roles, Responsibilities for disse Roles og deres interne kommu-nikation (Protocols). Lad os definere disse tre termer:

Def. Role (Software) A set of responsibilities and associated protocol with associatedroles.

Def. Responibility The state of being accountable and dependable to answer a re-quest.

Def. Protocol A convention detailing the expected sequence of interactions or actionsexpected by a set of roles.

UML kan ikke vise roller, sa det er derfor vigtigt at vurdere patterns ikke ud fra deresdiagrammer, men ud fra deres Intent og Roles med dertil hrende Responsibilities ogProtocols.

5.5 Pattern FragilityPatterns er en made at opna et mal pa og ikke et mal i sig selv! Et forkert implementeretpattern kan derfor lede til at man far alle ulemperne ved det pagldende Pattern ogingen af dets fordele. Pattern Fragility defineres som:

Def. Pattern Fragility Pattern fragility is the property of design patterns, that theirbenefits can only be fully utilized if the patterns object structure and protocol isimplemented correctly.

Typiske fejl er:

1. Brug af klassenavne ved deklaration fremfor interfacenavn

2. Binding til klasse pa et forkert tidspunkt (i.e. et sted hvor man ikke kan variereklassen)

3. Pga. stress eller deadlines laver man et hurtigt fix til noget variability (typisk medparametre)

19

6 Compositional designEmphasis on applying compositional design principles and relating it to concepts behav-ior, responsibilities, roles, and multi-dimensional variance.

7 FrameworksEmphasis on designing frameworks and understanding framework theory.

8 PatternsI denne sektion vil de forskellige design mnstre vre reprsenteret, hvor der blandtandet er brugt UML-diagrammer til at illustrere de forskellige mnstre.

8.1 Konstruktrer8.1.1 Abstract Factory

s. 217

20

8.1.2 Builder

s. 301

8.2 Struktur8.2.1 Adapter

s. 295

21

8.2.2 Composite

s. 322

8.2.3 Decorator

s. 289

22

8.2.4 Facade

s. 282

8.2.5 Proxy

s. 317

23

8.2.6 Null Object

s. 325

8.2.7 Model View Controller

Define a loosely coupled design to form the architecture of graphical user interfaces havingmultiple windows and handling user input from mouse, key- board,or other input sources.s. 342

24

8.3 Opfrsel8.3.1 Command-Pattern

s. 308

8.3.2 Iterator-Pattern

s. 312

25

8.3.3 Observer-Pattern

s. 335

8.3.4 State-Pattern

s. 185

26

8.3.5 Strategy-Pattern

s. 130

8.3.6 Template-method-Pattern

s. 366

27