Software arkitektur. Tobias Brixen Q2-2012

Transkript

1 Software arkitektur Tobias Brixen Q

2 Contents 0.1 Diverse defs Test-driven development Motivation Koncepter Rythm Values Principles s Systematic black-box testing Koncepter Definitions EC partitionering Variability management Koncepter The four techniques s Test stubs and unit/integration testing Koncepter Design patterens Koncepter Compositional design Koncepter Hvad er et objekt? The four techniques Frameworks Koncepter Page 2

3 0.1 Diverse defs Reliability Evnen til at opretholde et niveau af performance når brugt under specificerede betingelser Flexibility Change by addition, not by modification. Evnen for softwaren at blive tilføjet/enhanced funktionalitet rent ved tilføjelse af softwareunits og ikke ved modifikation af eksisterende Failure En fejl er når opførslen af programmet afviger fra det forventede Defect En defect er den algoritmiske grund til en fejl: noget kodelogik der er forkert implementeret Unit Under Test helhed. Law of Demeter En unit unit test et en del af et system vi ser som en Lad være med at lave en lang commandchain. Coupling Hvor stærkt koblede softwareunits er ifht. til hinanden. Man går normalt efter en lav kobling. Cohesion Being organized. Kohærens/sammenhæng. Høj kohærens betyder at have de rigtige skuffer, og putte de rigtige ting i de skuffer. 1 Test-driven development Emphasis on applying the rhythm and using/understanding the values and TDD principles. 1.1 Motivation TDD fokuserer på at skabe reliable og maintainable (sek 1.4) software. Tag små skridt og holde fokus for at koncentrere sig om at implementere en ting ad gangen, og tage små skridt for ikke at implementere kode der ikke bliver brugt. Der bliver brugt en rytme for hver iteration, og undervejs bruges nogle principper for at holde koden reliable og maintainable. Fordele er tiltro til ens kode når alle tests passer; høj fokus på reliability og maintainability af koden, samt rytmen og principperne der hjælper til at strukturere koden. 1.2 Koncepter Rythm Values Maintainability (s. 30) Analysability Page 3

4 Principles Refactoring... Changeability Stability Testability Clean code that works Fast feedback gives the programmer confidence Strong focus on reliable software Playing with the interface from the client s side (Morvirker at man implementere kode der ikke bliver brugt) Testcases er en form for dokumentation af klasser og større softwareunits Ingen driver kode Struktureret programmerings process 1.3 Rythm 1 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 dublication Man tilføjer en test fra sin testlise, og kører alle tests for at sikre sig at den uimplementerede test fejler. Man laver mindst mulig kode for at få koden til at passe. Så refaktoriserer man for at få clean code, og kører test igen for at sikre sig at man ikke har ødelagt noget. Def: Refactoring Refaktorering er processen hvor man modificerer og rekonstruerer kildekoden for at forbedre maintainabiliy og fleksibiliteten uden af ændre i systemes eksterne opførsel. Page 4

5 1.4 Values Simplicity Keep focus Take small steps Maintainability (s. 30) - Evnen til af et stykke software kan ændres. Analysability - Understandig the software Changeability - Add, modifying the software without large cost. e.g. no constants Stability - Avoid unexpected errors from minor changes. Testability - Enable a modified system to be tested 1.5 Principles s. 51 Test first Skriv test s før koden bliver skrevet Automated Test Vi tester vha. automatiske tests Test list Skriv en liste over alle de tests du ved du skal lave. Tilføj til den når der er potentielt nye tests One step test Vælg den test som vil lære dig noget og som du føler dig sikker på du kan implementere. Fake it (until you make it) Retuner en konstant. Triangulering Pas - måske: gå kun videre når du har lavet 2-3 tests og dermed fået fjernet fake it implementationne Isolated test Evident Data De forskellige tests skal ikke påvirke hinanden Formålet med testdata skal være evident/klar Representative Data som uniten udfører. Vælg data så de rammer forskellige dele af konceptet Evident Test Hvordan undgår vi at skrive defekte tests? Ved at holde testkoden læselig og så simpel som mulig. Assert First Når testsignaturen er skrevet, skriv da asserts. Du ved hvad du vil teste, og herefter hjælper IDE en med at sætte fake-it klasser op. Hvad gør vi med simple operationer? Vi imple- Obvious Implementation menterer dem bare Page 5

6 Break Hvad gør vi når vi føler os trætte og ramt? Holder en pause 2 Systematic black-box testing Emphasis on applying and understanding equivalence partitioning techniques and boundary value analysis. Motivation 2.1 Koncepter Start 2.2 Definitions A failure is the situration where the system s behaviour deviates from the expected, and is caused by a defect in the production code. Vi har derfor en teknik der hedder systematisk testing til at finde defects. Def: Systematic testing Systematisk testing er en planlagt og systematisk process med det præcise formål at finde defects i en veldefineret del af systemey Def: Black-box testing Unit under test (UUT) er som en sort box. Det eneste som kan guide for testing er specifikationen af UUT en, og generel kendskab til almindelige programmerings teknikker, algoritmiske kontruktioner, og almindelige fejl lavet af programmører. Def: White-box testing Vi kender den fulde implementation er UUT en; altså koden kan blive inspiceret for at generere tests. Testingstrategier: 1) No testing - Simple metoder: Accessor metoder; testkoden vil blive længere end implementationen 2) Eksplorativ testing - mavefornemmelse. Til mediumkomplekse units. Low cost. TDD er basically eksplorativ testing 3) Systematic testing - Til højkomplekse units eller systemer hvor reliability er vigtig. Her følges en metode for at højne sandsynligheden for at finde en defect. High cost. Def: Equivalence class (EC) Et subset af alle input, hvor det antages at et element i dette subset demonstrerer samme defekt som alle andre elementer i sættet. Valid EC er de elementer som bliver proceseret normalt Page 6

7 Invalid EC er de element som kræver specialbehandling, som kaster exceptions, returnerer en udefineret value, eller på anden måde resultere i abnormal processering Soundness For at en ECer sound, skal den opfylde coverage, representation og disjointness. Coverage Alle mulige input elementer tilhører en EC Representation Hvis en defekt er demonstreret af et medlem af en klasse, bliver den samme defekt demonstreret af alle andre elementer i samme klasse. Disjointness Intet input tilhører mere end én EC Boundary value En value der ligger tæt på kanten af en EC Range: Tag en over imellem og over. Sæt: Et EC for hver value, og en udenfor. Boolean: En EC for hhv true og false. 2.3 EC partitionering Equivalance class table Condition Invalid ECs Valid ECs From Position < 0[1]; > worldsize[2] 0 worldsize[3] To Position < 0[4]; > worldsize[5] 0 worldsize[6]; Extended test case table EC s Covered Test Case Expected output [3], [6], [8] (1, 1, 2, 1) and Plains legal [3], [6], [7] (1, 1, 2, 1) and Butter illegal [1], [6], [8] ( 1, 1, 1, 1) and Plains illegal [2], [6], [8] (16, 17, 16, 16) and Plains illegal [3], [4], [8] (1, 1, 1, 1) and Plains illegal [3], [5], [8] (16, 16, 16, 17) and Plains illegal Masking Meyers er til for at undgå masking. Her passer den testen med (, 0), hvor implementationen burde have været row < 1. public class ChessBoard { public boolean v a l i d ( char column, int row ) { i f ( column < a ) { return f a l s e ; } i f ( row < 0 ) { return f a l s e ; } return true ; } } Page 7

8 3 Variability management Emphasis on applying the four different techniques for handling variability and analysing their benefits and liabilities. Motivation Variabilitet er mange gange et krav til software. Enten fra fra kunders krav, og selv der til sælge forskellige varianter af software, eller at vi skal have mulighed for at teste på hardware vi ikke kan teste på (test stubs). Det er her vigtig at genbruge kode. Løsningen plejer at komme fra processen. 3.1 Koncepter GoF 1 Program to an interface, not an implementation 2 Favor object composition over class inheritance 3 Consider what should be variable in your design (or: Encapsulate the behaviour that varies) : Identificér variabilitetspunktet. 2: abstrahér ansvaret ud til et interface. 3: Delegerer ud, for at compose den fulde opførsel. Def: Variability Point Et variabilitetspunkt er en veldefineret sektion af produktionskoden hvis opførsel skulle kunne variere. Def: Change by modification er opførselsændring der er introduceret i eksiterende produktionskode. Def: Change by addition er opførselsændring introduceret ved at tilføje nye produktionskode i stedet for at ændre eksisterende. 3.2 The four techniques s. 111 Source Code Copy Fordele Hastighed Lav en kopi af hele sourcen. Simpel - Det er nemt at forklare medprogrammører Ingen indblanding - Hvis man laver en fejl i den ene, er den anden ikke affected. Ulemper Multiple maintenance problem Page 8

9 Parametric Fordele En parameter med if-statements der brancher Simpelt - Nemt at forstå; alle programmører kender if s Ingen multiple maintenance - Én kodebase Ulemper Polymorphic Fordele Reliability - Det er change by modification = introduktion af nye defects Analyzability concern - Des flere variabilitetspunter, des mindre overblik Responsibility erotion (God class) - PayStationImpl skal nu også handle udregningsstrategier. Jeg nedarver og overrider metoden der skal variere. Ingen multiple maintenance problemer - Kun én kodebase Reliability - Kodebasen er én gang for alle blevet forberedt til variabilitet Code analyzability - 43ende giver ikke codebloat. Ulemper Højt antal af klasser Vi har brugt vores eneste nedarvning (i hvert fald i java) Codereuse i varianter svært Compile-time binding Compositional Jeg beskriver det varierene i et interface, og lader min paystation kalde på interfacet. Fordele Reliability: Koden er, én gang for alle, gjort klar nye variabiliteter Run-time binding Seperation of responsibilities Seperation of testing - rateudregning og core paystation kan blive testet hver for sig. Variant selection in one place - Det er kun når man kalder paystaion at det bliver bestemt Combinatorisk - Vi kan implementere flere interfaces, ie. strategier; modsat nedarvning. Ulemper Højt antal klasser Clienter skal kender strategier - Variant seelction er flyttet til client objekter. Page 9

10 4 Test stubs and unit/integration testing Emphasis on applying test stubs and understanding the testing levels of unit/integration/system testing. Motivation Når vi skal teste ting vi ikke har kontrol over (e.g. Math.rand, hardwaremotor) kan vi bruge teststubbe (el. doubles fra Meszaros s. 192). Teststubbe implementerer samme interface som vores DOU, og alt efter om det er testing eller produktion kan vi parse det rigtige objekt med. 4.1 Koncepter Unit test (Vi tester en unit på en returværdi / testing software in isolation) UUT (Unit under test) DOU (Dependent on unit - e.g. systemclock, math.rand) Integrationtesting (Vi tester sammenhængen af units) Direct input - Input vi (testkoden) kan kontrollere, e.g. parametre, feltvariabler sat af testkoden. Indirect input - Input vi ikke kan (el. svært) e.g. hardware. 5 Design patterens Emphasis on finding the proper design pattern for a problem at hand and applying it. Motivation Vi bruger patterens til at have en guideline for best-practe for hvordan man løser et bestemt problem inden for et problemområde. Patterens er et kommunikationsmiddel. 5.1 Koncepter Behaviour, Responsibility, Role, og protkol under sektion 6.2 Def: Design Patteren (Gamma et al.) Patterens er beskrivelse af kommunikerende objekter der er skræddersyet til at løbe et generelt problem i en kontekst. Def: Design Patteren (Beck et al.) Et design patteren en et tekstuel repræsentation af designinformation, om et design der har virket, og som kan bruges til en lignende situation i fremtiden. I den her model bruges 4 dele: Navn: Et navn så man kan snakke om den, Problem: Problemet der bliver løst, Løsning: I software bliver den beskrevet vha. tekst og diagrammer, Consequences Hvile trade-offs er der? Page 10

11 Def: Design Pattern (Roadmap View) Et design patteren strukturere, dokumenterer, og giver et overblik over de roller og protokoller i et komplekse, compositionele designs. Et desigpattern er er et landkort over dele af designet Design patteren (Role View) Et designpattern er defineret ved et sæt af roller, hver med specifik ansvarsområde, og ved at have en veldefineret protokol mellem disse roller. Pattern fragility Et patteren kan kun vise alle sine fordele hvis implementeret korrekt. (e.g. hvis man i STRATEGY bruger konkrete strategier istedet for interfaces) Typiske fejl Bruger klassenavnet istedet for interfacenavne Man binder det forkerte sted (e.g. instansierer den inden i kroppen) 6 Compositional design Emphasis on applying compositional design principles and relating it to concepts behavior, responsibilities, roles, and multi-dimensional variance. Motivation 6.1 Koncepter Behavior Responsibilities Roles Multi-dimensional variance 1 Program to an interface, not an implementation (løst koblet) 2 Favor object composition over class inheritance (runtime binding) 3 Consider what should be variable in your design (or: Encapsulate the behaviour that varies) 6.2 Hvad er et objekt? Language Centric Class = instancefields + methods. Svart at kode sammenhængen mellem klasser Model-centric Et objekt er en model af virkeligheden. Når objektet bliver kørt, er det som at simulere en del af virkeligheden. Objekter er en abstrahering af et virkeligt objekt. Det fortæller dig ikke noget om hvordan man designer objekter der ikke eksisterer. Page 11

12 Resposibility centric Def: Et OO program er struktureret som et community af interagerende agenter kaldet objekter. Hver objekt har en rolle at spille. Hver objekt stiller er service til rådighed, eller udfører en handling der er brugt af andre medlemmer af dette commnuity. Et objekt er noget med ansvar. Det er bedre med et design der virker, mod et design der ligner den virkelige verden. Fundementale begreber: 1) Objekt 2) Roller Behaviour Def: Acting in a particular and observable way Hvordan det bliver gjort. Metoder er skabeloner for algoritmer Responsibility Def: The state of beging accountable and dependable to answer a request Ingen behaviour er specificeret, det er en kontrakt som vil blive overholdt. Man bruger evt CRC (Class name, Responsibilities, collaborating classes) Role A function or part performed especially in a operation or process. En rolle - mange objekter. Comparable rollen specificerer at et objekt har ansvaret for at fortælle om det er større, ligmed eller mindre en et andet givet objekt. Mange roller - et objekt. Fx i framework. Roller i software: Et sæt af ansvar og associerede protokoller. Det er ikke nemt at specificere i software, det tætteste man kommer på, er ved et interface, men man kan ikke specificere en protokol (at metode A på objekt X skal køres før B) Protokol En konvention (el. etikette) der udspecificerer sekvensen af interaktionen or handlingerne forventet af et sæt af roller. E.g. STRATEGY: Context starter udførslen af algoritmen, og ConcreteStrategy reaktivt svarer når adspurgt. 6.3 The four techniques Se sektion 3.2 The four techniques 7 Frameworks Emphasis on designing frameworks and understanding framework theory. Motivation Page 12

13 7.1 Koncepter Se side for oversigt og forklaring Def: Frozen spot En del af frameworket, der ikke kan blive ændret og som definerer det basale design og objekt-protokollerne i det endelige applikation. Def: Hot post Klart defineret del af frameworket, hvor specialiseret kode kan ændre eller tilføje opførsel til den endelige appikation. Inversion of control The framework defines the flow of control, not you. Page 13