Hvordan programmerer man?? STREAM - en model

1. Hvordan programmerer man?? STREAM - en model

2. Programmører arbejder ofte i teams Hver programmør arbejder på sin del af en større helhed.

3. Programmører arbejder ofte i teams Hver programmør arbejder på sin del af en større helhed. Komplekst!! Hvordan kommer man i gang??

4. STREAM – StepwiseImprovement Programmøren ændrer programmet som ”en voksende ø af funktionaliteter” FØRSTE VERSION UDVIDELSE 1 UDVIDELSE 2 …

5. Programmøren starter med en lille konkret del som efterhånden udvides. Programmøren har ikke det fulde overblik over slutproduktet undervejs FØRSTE VERSION UDVIDELSE 1 UDVIDELSE 2 …

6. Modsat arkitekten, der ved præcis hvordan huset skal se ud før byggeriet går i gang… Sidebemærkning: Denne programmeringstilgang kaldes ofte trinvis forfining. De fleste programmører vil nok sige at den eksisterer mere i teorien end i praksis…

7. Nøgleord i STREAM: Udvidelse, forfining, omstrukturering FØRSTE VERSION Forfining Omstrukturering UDVIDELSE 1 UDVIDELSE 2 …

8. Specifikation: En specifikation er en beskrivelse (ofte skriftlig) af slutproduktet. En beskrivelse at hvad programmet skal kunne. Med STREAM er specifikationen dynamisk – den ændrer sig undervejs i programmeringsprocessen og ligger ikke fast fra starten. FØRSTE SPECIFIKATION UDVIDELSE 1 … UDVIDELSE 2

9. Udvidelse: Udvide specifikationen så slutproduktet kommer til at indeholde mere funktionalitet Forfining: Gøre abstrakt kode til kode, der kan udføres, så programmet kan det der står i specifikationen Omstrukturering: Forbedre programmet uden at ændre på funktionaliteten. Oprydning, effektivisering, klargøring til ny udvidelse,…

10. Krav Hvad skal programmet kunne? Kundens bestillingsliste. Ændrer sig ikke undervejs. Specifikation Programmørens beskrivelse af programmets funktionalitet. Ændres løbende. Programmet Det implementerede program. Ændres løbende Programmørens elementer:

11. Krav Hvad skal programmet kunne? Kundens bestillingsliste. Ændrer sig ikke undervejs. Specifikation Programmørens beskrivelse af programmets funktionalitet. Ændres løbende. Programmet Det implementerede program. Ændres løbende Programmørens proces: SLUT Er alle krav med i specifikationen? JA JA NEJ NEJ Kan programmet opfylde alle krav? Udvid JA Kan programmet det der står i specifikationen? NEJ Forfin og omstrukturer

12. HVORDAN GØR MAN ALT DET?? • STREAM har 6 skridt: • Stubbe • Tests • Representation • Evaluering • Attributter • Metoder

13. Step 1: Stubbe • Lav ”skellet-klasser” til alle de klasser, der er brug for i programmet. Giv dem metoder uden funktionalitet – ”stubbe”. • De metoder, der skal returnere en værdi sættes til at returnere en ”default værdi” (eksempelvis 0 eller null), så klassen kan kompileres. • Ved slutningen af denne fase har man et program med klasser, der kan kompileres uden fejlmeddeleser, men ikke gør noget som helst.

14. Step 2: Tests • Design tests, der kan teste alle metoderne. Hvad forventer du af den enkelte metode? Sørg for at alle muligheder tages med. • Der findes mange måder at designe tests på. Vi vil ikke gå i dybden med dette her!

15. Step 3: Representasion

16. Step 4: Evaluering

17. Step 5: Attributter

18. Step 6: Metoder

19. Eksempel: • Kunden er en pizzarestaurant. Der skal laves et bestillingssystem, så pizzabageren kan se hvilke pizzaer telefonpasseren bestiller for kunden og i hvilken rækkefølge de skal bages. • Krav: • Pizzaer skal kunne bestilles med et eller flere af valgene: ost, tomat, skinke og løg • Kunne indikere i hvilken rækkefølge pizzaerne er bestilt (skal bages) • Varelageret skal indeholde alle typer af fyld og mængden skal reduceres hver gang der anvendes en bestemt ingrediens.

20. Step 1: Stubbe • Lav ”skellet-klasser” til alle de klasser, der er brug for i programmet. Giv dem metoder uden funktionalitet – ”stubbe”. • De metoder, der skal returnere en værdi sættes til at returnere en ”default værdi” (eksempelvis 0 eller null), så klassen kan kompileres. • Ved slutningen af denne fase har man et program med klasser, der kan kompileres uden fejlmeddeleser, men ikke gør noget som helst. • Åbn greenfootfilenpizza_stubbe.

21. Step 1: Stubbe • Pizzariaets (varelagerets) stubbe: • Tilsvarende metoder til de andre ingredienser

22. Step 1: Stubbe • Pizza stubbe:

23. Step 2: Tests • Design tests, der kan teste alle metoderne. Hvad forventer du af den enkelte metode? Sørg for at alle muligheder tages med. • public voidget_tomat() • public voidget_ost() • public voidget_skinke() • public voidget_løg() • public intGet_pizzanummer() • public voidspecificer_pizza()

24. Step 3: Representation • Hvordan skal objektet implementeres – hvilken representasion skal vælges? Kom med så mange forskellige som muligt og helst mindst to! • Pizzaen • R1: • alle ingredienserne lagres som tekststrenge og dynamisk nummerering af pizzaer så den med nummer 1 altid skal laves først • R2: • Ingredienser som boolske variable. Nummerering efter bestillingsrækkefølge

25. Step 4: Evaluering • R1: alle ingredienserne lagres som tekststrenge og dynamisk nummerering af pizzaer så den med nummer 1 altid skal laves først • R2: Ingredienser som boolske variable. Nummerering efter bestillingsrækkefølge

26. Step 5: Attributter • Vi er nu klar til at lave constructorer for klasserne og designe den visuelle del af systemet.

27. Step 5: Attributter • Vi er nu klar til at lave constructorer for klasserne og designe den visuelle del af systemet. • Pizzariaet: • Her placeres pizzabestillinger af telefonpasseren • Her placeres afviklede bestillinger af pizzabageren

28. Step 5: Attributter

29. Step 5: Attributter

30. Prøv programmet af og læs koden…