INF Enkel historikk over modul-utvikling. Ønsker til en god oppdeling. Program-arkitektur: Hvordan dele opp i moduler/komponenter?

Transkript

1 INF oktober 2004 Program-arkitektur: Hvordan dele opp i moduler/komponenter? Dagens temaer: Litt om modularisering av programmer (program-arkitektur) Om organiseringen av Del 2 Neste uke: Verken forelesning eller grupper Uka fra 18. oktober Mer oppgaver og forelesning om Del 2. Frist for Del 2: Meget tidlig i November 1 Listing-fil If-setning Deklarasjoner Uttrykk Symboler Flink-kode Testutskrifter Finnes ingen metode som sikkert fører fram Må bruke sin: Erfaring med prog.språket og andre verktøy som skal brukes Innsikt i feltet som skal behandles, og hvordan oppdeling tidligere er gjort Det første man tenker på er som regel ikke det beste Det trengs ofte lang modning for å finne de dype prinsipper i problemet. En slags metode : Forsøk å orientere deg på kryss og tvers i terrenget Grip fatt i begreper og substantiver Prøv ut hvordan forskjellige forslag vil virke, og ha stadig tro på forbedring En gang må man si det er bra nok, til en start 2 Enkel historikk over modul-utvikling Ønsker til en god oppdeling Ca 1957: Klumper av handling Subrutiner i Fortran, med parametere Ca 1960: Klumper av data Record i Cobol Ca 1970, mye inspirert av Simula 67, m.m. Klumper av data og operasjoner Som man ikke kan fikle med utenfra Tar seg av et sett detaljer Opp gjennom 80-årene ble dette utviklet innen mange språk: ADT (Abstrakt data-type)-orientert: Ada, Modula, Objekt-orientert variant: C++, Objective C, Smalltalk, Eiffel, Java, C#, 3 Programmet er lett å lese og forstå Kan overskue riktigheten Nye personer kan lett sette seg inn i det Delene er mest mulig uavhengige Kan forstås uavhengig av hverandre Kan programmeres uavhengig av hverandre Kan testes ut uavhengig av hverandre Hver modul omslutter noe komplekst, slik at resten slipper å tenke på dette Forholdet mellom modulene må være vesentlig enklere enn det inni dem Endringer blir lokale (men hvem vet hvilke endringer som skal gjøres?) Må dermed ofte tidlig velge hvilke endringer som skal være enkle å gjøre Modulene kan gjenbrukes i senere programmer Utviklingskostnadene er akseptable Utførelsen er ikke for ressurskrevende (tid, plass, ) Dette kan ekskludere visse oppdelinger Må avveies mot utviklingskostnader 4

2 Den tradisjonelle modul: Abstrakt datatype, ADT Bang-Tandberg Funksjoner/operasjoner/metoder synlige utad: Tilpasset brukerens begreper Er beskrevet i brukerens begreper Er komplett (alle rimelige behov dekket) Operasjonene er tilpasset hverandre For teknikere finnes en helt annen beskrivelse De har lov til å gå inn å måle og forandre, med tilsvarende ansvar Problem: Databehandlerne står på begge sider Blir lett uklarheter og fristelser Moduler er gjerne implementert ved nye underliggende moduler 5 Lagdelt (hierarkisk?) struktur er grei Pilene angir kall-retning Man bruker bare tjenester fra laget under De nederste lagene ikke avh. av de over Kan lett bygges opp fra bunnen, inkl. testing Nedre lag kan brukes om igjen helt uavhengig av nåværende bruk 6 Godt samarbeidende gruppe En skisse av Minila-kompilatoren De fleste modulene er gode radio-moduler Alle må være der for at noe kan komme i gang Kan ikke gjenbrukes uten at de andre også er til stede Om man ser på forskjellige aspekter ved programmet gir hver av disse ofte en hierarkisk struktur (som kan være totalt forskjellige): Tre-generering Kode-generering Feil-melding Test-utskrifter Oppstart og nedtaking 7 Flinkrepr. Minilaprogram fra fil Listingansvarlig Linjegenerator Linje for linje Tegn for tegn Symb. for symb. Dekl. Program Setn. Hovedansvarlig va pr pr va if if til Fil: Listing-fil Instr. for instr Flok-format Tregenerator Tegngenerator Symbolgenerator Tegngenerator Symbolgenerator Tregenerator Flink-maskinen 8

3 Eksempel på uryddighet En viss slik uryddighet vil alltid finnes: Ofte: Ryddig fra en vinkling, uryddig fra en annen Modulers utstrekning kan defineres ved deres ansvarsområde/rettighetsområde I treet vil det i de fleste tilfellene gå ved grensen for node-objektet Men f.eks. for innsetting i dekl-liste må dekl-sekv.-objektet og dekl-delen av liste-objeketene være ett ansvarsområde (variable begge steder er involvert) Dekl: navn: U fdekl navn: Q navn: P VarDekl navn: Y ProcDekl navn: V Eksempel på uryddighet 2 proc P in X out Y; < dekl. av U, Q og V >; begproc endproc; Mulig uryddighet: Det kan her være naturlig å gjøre innsettingen av parametere i listen fra ProcDekl-objektet (før analysen i denne?) Men hvordan står det i forhold til at denne innsettingen normalt gjøres under analysen i -objektet?? fdekl : navn: Y navn: U navn: Q navn: V?? VarDekl?? ProcDekl navn: P DS INPAR OUTPAR SS navn: Y 9 Er disse av en spesiell subklasse av Dekl? 10 Objektorientering: Mer selvstendige moduler Hovedjobben: Det logiske bildet Tradisjonell modul (abstrakt data-type): Gjør utad sett alltid det samme = det i bruksanvisningen Implementasjonen kan forandres, så lenge det virker likt utad Henger gjerne sammen med en lagdelt struktur på modulene Ved klasser/subklasser og redefinisjon (overriding) av metoder får man: Mer selvstendige moduler: Melding/kall Forstår meldingen (altså, har metoden) Velger selv metode Eksempel: Melding/kall: Klasse: Subklasser: Vi får objektet til å velge metode ut fra hvilken subklasse det er av tegndegut Figur Firkant, Sirkel skrivdegut MinilaKonstr IfSetn, WhileSetn Fordeler: Brukeren kan tenke i mer høynivå begreper Greit at valg av metode gjøres av objektet selv Lett å legge inn nye varianter (subklasser) som trenger egen metode 11 Analyse Sjekking av: * Struktur *Navnebruk Treet blir laget ferdig av Analysatoren (Tre-generatoren) Dekl Program var Prosedyre Tilord If While Kode-gen. Noen av node-klassene må utvides litt for Del-2 Kode-gen. har en hoved-metode, for eksempel oversett( ) : Denne kalles fra hovedansvarlig når den får beskjed om at analysen er ferdig Det første den gjør er å hente treet fra Tre-gen. (ved å få en peker til roten) Utfører så oversettelsen, ved metoder distribuert i treet (f.eks. lagkode( ) ) Får mye hjelp av Flink-representanten Til slutt skriver Flink-representanten programmet ut i Flok-format Setn Dekl setn Bet Setn Flok 12

4 void lagkode() Kode-generatoren skal også være distribuert Kode-generatoren vil også være implementert distribuert i tre-nodene: Som metoder ( lagkode() ) inne i tre-nodene Hver metode i en tre-node står ansvarlig for å lage Flink-kode for sin del av treet (inkl. undernoder) 13 Hva tilbyr Flink-representanten utad? void lagkode() nesteinstadr()? startopp() Et antall metoder som gjør at Kode-generatoren ikke behøver å tenke på detaljer under veis (skal være en god sekretær for kodegenereringen) Kan tenke på en radio: Hvilke knotter og visere er de rette? Må tenke gjennom hvilke behov Kode-generatoren har Disse må dekkes på en effektiv og naturlig måte Og slik at de passer sammen, også stilmessig og navnemessig Vil gjerne naturlig bli delt opp i grupper eller familier Skal kunne beskrives i begreper som kodegeneratoren tenker i. avslutt() 14 skrivflok() Hvilke instruksjoner skal Minila oversettes til? void lagkode() void lagkode() K-testutskrift Listing-ansv. Dette er beskrevet i (litt kryptiske) tabeller i Kap. 5 Ser mye på dette på gruppene Vi skal bruke disse tabellene slavisk Er mulig (og morsomt) å optimalisere (diskutert i noen oppgaver) Men får bare gjøre dette om det er mulig å skru det av (ved levering). 15 I alle tre-nodene: void lagkode() / / Gjerne også abstrakt i ytterste tre-klasse K-testutskrift: Tilsvarende som A-testutskrift, men i metoden lagkode( ) Med tilsvarende innrykk Må legges inn i Listing-ansvarlig, velg passelige navn Greit med en inn -prosedyre og en ut -prosedyre 16

5 Innsiden av Flink-representanten void lagkode() Listing-ansv. void lagkode() I-testutskrift Listing-ansv. Skal ha kopier av lagrene i Flink-maskinen Og variable som viser hvor langt disse er fylt opp eller reservert Skal kopieres ut i Flok-kode når kodegenereringen er ferdig Kunne også godt legge inn en metode utfør() som kan simulere utførelsen av programmet, før det legges ut på fil. Dette er ikke en del av den obligatoriske oppgaven, og må eventuelt være styrt av parametere til kompilatoren. 17 Krever et antall prosedyrer i Listing-ansvarlig Hver må angi på listing-filen: Hvilken metode i Flink-representanten som er kalt Og skrive ut all interessant informasjon om dette kallet flinkrepr.lagsti(113, 1) kan for eksempel komme ut slik: --- I (instr) <pos av inst> STI (2) Enkelt: Behandling i SetnSekv Behandling av variabel-deklarasjoner fd Program SetnSekv fs fdekl VarDekl nd Var nd Proc nd Var ns Tilord V U ns While B SS ns Tilord V U Dekl: navn: U navn: Q Class SetnSekv / / Helt tilsvarende for og uttrykk Setn S; void lagkode(); <K-test-inn>; S = forstesetn; / / fs på figuren while ( S!= null ) S.lagKode(); / / NB: forutsetter at lagkode er abstakt i Setn (eller helt ytterst) S = S.nesteSetn(); / / ns på figuren <K-test-ut>; 19 VarDekl-klassen må utvides med variabel (for eksempel celleno ) Angir hvilken celle den har fått tildelt i heltalls-lageret (første tildelte celle, om det er array) Inne i VarDekl: void lagkode( ) <K-test-inn>; if (<det er array>) celleno = flinkrepr.resvar(<antall celler til arrayen>, navn); else celleno = flinkrepr.resvar(1, navn); <K-test-ut>; 20

6 void lagldi(int A, int C) int F = 1; // LDI har nummer 1 < Øk IL_ledig", og sjekk at det er plass til en instr. til >; // Sett instruksjonen ned i lageret: func[il_ledig] = F; adr[il_ledig] = A; corr[il_ledig] = C; < Kall passelig metode i Listing-ansv. for I-testutskrift >; Osv. for alle de andre instruksjonene Metodene i Flink-representanten int nesteinstadr() leverer verdien av IL_ledig" int resvar(int ant, String navn) // Denne reserverer "ant" celler i heltallslageret (ved å // Øke HL_ledig". Sjekke at det er plass nok. // Leverer adr. til (første) cellen. // Parameteren "navn" er bare med for I-testutskriften // Skal gi I-testutskr. med: HL_ledig", "ant" og "navn" int reskonst(int verdi) // Denne reserverer en celle i heltallslageret, fyller den med // den angitte verdien, og lever adr. til cellen. // Skal sjekke at det er plass nok. // Skal gi I-testutskr. med: HL_ledig" og "verdi" void fyllgammeladr(int instnr, int nyadr) // Skal fylle instruksjon nr "instnr" med adressedel "nyadr" // Skal gi I-testutskr. med: "instnr" og "nyadr" Gjøres i en felles metode i? Merk forskjellen i eventuell plassering Kan også godt lage egne hjelpe-metoder: Disse kan mest natulig være felles for alle nodene i treet Altså, de deklareres static i ytterste trenodeklasse Et eksempel kan være: static void lagaropinst(string arop, int adr, int corr) 21 Forandringer i gamle deler av kompilatoren Forandringer i Hoved-ansvarlig: Ved innlesning av parameterne: Full parameter-sekvens til kompilatoren: <prog-fil> <flok-fil> <listing-fil> <hvilke testutskr.> <maxinst> <maxint> De to første parameterene må oppgis maxinst er lengden av inst-lageret og maxint er lengden av heltallslageret Om ikke oppgitt skal disse ha verdien 1000 Parametere man ikke vil oppgi angis ved - (eller blank, om de er på slutten) Ved oppsetting av modul-objektene: Også Kode-generator og Flink-representant må skapes Flink-representanten skal ved oppstart også få maxinst og maxint. Igangsetting: Også kodegenereringen må settes i gang: tregen.lesprogr(); // Var der i Del 1 kodegen.oversett(); // Ny i Del 2 Oversettelsen skal bare startes dersom Minila-program er OK Dette går automatisk dersom man har vanlig struktur (og ikke bruker softerror ) Merk: Det kan også komme feilmeldinger fra Del 2 (f.eks. for liten plass ) 22 Forandringer i gamle deler av kompilatoren (forts.) Ekstra variabel i deklarasjons-nodene: For dekl. av variable/arrayer/parametere: En variabel (f.eks. cellenr ) som inneholder adresse til reservert(e) celle(r) For proseyre-deklarasjoner: En variabel (f.eks. startadr ) som inneholder adresse til første instruksjon Utvide Listing-ansvarlig Med apparat for å ta seg av K- og I-testutskrift Ny metode i Tre-generatoren Som Kode-generatoren kan kalle for å få (peker til roten av) treet Utvide mengden av statiske felles-variable (og metoder?) for treet: Den eneste nye er antakeligvis peker til Flink-representanten Må også legges til i oppstart-metoden for treet (som setter disse variablene) Mange av de som er der fra Del 1 er også viktige i Del 2 Kanskje skal også xbet og xin være slike variable (se nederst side 106) 23