Miniprojekt i Programmering (MIP)

Dat1 og SW3, januar 2010.

Opgavetillæg forud for omeksamen

I denne opgave skal der skrives et simpelt system, som administrerer kunder der ønsker at købe og/eller sælge køretøjer. Der skal programmeres et hierarki af klasser som afspejler de forskellige typer af køretøjer, der kan sættes til salg. Der skal endvidere programmeres en eller flere klasser, der afspejler købsønsker på bestemte typer af køretøjer som har nærmere angivne egenskaber. Programmet skal holde styr på en samling af køretøjer, der ønskes solgt. Endelig skal programmet administrere en samling af kunder, hvor en given kunde kan være både sælger og potentiel køber af køretøjer.

Programstruktur.

Følgende klasser skal programmeres:

1. Personbil: Repræsenterer en personbil, der ønskes solgt. Der registreres følgende data om personbiler: Mærke, årgang, kørte kilometer og pris.
2. Lastbil: Repræsenterer en lastbil, der ønskes solgt. Der registreres følgende data om lastbiler: Mærke, årgang, kørte kilometer, pris og maksimal lasteevne.
3. Trailer: Repræsentere en trailer, der ønskes solgt. Der registreres: Mærke, pris, dimensioner (længde og bredde af traileren) samt maksimal lasteevne.

Som en del af opgaveløsningen skal klasserne Personbil, Lastbil og Trailer organiseres i et specialiseringshierarki, som er fornuftig i forhold til kravene i denne opgave.

4. KøbsØnske: Repræsenterer et købsønske for et køretøj. Et købsønske udtrykker krav til en eller flere egenskaber af et køretøj (som nævnt herover). Kravene kan omfatte typen af køretøj, mærke, årgang, kilometertal, pris, minimal lasteevne og minimal dimension (minimal længde, minimal bredde). I et købsønske behandles følgende egenskaber gennem et interval (fra et minimum til et maksimum): årgang, kilometertal og pris.

KøbsØnske kan enten programmeres som én klasse, eller som et klassehierarki f.eks. svarende til det valgte hierarki for typer af køretøjer.

5. Kunde: Repræsenterer en køber og/eller sælger af et køretøj. Der registreres navn, og postnummer for kundens bopæl. Endvidere registreres der for hver kunde hvilke køretøjer kunden ønsker at sælge, og hvilke ønsker kunden har om køb af køretøjer.
6. SalgsKartotek: Repræsenterer en samling af køretøjer, der er sat til salg.
7. KøbsKartotek: Repræsenterer en samling af købsønsker.
8. Kundekartotek: Repræsenterer en samling af kunder.

Alle klasser skal have passende konstruktorer og properties/metoder, som modsvarer de indkapslede data.

Funktionalitet.

Følgende funktionalitet skal programmeres:

1. Søgning efter alle køretøjer, der sælges til en pris mellem a og b kroner. a og b skal være parametre til en metode, der foretager søgningen i et salgskartotek. Søgningen skal returnere en samling af køretøjer.
2. Søgning efter alle de kunder, der er sælgere. Den resulterende samling af kunder skal ordnes efter billigste salgspris af de køretøjer, som en kunde har til salg. Kunden, som sælger det billigste køretøj, kommer først.
3. Søgning efter alle de kunder, som er købere. Kunderne skal ordnes efter den maksimale pris, som kunden er villig til at betale for et køretøj. Start med højeste pris. Søgningen skal returnere en samling af kunder.
4. For en given kunde der er køber, find og returner samlingen af de køretøjer i salgskartoteket som matcher et af kundens købsønsker. På et niveau i problemløsningen skal dette omfatte en eller flere metoder, der matcher ét køretøj med ét købsønske (se detaljer herunder).
5. For en given kunde der er køber, find og returner alle de matchende køretøjer i salgskartotektet som er "tæt nok" på køberens bopæl.

Der vil blive lagt vægt på at kompleks funktionalitet nedbrydes passende i et antal mindre komplekse metoder. Endvidere vil der blive lagt vægt på, at alle programmerede metoder placeres i de mest naturlige klasser.

Afstanden mellem to kunder kan f.eks. implementeres som differensen mellem kundernes postnumre.

Idet en kunde k både kan have købs- og salgsønsker, skal det i funktionaliteterne D og E forhindres, at k får tilbud om at købe et af de køretøjer han/hun selv har til salg.

Der er ikke absolutte krav til hvordan et købsønske o matcher et køretøj k, som er sat til salg. Følgende kan opfattes som inspiration og vejledning:

• Typen af køretøjet i o svarer til typen af k.
• Mærket i o er lig med mærket i k.
• Årgangsintervallet i o indeholder den eventuelle årgang i k.
• Prisintervallet i o indeholder prisen i k
• Kilometerintervallet i o indeholder det eventuelle kilometertal i k.
• Den minimale lasteevne i o er mindre end den eventuelle maksimale lasteevne af k.
• Dimensionerne i o svarer 'mindst til' den eventuelle dimension af k.

Programmets funktionalitet skal kunne demonstreres på en af følgende to måder:

• Gennem en klasse, der implementerer en simpel tekstuel brugergrænseflade, med en simpel tekstuel menu, der interaktivt tillader brugeren at aktivere den påkrævede funktionalitet. Det forventes ikke at brugergrænsefladen er flot eller prangende.
• Gennem en eller flere klasser, der ved unit testing godtgør at programmet virker som forventet.

Variationer.

Som det fremgår, rummer opgaven betydelige variationsmuligheder i programmeringen af klassen KøbsØnske, i dannelse af klassehierarkierne, samt måden hvorpå køretøjer og købsønsker matcher hinanden.

Geografisk afstand: Som beskrevet ovenfor kan afstanden mellem to geografiske steder beregnes som differensen mellem postnumre. Det er muligt at indføre et mere realistisk afstandsmål (dog stadig baseret på postnumre).

Intervaller: I klassen KøbsØnske indgår der intervaller af årgange, kilometertal og priser. Det vil være muligt at programmere en generel type, der hjælper med håndtering af sådanne intervaller.

Matching mellem købsønsker og køretøjer (der ønskes solgt) er central i denne opgave. En god løsning på problemet kræver at der kan 'dispatches' på båden typen af køretøj og på typen af købsønske (via virtuelle metoder). Overvej muligheden for at programmere match operationerne uden eksplicit brug af typetest i form af obj is T.

Ressourcer.

På adressen http://www.cs.aau.dk/~normark/oop-09/html/mip-jan-10/cs-udlevering.html findes en C# kildefil, der opretter et antal køretøjsobjekter sat til salg, samt et antal kundeobjekter der ønsker at sælge disse. I filen findes også en række uformelle købsønsker, der i opgaveløsningen skal repræsenteres som objekter af typen KøbsØnske. Det forventes at de givne køretøjer og kunder tilpasses jeres program. Det forventes endvidere at programmet, som et minimum, demonstreres på de givne kunder, køretøjer og (uformelle) købsønsker.

Krav og forventninger til program og dokumentation

• Det udviklede program skal være objekt-orienteret, og det skal skrives i C#.
• Kildeteksten af det udviklede program skal afleveres i to eksemplarer på elektronisk form, f.eks. på CD-ROM eller USB memory stick, men ikke DVD.
• Der skal afleveres to papirudskrifter af det samlede program. Der skal være linienumre i udskrifterne. Udskrifterne skal være uden brud af linierne i programmet. Udskriv om nødvendigt i "landscape mode".
• Idet de givne programdele er udtrykt på dansk, anbefales det at navne og begreber i det afleverede også er på dansk.
• Det udviklede program skal være demonstrerbart på de udleverede kunder, køretøjer og købsønsker.
• Det udviklede program skal være velskrevet og velkommenteret, således at det fremstår forståeligt for læsere af programmet.
• Med det udviklede program skal der følge en kort beskrivelse af programmet (ca. én side). Denne beskrivelse skal omfatte navne på deltagerne; minigruppe id (enten Dat<bogstav> eller SW<bogstav>); status af programmet; beskrivelse af evt. antagelser, begrænsninger, udvidelser eller variationer i forhold til opgaveformuleringen; listning af alle kilder der har været anvendt til at løse opgaven (dog ikke materiale fra OOP kursets pensumliste); underskrift fra alle deltagerne. En underskrift bekræfter en ligelig deltagelse i programmeringsarbejdet, at ingen andre end de underskrevne har bidraget til arbejdet, og at alle anvendte kilder (ud over pensum) er angivet.
• Evt. uklarheder i opgaveformuleringen forventes afklaret som en del af opgaveløsningen.
• Der henvises i øvrigt til beskrivelsen af rammerne for miniprojektet på MIP hjemmesiden https://intranet.cs.aau.dk/education/courses/2009/mip/.

I forbindelse med opgaveløsningen og MIP eksamen opfordres I til at se på læringsmålene for MIP i gældende studieordning (blad lidt frem i dokumentet):

• http://www.fsn.aau.dk/fileadmin/fsn/dokumenter/7_studieordninger/338-f08/datbachkand_sept2007_sept2008.html#4.1.1.2

Hvis der bliver behov for flere oplysninger, rettelser eller lignende i programmeringsperioden udsendes der besked på mailing listerne dat1-2@cs.aau.dk og sw3-4@cs.aau.dk. Endvidere indsættes tekst i toppen af denne opgaveformulering på nettet, som kan tilgås via det gule felt øverst på OOP hjemmesiden. Kontaktpersonen er Kurt Nørmark, normark@cs.aau.dk.