1.5. Planlægning af et program

For at omsætte teori til praksis er det bedst at begynde med en opgavetype, som man kender lidt til i forvejen, og helst et område, som ikke involverer kompliceret teknik. I denne sammenhæng er spil og simuleringer er gode.

Det er vigtigt, at man ikke begynder for ambitiøst. Pas på ikke at gøre for meget ud af detaillerne i første omgang. Prøv for eksempel at skitsere, hvilke oplysninger, der bør være med i et CD kartotek. Når det viser sig, at denne opgave er af næsten uoverskuelig kompleksitet og involverer ansættelse af 10 erfarne bibliotekarer (jvf. Knuth [2]) så er man gået for langt.

For at repræsentere et medlem i et medlemskartotek er det indlysende, at der skal være navn og medlemsnummer (eller er medlemsnummer nok?), måske skal navnet deles i for/efternavn, formentlig skal vi have adressen med. Hvordan vi vil nedfælde adressen kommer an på meningen med kartoteket. Normalt skal der være forskellige måder at kontakte personen. Det kunne måske klares ved et telefonnummer eller en e-postadresse. Skal der være felter for indbetalt kontingent eller vil vi henvise til et kontonummer og dermed bevæge os ind på posteringsteknikker?

Det er rart at prøve det nogle gange. Det er også ganske underholdende, fordi man (forhåbentlig) opdager en masse om, hvad man kan forvente af funktionalitet ud fra de data, man agter at registrere.

Opgave: Prøv at tegne/skitsere en repræsentation af noget, du kender godt, f.eks. et medlemskartotek, og beskriv de operationer, du ønsker at kunne foretage. Hvis det bliver nødvendigt at ændre i datarepræsentationen, så gør det, og tjek, at de gamle operationer stadig kan fungere. Prøv at holde skitsen så simpel som muligt, således at man stort set kunne gøre de samme ting ved hjælp af en editor (tekstbehandling).

Det er den samme fremgangsmåde som ved objektorienteret analyse og planlægning, med den lille undtagelse, at vi ikke hævder at afspejle den ydre verdens datastruktur i vores interne datarepræsentation.

Man kan selvfølgelig også begynde med de operationer , som man ønsker at have til rådighed. Derefter finder man ud af, hvilke data, som kræves for at kunne gøre det.

Med denne metode skal man være mere opmærksom på, hvordan de forskellige data skal grupperes. Det sjove ved den "objektorienterede" analyse er jo, at man anvender sit forudfattede billede af den eksisterende opgave til at gruppere sine data.

Uanset hvilken indfaldsvinkel man foretrækker, så er det vigtigt at tegne og tale med kolleger, i nødsfald med sig selv, om hvordan man kunne gribe sagen an. Brug meget gerne pseudo-programmering, d.v.s. almindelige sætninger, som beskriver, hvordan programmet skal fungere. Det kunne man kalde aktions-orienteret programmering ;-)

Den her foreslåede fremgangsmåde er jo den samme procedure som ved objektorienteret analyse til for eksempel programmering i C++, Det er ikke umuligt at skrive strukturerede, objektorienterede programmer ved hjælp af C sproget. Det er selvfølgelig nemmere at gøre det med C++ (eller bør være nemmere), men der er stadig nogle situationer, hvor C er mere effektivt.