Programmering af Store Systemer
Projektopgave
Vi skal konstruere et system til håndtering af fejlmeldingers og reparations logistik.
Systemet skal give medarbejdere adgang til alle oplysninger der skal bruges til fejlretning,
og sikre at alle procedurer bliver overholdt, så alle fejl bliver rettet korrekt
Vi går ud fra at følgende reelt bliver håndteret af andre systemer:
- Medarbejdere
- Kunder
- Udstyr
- Afregning
Desuden har vi ikke taget følgende med i vores system, selv om det synes at skulle være
en naturlig del af et problem-management system:
- Overholdelse af tidsfrister
- Opfølgning på problemer
- Opsamling af erfaringer
- Overvågning af resurseforbrug
Vi har holdt gruppemøde mindst to gange ugentligt – og så arbejder vi sammen til hverdag,
så frokostpausen er ofte blevet brugt til at diskutere et element i systemet.
Vi forsøgte at lægge en oversigtlig plan med få delmål.
Desværre brugte vi meget mere tid på C++ Builder end vi havde forudset.
Planen holdt kun delvist, og kun takket være fokusering på centrale funktionaliteter.
Vi har ikke udnævnt en gruppeleder men har haft stor glæde af at kende hinanden fra starten af uddannelsen.
For at holde løbende status har vi haft gang i rapporten siden starten af projektet.
Da dette er en programmeringsopgave, går vi direkte til beskrive af systemets problemområde.
Det betyder også at vi ikke kommer med en specifik beskrivelse af anvendelsesområdet og anbefalinger.
Vi vil undervejs i rapporten omtale funktioner, brugergrænseflade og den tekniske platform
hvor det passer ind i den øvrige dokumentation.
Vi har bortprioriterede en beskrivelse af systemets hændelser med hændelsestabel og sekvens-diagrammer
for at kunne koncentrere os om udviklingsmiljøet og selve implementeringen.
Figur 1. Klassediagram for systemet.
Vi har set os nødsaget til ikke at beskrive den enkelte klasses adfærdsmønster –
vi prioriterede programmeringen af systemet højere end tilstandsdiagrammerne med beskrivelse.
Generelt har vi anvendt "typerne" String (AnsiString) og DateTime er fra Borlands VCL (Visual Component Library).
I det følgende er klasser opstillet alfabetisk og beskrevet.
2.2.1 Klassen ’Beskrivelseslog’
2.2.1.1 Ansvar og formål
Logregistreringer af ændringer af fejlbeskrivelser i klassen Fejlmelding.
Klassen er aggregeret til subklassen Fejlmelding, hvor én (1) fejlmelding er aggregeret
til nul-til-mange (0..*) logentries, og til superklassen Problemlog hvor ét (1) logentry
er aggregeret til ét (1) problem.
2.2.1.2 Attributter
Strengen ’Fejlbeskrivelse’ indeholder den tidligere fejlbeskrivelse fra en fejlmelding.
2.2.1.3 Metoder
Konstruktøren Beskrivelseslog() der indlæser data i alle attributter og
gemmer dem i en ny post i databasen. Destruktøren ~Beskrivelseslog()...
hentFejlbeskrivelse() henter attributten og har derfor returtypen String.
2.2.2 Klassen ’Fejlmelding’
2.2.2.1 Ansvar og formål
Indeholder aktuelle oplysninger om en fejlmelding.
Klassen er aggregeret til subklassen Person så én (1) person kan have indmeldt nul-til-mange (0..*) fejl.
Ansvaret for fejlmeldingen ligger i aggregeringen til subklassen Medarbejder hvor én (1) medarbejder
kan være ansvarlige for nul-til-mange (0..*) fejlmeldinger.
Til hver (1) fejlmelding er der nul-til-mange (0..*) troubletickets, hvilket er angivet med en aggregering til
subklassen Troubleticket. Da der er noget udstyr involveret i de fleste fejl, er klassen associeret til klassen Udstyr.
Når der ændres beskrivelse eller status, bliver dette logget i superklasserne Beskrivelseslog og Statuslog,
der er aggregeret så én (1) fejlmelding kan have nul-til-mange (0..*) logentries af hver type.
2.2.2.2 Attributter
Beskrivelse af fejlen ligger som fritekst i strengen ’Beskrivelse’, og oplysningen om hvornår fejlmeldingen er oprettet
ligger i tidspunktet ’Tidspunkt’. Status for fejlmeldingen ligger som et heltal i ’Status’.
2.2.2.3 Metoder
Konstruktøren Fejlmelding() opretter objektet med relevante data i attributterne og gemmer i en ny post i databasen.
Destuktøren ~Fejlmelding()... Metoderne retBeskrivelse() og retStatus() opretter et logentry
i klasserne Beskrivelseslog og Statuslog før attributterne opdateres med korrekte data.
Metoderne hentBeskrivelse(), hentTidspunkt() og hentStatus() giver læsedadgang til attributterne
og har de tilsvarende returtyper.
2.2.3 Klassen ’Kunde’
2.2.3.1 Ansvar og formål
Indeholder oplysninger om en kunde. Selve kundeadministrationen antager vi ligger i et andet system
i en endelige implementering, så der skal være en passende systemgrænseflade mellem de to systemer.
Klassen er en sub-klasse til klassen Person i en association hvor én (1) kunde er én (1) person.
2.2.3.2 Attributter
Strengene ’Adresse’ og ’Telefonnr’ indeholder data om kundens adresse og telefonnummer.
Vi har valgt at lade telefonnummeret blive gemt i en streng, da der kan blive brug for andre tegn end numeriske,
for eksempel +, ( eller ).
2.2.3.3 Metoder
Konstruktøren Kunde() og destruktøren ~Kunde() er implementeret trivielt i dette system,
da der findes et specielt system til kundadministration. Læseadgangen til attributterne gives ved metoderne
hentAdresse() og hentTelefonnr(), der har returtyper svarende til attributterne.
2.2.4 Klassen ’Medarbejder’
2.2.4.1 Ansvar og formål
Indeholder data om medarbejdere i firmaet. Vi antager at der findes et specielt personalesystem,
som administrerer personaleoplysningerne i systemets endelige udgave og stiller dem til rådighed for feljmeldingssystemet.
Klassen er subklasse til klasserne Person og Problemlog, sådan et én (1) medarbejder er
én (1) person, og én medarbejder kan være ansvarlige for nul-til-mange (0..*) logentries.
2.2.4.2 Attributter
Den enkelte medarbejders initialer er gemt i strengen ’Initialer’.
2.2.4.3 Metoder
Konstruktøren Medarbejder () og destruktøren ~Medarbjeder() er implementeret trivielt,
for oplysningerne findes i personalesystemet. Attributten læses med hentInitialer(), der har returtypen string som attributten.
2.2.5 Klassen ’Person’
2.2.5.1 Ansvar og formål
Da både en kunde og en medarbejder har et navn, er klassen Person oprettet til navne på personer.
Klassen er superklasse for klasserne Kunde og Medarbejder i en aggregering, hvor én (1) kunde har
ét (1) navn og én (1) medarbejder har ét (1) navn. Klassen er samtidig subklassen til klassen
Fejlmelding i en aggregering, hvor én (1) person kan have indmeldt nul-til-mange (0..*) fejl.
2.2.5.2 Attributter
Personens navn er opbevaret i strengen ’Navn’.
2.2.5.3 Metoder
Da der er separate systemer til kunde- og personaleadministration er konstruktøren Person()
destruktøren ~Person() trivielle. Attributten læses med hentInitialer() der returnere en streng.
2.2.6.1 Ansvar og formål
Alle logentries har et tidspunkt for ændringen. Til at håndtere disse oplysninger er denne klasse oprettet.
Klassen er superklasse til klasserne Beskrivelseslog, Reperationslog, Statuslog og
Tilstandslog i en aggregeringsstruktur, hvor ét (1) tidspunkt er knyttet til ét (1) logentry.
2.2.6.2 Attributter
’Tidspunktet’ af typen tidspunkt er den eneste attribut.
2.2.6.3 Metoder
Konstruktøren Problemlog() opretter et objekt med attributten sat af en overført værdi.
Destruktøren ~Problemlog() er triviel og derfor ikke implementeret specielt.
Attributten læses med hentTidspunkt() der returnere med typen datetime.
2.2.7 Klassen ’Reperationslog’
2.2.7.1 Ansvar og formål
Nye oplysninger om et stykke udstyrs reparation logges ved hjælp at denne klasse, der er superklasse til klassen
Udstyr i en aggregering hvor ét (1) stykke udstyr kan have nul-til-mange (0..*) logentries.
Desuden er klassen Reperationslog subklasse til klassen Problemlog i en én (1) til én (1) aggregering.
I en større sammenhæng ville vi nok foretrække at logningen af det enkelte stykke udstyrs reperationer
blev håndteret af det specielle system til håndtering af udstyr som vi går ud fra findes i virksomheden.
2.2.7.2 Attributter
En fritekst beskrivelse af reparationen ligger i attributten ’Beskrivelse’ der er et string-element.
2.2.7.3 Metoder
Konstruktøren Reperationslog() opretter et objekt og tildeler attributten ’Beskrivelse’ et indhold givet af
en parameter. Destruktøren ~Reperationslog() er triviel og derfor ikke specifikt implementeret.
Attributtens indhold gives ud f det enkelte objekt med hentBeskrivelse(), der har typen string svarende til attributtens type.
2.2.8 Klassen ’Statuslog’
2.2.8.1 Ansvar og formål
En ændring af en fejlmeldings status registreres i denne klasse, der er superklasse til klassen Fejlmelding
i en aggregering hvor én fejlmelding kan have flere (0..*) logentries. Desuden er denne klasse subklasse til
klassen Problemlog i en aggregeringsstruktur med en én (1) til én (1) mangfoldighed.
2.2.8.2 Attributter
Fejlmeldingens tidligere fejlstatus kopieres over i heltals-attributten ’Fejlstatus’.
2.2.8.3 Metoder
Konstruktøren Statuslog() opretter et objekt med den parametergivne værdi til attrubutten.
Destruktøren ~Statuslog() er triviel og derfor ikke implemeteret i systemet.
Klassens attribut kan læses af andre klasser med hentFejlstatus() der returnere et heltal.
2.2.9 Klassen ’Tilstandlog’
2.2.9.1 Ansvar og formål
En ændring af en troubletickets tilstand logges ved hjælp af denne klasse.
Klassen er en subklasse til klassen Problemlog i en aggregerings hvor én (1) tilstandsændring giver
ét (1) logentry. Klassen er desuden superklasse til klassen Troubleticket hvor én (1) troubleticket
kan have flere (0..*) logentries
2.2.9.2 Attributter
Den tidligere tilstand for en troubleticket gemmes i attributten ’Tickettilstand’ med et heltal.
2.2.9.3 Metoder
Et objekt oprettes med attributtens værdi sat af en parameter med konstruktøren Tilstandlog().
Destruktøren ~Tilstandlog() er ikke implementeret da den er triviel.
Attributtens værdi læses ved hjælp af hentTickettilstand() der returnerer et heltal.
2.2.10 Klassen ’Troubleticket’
2.2.10.1 Ansvar og formål
Den enkelte troubleticket opbevares i systemet i denne klasse, der er subklasse til klasserne Fejlmelding
og Tickettilstand i en aggregeringsstruktur. Én (1) fejlmelding kan i denne sammenhæng have
nul-til-mange (0..*) trobletickets mens én (1) troubleticket kan have nul-til-mange( 0..*) logentries.
En troubleticket kan have relation til et stykke udstyr, så klassen er assoicieret til klassen Udstyr.
2.2.10.2 Attributter
En troubleticket har et oprettelsestidspunkt, der er gemt i attributten ’Tidspunkt’, og en tilstand,
der gemmes i attributten ’Tilstand’. ’Tidspunkt’ har datatypen datetime og ’Tilstand’ er et heltal.
2.2.10.3 Metoder
Et troubleticket-objekt oprettes af konstrukutøren Troubleticket() hvor attributternes værdier
sættes af parametre. Destruktøren ~Troubleticket() er ikke implementeret på grund af triviel funktionalitet.
Metoden retTilstand() opretter et logentry med den gamle tilstand før attributten opdateres.
Der returneres et heltal til kontrol af forløbet.
Attributterne læses med metoderne hentTidspunkt() og hentTilstand() der returnerer henholdsvis et tidspunkt og et heltal.
2.2.11 Klassen ’Udstyr’
2.2.11.1 Ansvar og formål
Da vi går ud fra at der i produktionsversionen af systemet findes et specielt system til administration af udstyr,
skal denne klasse mere ses som en systemgrænseflade. Klassen er associeret med klasserne Fejlmelding og Troubleticket,
og subklasse til klassen Reperationslog i en aggregeringsstruktur hvor ét (1) stykke udstyr kan have flere reparationer (0..*) bag sig.
2.2.11.2 Attributter
En enhed har et unikt nummer, der kan være beskrivende. Derfor har vi valgt at lade attributten ’Nummer’ have en streng-type
lige som attributten ’Beskrivelse’ til fritekstbeskrivelse af enheden.
2.2.11.3 Metoder
Konstruktøren Udstyr() opretter et stykke udstyr i systemet med de værdier til attributterne som parametrene giver.
Attributterne kan senere læses med metoderne hentNummer() og hentBeskrivelse().
Destruktøren ~Udstyr() er ikke implementeret da den har triviel funktionalitet.
Da vi ikke har de store ændringer til analysedelen, vil vi ikke beskrive komponenter eller anbefalinger særskilt her i designdelen.
3.1.1 Rettelser til analysen
Globale variable og frie funktioner placeres i klassen Global. For eksempel bliver oplysninger om hvem den aktuelle bruger
af systemet er gemt i Global.
3.1.2 Kvalitetsmål
Vi vil ikke hér komme med en detaljeret beskrivelses af kvalitetsmålene, blot udtrykke et ønske om
at systemet er troværdigt, vedligeholdbart, skalerbart og stabilt i en endelig udgave.
3.2.1 Udstyr
PC-platform (Wintel); stationær arbejdsstation, bærbar, printer (kopimaskine).
3.2.2 Basisprogrammel
Applikationen er lavet med Borland C++Builder 5 Professional med Update Pack 1.
Rapporten er primært skrevet på Microsoft Word 2000 (DK) med illustrationer lavet med Vision 2000 International.
Værktøjerne har været afviklet under Microsoft Windows 98 SE (DK), ME (DK), NT 4.0 Workstation (DK)
og 2000 Professional (International). Undervejs har vi brugt Winzip og pkzip til pakning af kode og dokumentation og
kommunikeret med hinanden, holdet og underviserne med almindelige mail- og groupware-programmer.
Til at flytte implementeringen mellem forskellige maskiner hos os selv og på Niels Brock har vi lavet en lille .bat-fil:
ECHO off
CLS
ECHO Vent venligst...
REM Flytter kildekode til A-drev
REM verify og overwrite sat
REM 2001, Niels Grove-Rasmussen
DEL a:. /q
ECHO Disketten er renset.
COPY Projkopi.bat a: /v /y
COPY *.bpg a: /v /y
COPY *.bpr a: /v /y
COPY *.h a: /v /y
COPY *.cpp a: /v /y
COPY *.dfm a: /v /y
COPY *.doc a: /v /y
COPY *.db a: /v /y
COPY *.px a: /v /y
COPY *.val a: /v /y
ECHO.
ECHO Filerne er kopieret til diskette.
PAUSE
Beskrivelsen af filtyperne kommer senere i denne rapport.
3.2.3 Systemer og apparater
Single-Tier databasearkitektur, der gør at systemet kan køre stand-alone.
Alias (Alia-MuGro) skal sættes op på hver klient.
WinTel platform generelt.
3.2.4 Designsprog
Vi har baseret os på UML med den notation der benyttes i "Objektorienteret Analyse og Design"
[Matiassen et al] fra modulet Grundlæggende systemudvikling (gsu).
Vi har implementeret en single-tier løsning, men en endelige udgave af systemet vil sandsynligvis være
en klient-server implementering, eventuelt med dedikerede systemer til database, brugeradministration,
databasetilgang (connection) eller storage.
Vi går som sagt ud fra at der findes systemer til administration af medarbejder, kunder og udstyr,
og at disse systemers grænseflader er standardiserede og veldokumenterede.
Indtil videre vil vi nøjes med at komponenterne til grænseflader og den tekniske platform er i Borland C++ Builderen.
Borland C++ Builder viste sig i praksis at være svær at implementere vores egen klasse i systemet med,
så vi valgte at lade metoderne indgå i funktionaliteten, det vise de er implementeret i hændelser
(events) og grafiske elementer som knapper eller kombobokse. Det gør så at det objektorienteret datalag
vi havde designet ikke bliver til noget, men for eksemplets skyld har vi medtaget definitionen af vores klasser i
bilag
Klassediagrammet transformerede vi til Paradox-tabeller, der er detaljeret beskrevet i
afsnit 4.2.2. Selve transformationen er som følgende:
Den centrale klasse Fejlmelding transformeres til tabellen T_Fejlmelding med primærnøglen ’Id’,
hvor associeringen til klassen Udstyr og aggregeringerne til klasserne Person og Medarbejder styres af
fremmednøglerne ’UdstyrId’, ’PersonId’ og ’MedarbejderId’. Attributten ’Status’ fra klassen Fejlmelding er
normaliseret i tredje orden i tabellen T_Status med fremmednøglen ’StatusId’ i T_Fejlmelding.
Attributterne ’Beskrivelse’ og ’Tidspunkt’ er transformeret til felterne af samme navn.
Tabellen T-Status indeholder foruden primærnøglen ’Id’ feltet ’Status’ der kommer fra attributten ’Status’
i klasserne Fejlmelding og Statuslog. Tabellen er som tidligere beskrevet en normalisering af attributten ’Status’
og ’Fejlstatus’ i klasserne Fejlmelding og Statuslog.
Klassen Troubleticket er transfomeret til tabellen T-Troubleticket med primærnøglen ’Id’.
Aggregeringen til klasserne Fejlmelding og Medarbejder og associeringen til klassen Udstyr kontrolleres
af fremmednøglerne ’FejlmeldingId’, ’MedarbejderId’ og ’UdstyrId’. Attributten ’Tilstand’ i klassen Troubleticket
er normaliseret i tredje orden i tabellen T-Tilstand med fremmednøglen ’TilstandId’ i T-Troubleticket.
Attributten ’Tidspunkt’ er transformeret til feltet ’Tidspunkt’.
Attributterne ’Tilstand’ og ’Tickettilstand’ i klasserne Troubleticket og Tilstandslog er nomaliseret i
tredje orden til tabellen T-Tilstand, der foruden primærnøglen ’Id’ indeholder feltet ’Tilstand’ som er
selve transformationen af attributterne.
Superklassen Person er transformeret til tabellen T-Person med primærnøglen ’Id’ og feltet ’Navn’
som kommer fra attributten ’Navn’. Vi finder det sandsynligt at et produktionssystem vil have delt oplysninger om fornavn og
efternavn i flere tabeller på grund af normalisering af efternavnet i første orden, da efternavne vil
optræde som repeterende grupper da der er flere der hedder for eksempel Jensen.
Subklasserne Kunde og Medarbejder er transformeret til tabellerne T-Kunde og T-Medarbejder
hver med primærnøglen ’Id’ og fremmednøglen ’PersonId’. T-Kunde indeholder desuden felterne
’Adresse’ og ’Telefonnr’ der kommer fra attributterne med samme navn i klassen Kunde.
I den virkelige verden ligger kundeoplysningerne i et separat kundesystem, hvor adressen er delt ud i flere felter og tabeller
på grund af normaliseringer af for eksempel postnummer og vej. Der vil sandsynligvis også være idé
i at normalisere telefonnummeret på nummergruppering til for eksempel fastnet eller mobilnet.
Vi går ud fra at i en endelig produktionsudgave af systemet er der et specielt system til administration af udstyret
(system-management), hvor oplysningerne er mere detaljeret og normaliseret ud i flere tabeller. I vores system er klassen
Udstyr transformeret til tabellen T-Udstyr der ud over den primære nøgle ’Id’ indeholder felterne
’Nummer’ og ’Beskrivelse’ som er direkte transformationer af attributterne af samme navn.
Logningsfunktionalieteten ligger som tidligere beskrevet i fem klasser, hvor klassen Problemlog
er superklasse og transformeres over i tabellen T-Problemlog. Foruden den primære nøgle ’Id’ indeholder
tabellen fremmednøglen ’MedarbejderId’ for aggregeringen mellem klasserne Problemlog og Medarbejder.
Attributten ’Tidspunkt’ transformeres direkte over i feltet ’Tidspunkt’. Vi går ud fra at der er så få
samtidige hændelser der skal registreres, at det ikke er værd at normalisere tidspunktet ud i en selvstændig tabel.
De fire klasser Beskrivelseslog, Reperationslog, Statuslog og Tilstandslog til logning
transformeres til tabellerne T-Beskrivelseslog, T-Reperationlog, T-Statuslog og T-Tilstandslog,
hver med den primære nøgle ’Id’ og en fremmednøgle til den tabel der skal logges – T-Fejlmelding,
T-Troubleticket eller T-Udstyr. Det loggede felt enten et kopifelt (’Fejlbeskrivelse’ og ’Beskrivelse’) i
logtabellen eller en normaliseret fremmednøgle (’StatusId’ og ’TilstandId’) til en mellemliggende tabel (T-Status
og T-Tilstand). Alle fire tabeller har en fremmednøgle ’ProblemId’ til tabellen T-Problemlog på
grund af aggregeringsstrukturen til klassen Problemlog.
Endelig er der oprettet tabellen T-User, der gemmer id på den medarbejder der er den aktuelle bruger,
det vil sige at ud over den primære nøgle ’Id’ er der kun feltet ’MedarbejderId’ der er fremmednøglet til
tabellen T-Medarbejder. Tabellen T-User er afledt af klassen Global.
Figur 2. Bachman-inspireret diagram over tabelrelationer. Fed skrift angiver tabelnavn,
understreget kursiv den primære nøgle og understreget fremmednøgler.
Vi har brugt Borlands Database Desktop der følger med C++Builder 5 til at oprette tabellerne som Paradox 7 tabeller.
Beskrivelsen af datatyperne er en oversættelse af Paradox typerne. I det følgende er tabellerne nævnt
i alfabetisk orden og beskrevet:
4.2.2.1 Tabellen ’T-Beskrivelseslog’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling | |
Primær nøgle |
| Fejlbeskrivelse |
Alfa |
128 | |
| ProblemId |
Langt heltal | |
Fremmednøgle til T-Problemlog |
| FejlmeldingId |
Langt heltal | |
Fremmednøgle til T-Fejlmelding |
4.2.2.2 Tabellen ’T-Fejlmelding’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling | |
Primær nøgle |
| Beskrivelse |
Alfa |
132 | |
| Tidspunkt |
Tidspunkt |
|
|
| UdstyrId |
Langt heltal |
|
Fremmednøgle til T-Udstyr |
| PersonId |
Langt heltal |
|
Fremmednøgle til T-Person for indmelder |
| MedarbejderId |
Langt heltal |
|
Fremmednøgle til T-Medarbejder for ansvarlig |
| StatusId |
Langt heltal |
|
Fremmednøgle til T-Status |
4.2.2.3 Tabellen ’T-Kunde’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Adresse |
Alfa |
132 |
|
| Telefonnr |
Alfa |
16 |
|
| PersonId |
Langt heltal |
|
Fremmednøgle til T-Person |
4.2.2.4 Tabellen ’T-Medarbejder’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Initialer |
Alfa |
4 |
|
| PersonId |
Langt heltal |
|
Fremmednøgle til T-Person |
4.2.2.5 Tabellen ’T-Person’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Navn |
Alfa |
132 |
|
4.2.2.6 Tabellen ’T-Problemlog’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Tidspunkt |
Tidspunkt |
|
|
| MedarbejderId |
Langt heltal |
|
Fremmednøgle til T-Medarbejder |
4.2.2.7 Tabellen ’T-Reperationslog’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Beskrivelse |
Alfa |
132 |
|
| ProblemId |
Langt heltal |
|
Fremmednøgle til T-Problem |
| UdstyrId |
Langt heltal |
|
Fremmednøgle til T-Udstyr |
4.2.2.8 Tabellen ’T-Status’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Status |
Langt heltal |
|
|
4.2.2.9 Tabellen ’T-Statuslog’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| StatusId |
Langt heltal |
|
Fremmednøgle til T-Status |
| ProblemId |
Langt heltal |
|
Fremmednøgle til T-Problem |
| FejlmeldingId |
Langt heltal |
|
Fremmednøgle til T-Fejlmelding |
4.2.2.10 Tabellen ’T-Tilstand’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Tilstand |
Langt heltal |
|
|
4.2.2.11 Tabellen ’T-Tilstandlog’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primærnøgle |
| TilstandId |
Langt heltal |
|
Fremmednøgle til T-Tilstand |
| ProblemId |
Langt heltal |
|
Fremmednøgle til T-Problem |
| TroubleticketId |
Langt heltal |
|
Fremmednøgle til T-Troubleticket |
4.2.2.12 Tabellen ’T-Troubleticket’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| Tidspunkt |
Tidspunkt |
|
|
| FejlmeldingId |
Langt heltal |
|
Fremmednøgle til T-Fejlmelding |
| MedarbejderId |
Langt heltal |
|
Fremmednøgle til T-Medarbejder |
| UdstyrId |
Langt heltal |
|
Fremmednøgle til T-Udstyr |
| TilstandId |
Langt heltal |
|
Fremmednøgle til T-Tilstand |
4.2.2.13 Tabellen ’T-User’
| Navn |
Type |
Størrelse |
Beskrivelse |
| Id |
Autooptælling |
|
Primær nøgle |
| MedarbejderId |
Langt heltal |
|
Fremmednøgle til T-Medarbejder |
4.2.3 Filer
I Paradox arbejder primært vi med disse tre filtyper [Paradox 5.0]:
- .db indeholder en Paradox tabel. Det vil sige at for eksempel tabellen T-Fejlmelding ligger i filen T_Fejlmelding.db.
- .px indeholder det primære index til en Paradox tabel
- .val har validitetstjek og referentiel integritet for en Paradox tabel
Denne struktur er temmelig forskellig fra – og bedre end – Access som vi hidtil har arbejdet i,
hvor tabellerne ligger sammen med alle andre oplysninger om databasen i en .mdb-fil.
4.2.4 Håndtering af kunde, medarbejder og udstyrstabel
I vores system har vi implementeret adgang fra vores brugergrænseflade til disse tabeller, fordi det er krævet i opgaven.
Vi vil dog i et endeligt system anbefale at disse bliver ændret til systemgrænseflader, og systemerne bliver adskilt.
Grunden hertil er at en kunde- og udstyrshåndtering i sig selv er temmelig kompleks, og kan hurtigt blive et væsentligt
stykke værktøj i regnskabsøjemed. Derfor dur det ikke at system for det første gøres mere usikkert
ved at lade mange forskellige funktioner få adgang til disse data, og for det andet ikke have nogen form for historik.
Det samme gør sig gældende i både udstyrstabellen, og medarbejdertabellen.
Vi har til dels lagt op til dette i vores systemdesign, ved at undlade at normalisere udstyr ud på nogen som helst måde.
Det vil sige at selv om der er 10.000 ens apparater, vil disse blive registreret som 10.000 enheder, som intet har til fælles.
Denne datahåndtering gør sig på samme måde gældende i både kunde og medarbejder-håndtering,
dog med den ændring at der er en smule normalisering i disse klasser.
Som følge af vores anbefaling vil der flere gange i rapporten blive handlet overens med vores overbevisning om at kunden
har fulgt vores instrukser.
En del af ovenstående anbefaling er draget af vores erfaring blandt andet fra Videregående SystemUdvikling (vsu),
hvor vi skulle konstruere et Hardware (Inventory) system for ATP-huset. Hér fik vi en indsigt i kompleksiteten ved et
sådanne system. Vi mener at den udstyrsregistrering vi er kommet ud i her, vil på mange områder minde om
det system som vi fik konstrueret til ATP-huset.
4.3.1 Struktur
Projektgruppen (PG_Telefejl) indeholder kun ét projekt (P_TeleFejl).
I dette projekt er der en startenhed (U_TeleFejl) hvorfra de øvrige projektenheder hentes ind i programmet med
include-sætninger.
Klassen Global er blevet implementeret som private metoder til hver enhed (unit) og tabellen T-User, som er beskrevet tidligere.
Koden er fordelt over projektets enheder (units) der er repræsenteret ved formularer (Form) eller dialoger (Dial).
Sammenhængen mellem projektets units er hér skitseret:
Figur 3.Sammenhænge mellem vinduerne.
4.3.1 Visuelle elementer
Figur 4. Logon til systemet (Dial_Logon).
Et logonvindue (Dial_Logon) håndterer adgangen til systemet, der repræsenteres af et vindue
(Form_TeleFejl) med de tre valgmuligheder Udstyr, Indmelding og Fejlhåndtering.
I en produktionsversion af systemet er det meningen at der sker en single-signon så informationer
om brugeren hentes fra et generelt sikkerhedssystem som for eksempel NT Domainmanager eller RACF.
Figur 5. Systemets hovedvindue (Form_TeleFejl).
Hver valgmulighed åbner et nyt vindue men lader hovedvinduet stå så det er mulig at
have de tre valgmuligheder åbne på samme tid.
Valget Udstyr giver en oversigt (Form_Udstyr) over udstyr registreret i systemet.
Der er redigeringsmulighed direkte i hvert stykke udstyr.
Figur 6. Udstyrsoversigt (Form_Udstyr).
Vinduet til indrappotering af fejl opsamler data om en fejl og lægges dem ned i databasen.
Figur 7. Vindue til indrapportering af en fejl (Dial_Indraportering).
En fejl kan indmeldes enten af en kunde eller en tekniker, hvilket vi har oprette knapper til.
Hvis det er en kunde der indmelder en fejl finder vi det mest hensigtsmæssigt at gå ud fra kundens telefonnummer.
Figur 8. En kunde findes ud fra telefonnummeret (Dial_IndmelderKunde).
Knappen ’Slet kunde’ sletter den valgte kunde, og knappen ’Ny kunde’ bruges til at oprette en ny kunde.
Hér er en mulighed for at forbedre brugergrænsefladen.
Figur 9. En ny kunde oprettes (Dial_KundeNy).
Hvis det er en tekniker, der indmelder en fejl, vil det være nemmest at gå ud fra teknikerens initialer –
som vi går ud fra han/hun selv kender...
Figur 10. Teknikeren findes ud fra initialerne (Dial_IndmelderTekniker).
Vinduet giver også mulighed for at slette eller redigere den aktuelle tekniker eller oprette en ny tekniker.
Vi har ikke implementeret en redigering af teknikeren, hvilket systemet gør opmærksom på.
Figur 11. Der er ikke implementeret en redigering af en tekniker.
Teknikeren oprettes med et minimum af oplysninger.
Figur 12. Ny tekniker oprettes (Dial_TeknikerNy).
Selve fejlmeldingen dannes først som ny post i databasen når der vælges ’OK’ og alle data er tilstede.
Hvis der mangle en eller flere oplysninger melder systemet det til brugeren og sætter fokus på det aktuelle element i vinduet.
Figur 13. Information om hvilken oplysning der mangler i en fejlmelding.
Figur 14. Fokus er sat på det element der mangler data.
Vinduet til fejlbehandling (en lidt misvisende betegnelse) er centralt for systemets funktionalitet,
idet det giver overblik over hvilke fejlmeldinger der er på en given person,
og hvilke troubletickets der er til hver af disse fejlmeldinger samt hvilke reparationer og ændringer
der har været på den aktuelle fejlmelding og troubleticket.
Dette er lavet ved hjælp af en tre-leddet master-detail kæde.
Figur 15. Vinduet til fejlbehandling (Form_Fejlbehandling).
Den første fane viser reparationer og anden fane giver en oversigt over ændringer
for den enkelte fejlmelding og troubleticket.
En fejlmeldings beskrivelse ændres med knappen ’Ny beskrivelse’, hvor ændringen bliver logget.
Figur 16. En ny beskrivelse til en fejlmelding (Dial_BeskrivelseNy).
En reparation oprettes med knappen ’Reperation’ der ligger i hver reparationsfane.
Figur 17. En reperation beskrives (Dial_Reperation).
En ny troubleticket oprettes ved hjælp at knappen "Ny", hvor der vælges mellem faste muligheder.
Figur 18. Vinduet Ny Trouble ticket (Dial_TroubleticketNy).
Når alle tre felter har fået valgt en værdi, læses de i vinduet Fejlbehandling.
Hvis en eller flere værdier mangler bliver brugeren gjort opmærksom på dette
og fokus sættes på det tomme felt.
Figur 19. Fejlmelding for manglede værdi i vinduet Ny Trouble ticket.
Komboboksene ’Skift status’ og "Skift tilstand’ udløser en logpost og en opdatering af
henholdsvis en fejlmelding og en troubleticket ved exit.
I C++ Builder er disse filtyper [Reisdorph] interessante:
-
.cpp er C++ kildekode. Der findes en sådan fil til hver enhed (Unit) og så
har vi selv lavet en til implementering af vores klasser
- .dfm er en form-fil hvor beskrivelsen af en form og dens komponenter er gemt i en resursefil
- .h er en C++ headerfil hvor for eksempel klasser defineres.
- .bpr er projektets makefil. Projektgruppens makefil er en .bpg-fil.
Vi har oprettet projektgruppen PG_TeleFejl som kun indeholder ét projekt –
P_TeleFejl. Koden som er genereret af C++ Builder ses i Appendix A.
Da C++ Builder er så omfangsrigt et miljø, viste det sig hurtigt at være mest
hensigtsmæssigt at benytte C++ Builderens units frem for egne klasser.
Blandt andet på grund af den indbyggede databaseadgang i C++ Builderen.
Systemet består af flere filer med kildekode der her hægtet sammen med include-kommandoer.
Figur 20. Include-struktur i C++ Builders projekt.
Filen vcl.h er hovedfilen for Borlands Visual Component Library og indeholder blandt andet
"typerne" String og DateTime. "diverse Builder.hpp" indikerer at C++ Builder miljøet
selv sætter en del forskellige definitioner til at blive inkluderet i det enkelte modul (unit).
Vi har desværre ikke den store viden inden for struktureret test af et system,
men vi har forsøgt at teste hvert vindue og hver tabel med forkerte eller manglende data.
Vi mener at have dækket de værste huller, men en egentlig brugertest –
endsige struktureret brugertest – har vi ikke foretaget.
I de tilfælde hvor vi har kunne se problematiske situationer har vi lavet en fejlmelding,
der som oftest giver brugeren mulighed for at indsætte manglende data.
Vi har godt nok implementeret en Fejl-metode i hvert modul (unit), men den er kun brugt i systemtest.
Vi har arbejdet sammen siden vi startede på datamatikeruddannelsen,
men i de tidligere projekter har vi været i en dobbelt så stor gruppe.
Vi har kunnet mærke at halvdelen af gruppen er væk ved at der er mere arbejder og
at modspillet ikke er helt så mangfoldigt.
Rapporten gik vi ret tidligt i gang med, og det har været en stor hjælp at kunne bruge den
som dokumentation for hvilke idéer der har været i forskellige elementer og konstruktioner.
Det har så blandt andet medført at analysedelen er noget mere detaljeret end dét
den endelige implementering benytter.
Et løst overslag over tidsforbruget vil være en mandemåned.
I opgaven er det givet at man skal oprette og nedlægge både kunder og ansatte, uden historik.
Samtidig skal alle fejlmeldinger, samt rettelser til et givet problem logges, og gemmes i fem år.
Ved sletning af en kunde, eller ansat vil en stor del af loggen miste sin værdi,
da den vil indeholde en række tomme referencer.
Når et stykke udstyr slettes, skal også historikken slettes. I dette tilfælde reperationsloggen.
Det vil sige at langsomt forringes værdien af problemloggen. Den vil i sidste ende indeholde en Id, som er sagen irrelevant,
et tidspunkt og en medarbejderId, som kan være en blind relation. Loggen vil referere til et stykke udstyr,
som er ukendt da det er slettet og en kundeId, som også er ubrugelig da kunden ikke er kunde hos os mere.
Kort sagt en masse referencer, som er ganske intetsigende.
Det samme gør sig gældende ved en logning af troubletickets. Efter fem år kan man måske kun se
at en troubleticket har haft en bestemt status. Hvem der har oprettet den, rettede i den, og hvilket stykke udstyr
den har været tilknyttet, eller hvem der har håndteret den vil ikke være til at opspore.
Endelig er der et problem ved ikke at have log på kunder. Hvis man har et bestemt telefonkabel,
der går fra central og ud til kunde, og der sker fejl på dette vil det blive logget.
Når kunden flytter vil fejlen og kablet flytte med ham rent logisk, men i virkeligheden vil kablet sandsynligvis
blot få en ny kunde tilknyttet. Der vil hurtigt gå rod i hvem der sidder med hvilket udstyr, og hvor fejlene rent fysisk er sket.
- Ændring af medarbejderdata.
- Man kan afslutte en sag, selvom der er troubletickets på.
- Filtrering af rettede fejl.
- En sorteret liste over for eksempel fejlmeldinger efter alvorlighed.
- Der er en direkte sammenhæng mellem en troubletickets tilstand og om der er tilknyttet en tekniker.
- En troubleticket kan ikke overdrages til andre teknikere.
- Filtrering af lukkede troubletickets.
- Sletning af udstyr.
En del af disse funktioner er programmeringsmæssigt trivielt materiale, og vil til forveksling minde om andre lignende funktioner.
Under dette ligger blandt andet punkt 1.
Da en stor del af vores tid er gået med at finde ud af vores udviklingsmiljø,
og store dele af implementeringen er foregået på Borland C++ Builders præmisser,
er vi rendt ud i tidsmæssige problemer.
Generelt har vi valgt at implementere forskellige funktionaliteter frem for principielle gentagelser.
Sidst men ikke mindst er vi af den overbevisning at flere af de nævnte punkter i opgaven ligner
modsigelser eller forringelse af en historiks kvaliteter (se begrundelse andetsteds).
Derfor har vi tilladt os at nedprioritere visse dele af implementeringen.
Vi har bemærket hvor meget undervisning der har været i selve pensum, og hvor lidt der har været i C++ Builder...
Det har blandt andet betydet at vi ikke har haft den ønskede tid til at programmere struktur og funktionalitet i systemet.
Funktionslagets størrelse mener vi er ganske stort sammenlignet med den afsatte tid til projektet og vores manglende erfaring
med udviklingsmiljøet.
Vi mener selv vi har fået fat i kernen af opgaven, og fået løst de generelle problematikker der er forbundet med denne.
I vores, efter eget skøn, stærke design vil de ovenstående mangler relativt nemt kunne implementeres -
hvis man har den fornødne tid.
Hillerød, 20. maj 2001
________________________________
Mikkel Munksgaard
________________________________
Niels Grove-Rasmussen
[Main og Savitch] Michael Main og Walter Savitch:
Data Structures and other Objects Using C++
(2. udgave, 2001, Addison Wesley Longman, ISBN 0-201-70297-5)
[Reisdorph] Kent Reisdorph:
Teach Yourself Borland C++Builder 3 in 21 Days
(1998, Sams Publishing, ISBN 0-672-31266-2)
[Rolland] F.D. Rolland:
Start på SQL
(2001, IDG Forlag, ISBN 87-7843-169-7)
[Hollingworth et al] Jarrod Hollingworth, Dan Butterfield, Bob Swart og Jamie Allsop:
C++Builder 5 Developer’s Guide
(2001, Sams Publishing, ISBN 0-672-31972-1)
Vi har også benyttet nedenstående som opslagsværker:
[Stoustrup] Bjarne Stroustrup:
The C++ Programming Language – Special Edition
(2000, Addison Wesley Longman, ISBN 0-201-70073-5)
[Groff og Weinberg] James R. Groff og Paul N. Weinberg:
LAN Times Guide to SQL
(1994, Osborne McGraw-Hill, ISBN 0-07-882026-X)
[Paradox 5.0]:
User’s Guide – Borland Paradox for Windows Version 5.0
(1994, Borland International, Part# PDX1150WW21774)
[Mathiassen et al] Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen og Jan Stage:
Objektorienteret analyse og design
(1998, 2. udgave, Forlaget Marko, ISBN 87-7751-129-8)
8.13.2.1 P_Telefejl.bpr
Denne fil har vi ikke listet, da det er en resursefil med en del irrelevante parameteroplysninger.