Klassediagrammet er blevet opdateret så det stemmer overens med arbejdet i 4 - og 5.iteration. Klasserne UserDirectory og statistikklasser er blevet tilføjet.
2007/05/30
Nyt klassediagram
Klassediagrammet er blevet opdateret så det stemmer overens med arbejdet i 4 - og 5.iteration. Klasserne UserDirectory og statistikklasser er blevet tilføjet.
4. iteration slut, 5.iteration startet
4. iteration er idag så småt færdig. Det meste kode er implementeret og virker ganske godt. Vi mangler blot lidt småjusteringer.
Vi har derfor startet 5. iteration, hvor vi vil arbejde med hvordan brugeren opretter sig som bruger og hvordan brugeren logger ind. Oprettelse af grupper og tilmelding til grupper ligger i god forlængelse af hvordan brugeren opretter sig som bruger og hvordan brugeren logger ind. Det er derfor også funktioner vi vil behandle under denne iteration.
Vi har færdiggjort Use cases og SDer, så det grundlæggende arbejde er på plads i forhold til at begynde på at implementere kode.
Her ses use cases:
Use Case: Oprettelse af bruger
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er ikke oprettet i systemet
• Brugeren er ikke logget ind
Success guarantee (postconditions):
• Brugeren oprettes i systemet
Main success scenario:
1. Brugeren starter programmet
2. Brugeren kan vælge at logge ind eller oprette ny bruger
3. Brugeren vælger at oprette ny bruger
4. Brugeren angiver fornavn, efternavn, brugernavn og en kode, som
angives to gange
5. Systemet accepterer de angivne oplysninger og brugeren er nu oprettet
6. Brugeren kan igen vælge at logge ind eller oprette ny bruger
Extensions:
1. Det angivne brugernavn eksisterer allerede i systemet
a. Brugeren bliver bedt om at skrive et nyt brugernavn.
2. Brugeren har ikke angivet den samme kode begge gange
a. Brugeren bliver bedt om at skrive koden igen
3. Brugeren har ikke angivet alle fornødne oplysninger
a. Brugeren bliver bedt om at angive alle oplysninger
4. Brugeren vælger at annullere oprettelsen
a. Bruger kan vælge at logge ind eller oprette ny bruger
Use Case: Bruger log-in
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er ikke logget ind
• Brugeren er oprettet i systemet
Success guarantee (postconditions):
• Brugeren får adgang til systemet
Main success scenario:
1. Brugeren starter programmet
2. Brugeren kan vælge at logge ind eller oprette ny bruger
3. Brugeren vælger at logge ind
4. Brugeren angiver brugernavn og adgangskode
5. Systemet accepterer de angivne oplysninger og brugeren logges ind
Extensions:
1. Det angivne brugernavn eksisterer ikke i systemet
a. Brugeren bliver bedt om at angive et nyt brugernavn.
2. Brugeren har ikke angivet koden svarende til det angivne brugernavn
a. Brugeren bliver bedt om at prøve igen
3. Brugeren vælger at annullere log-in processen
a. Bruger kan vælge at logge ind eller oprette ny bruger
Use Case: Oprettelse af gruppe
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er oprettet i systemet
• Brugeren er logget ind
Success guarantee (postconditions):
• En gruppe oprettes i systemet tilknyttet brugeren
Main success scenario:
1. Brugeren vælger at oprette ny gruppe
2. Brugeren angiver gruppenavn og en kode, som angives to gange
3. Systemet accepterer den nye gruppe
4. Den nye gruppe tilknyttes brugeren
Extensions:
1. Det angivne gruppenavn eksisterer allerede i systemet
a. Brugeren bliver bedt om at angive et nyt gruppenavn.
2. Brugeren har ikke angivet den samme kode begge gange
a. Brugeren bliver bedt om at skrive koden igen
3. Brugeren har ikke angivet alle fornødne oplysninger
a. Brugeren bliver bedt om at angive alle oplysninger
4. Brugeren vælger at annullere oprettelsen
a. Brugeren vender tilbage til systemet
Use Case: Tilmelding til gruppe
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er oprettet i systemet
• Brugeren er logget ind
• Der er oprettet mindst én gruppe i systemet
Success guarantee (postconditions):
• Brugeren tilknyttes en eksisterende gruppe
Main success scenario:
1. Brugeren vælger at tilmelde sig en gruppe
2. Brugeren vælger ud fra de eksisterende grupper den gruppe han vil tilmeldes
3. Brugeren angiver en kode tilknyttet den valgte gruppe
4. Systemet accepterer koden
5. Brugeren tilknyttes den valgte gruppe
Extensions:
1. Den angivne kode svarer ikke til koden for den valgte gruppe
a. Brugeren bliver bedt om at angive en anden kode
2. Brugeren vælger at annullere oprettelsen
a. Brugeren vender tilbage til systemet.
Vi har derfor startet 5. iteration, hvor vi vil arbejde med hvordan brugeren opretter sig som bruger og hvordan brugeren logger ind. Oprettelse af grupper og tilmelding til grupper ligger i god forlængelse af hvordan brugeren opretter sig som bruger og hvordan brugeren logger ind. Det er derfor også funktioner vi vil behandle under denne iteration.
Vi har færdiggjort Use cases og SDer, så det grundlæggende arbejde er på plads i forhold til at begynde på at implementere kode.
Her ses use cases:
Use Case: Oprettelse af bruger
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er ikke oprettet i systemet
• Brugeren er ikke logget ind
Success guarantee (postconditions):
• Brugeren oprettes i systemet
Main success scenario:
1. Brugeren starter programmet
2. Brugeren kan vælge at logge ind eller oprette ny bruger
3. Brugeren vælger at oprette ny bruger
4. Brugeren angiver fornavn, efternavn, brugernavn og en kode, som
angives to gange
5. Systemet accepterer de angivne oplysninger og brugeren er nu oprettet
6. Brugeren kan igen vælge at logge ind eller oprette ny bruger
Extensions:
1. Det angivne brugernavn eksisterer allerede i systemet
a. Brugeren bliver bedt om at skrive et nyt brugernavn.
2. Brugeren har ikke angivet den samme kode begge gange
a. Brugeren bliver bedt om at skrive koden igen
3. Brugeren har ikke angivet alle fornødne oplysninger
a. Brugeren bliver bedt om at angive alle oplysninger
4. Brugeren vælger at annullere oprettelsen
a. Bruger kan vælge at logge ind eller oprette ny bruger
Use Case: Bruger log-in
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er ikke logget ind
• Brugeren er oprettet i systemet
Success guarantee (postconditions):
• Brugeren får adgang til systemet
Main success scenario:
1. Brugeren starter programmet
2. Brugeren kan vælge at logge ind eller oprette ny bruger
3. Brugeren vælger at logge ind
4. Brugeren angiver brugernavn og adgangskode
5. Systemet accepterer de angivne oplysninger og brugeren logges ind
Extensions:
1. Det angivne brugernavn eksisterer ikke i systemet
a. Brugeren bliver bedt om at angive et nyt brugernavn.
2. Brugeren har ikke angivet koden svarende til det angivne brugernavn
a. Brugeren bliver bedt om at prøve igen
3. Brugeren vælger at annullere log-in processen
a. Bruger kan vælge at logge ind eller oprette ny bruger
Use Case: Oprettelse af gruppe
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er oprettet i systemet
• Brugeren er logget ind
Success guarantee (postconditions):
• En gruppe oprettes i systemet tilknyttet brugeren
Main success scenario:
1. Brugeren vælger at oprette ny gruppe
2. Brugeren angiver gruppenavn og en kode, som angives to gange
3. Systemet accepterer den nye gruppe
4. Den nye gruppe tilknyttes brugeren
Extensions:
1. Det angivne gruppenavn eksisterer allerede i systemet
a. Brugeren bliver bedt om at angive et nyt gruppenavn.
2. Brugeren har ikke angivet den samme kode begge gange
a. Brugeren bliver bedt om at skrive koden igen
3. Brugeren har ikke angivet alle fornødne oplysninger
a. Brugeren bliver bedt om at angive alle oplysninger
4. Brugeren vælger at annullere oprettelsen
a. Brugeren vender tilbage til systemet
Use Case: Tilmelding til gruppe
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er oprettet i systemet
• Brugeren er logget ind
• Der er oprettet mindst én gruppe i systemet
Success guarantee (postconditions):
• Brugeren tilknyttes en eksisterende gruppe
Main success scenario:
1. Brugeren vælger at tilmelde sig en gruppe
2. Brugeren vælger ud fra de eksisterende grupper den gruppe han vil tilmeldes
3. Brugeren angiver en kode tilknyttet den valgte gruppe
4. Systemet accepterer koden
5. Brugeren tilknyttes den valgte gruppe
Extensions:
1. Den angivne kode svarer ikke til koden for den valgte gruppe
a. Brugeren bliver bedt om at angive en anden kode
2. Brugeren vælger at annullere oprettelsen
a. Brugeren vender tilbage til systemet.
2007/05/28
28. maj
I dag har vi arbejdet på 4. iteration samt GUI'en. Vi har fået impleteret det meste af koden til statistik dog mangler det at blive impleteret i GUI'en. GUI'en er blevet opdateret så subprojekter nu kun ses i toppen af skærmen.Vi har derudover skrevet nogle ting om GRASP-mønstre til rapporten.
2007/05/27
Breaking news
Det tidligere offentliggjorte klassediagram er allerede forældet, idet vi nu også arbejder med en SubProjectStatistics-klasse. Desuden skal subprojekter have en OrgEndDate, som gemmes ved oprettelsen, så der er noget at lave statistikken ud fra. Et opdateret klassediagram følger.
SD: Visning af statistik
Nedenstående SD-diagram viser systemets indre arbejdsgang, når brugeren vil se statistik for et projekt. Når brugeren vil se den overordnede statistik er arbejdsgangen den samme, blot kører GUIControlleren "getStatistics" på den aktuelle gruppe.
Nyt klassediagram
Vi har ændret i vores klassediagram og tilføjet statistik. Klassen time-slice er blevet slettet og derudover er det ikke længere muligt at subprojekter kan have flere subprojekter. Vi har tilføjet statistikklasserne; ProjectStatistics og AllProjectsStatistics som henholdvis administerer statistik over et specifikt projekt og alle projekter.
2007/05/26
Use cases
Her ses tre use cases for statistik-iterationen.
Use case: ”Visning af projektstatistik”
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
Brugeren er oprettet i systemet og logget ind
Et projekt er oprettet
Success guarantee (postconditions):
Der vises en statistik over det aktuelle projekt
For hvert subproject vises det aktuelle tidsforbrug i dage og det estimeret tidsforbrug samt forskel på disse.
Desuden vises en total difference på alle subprojects.
Main success scenario:
Brugeren markerer et projekt som aktuelt
Brugeren vælger at se statistikken for projektet.
Statistikken vises
Extensions:
Brugeren har ikke markeret et projekt
Brugeren kan ikke vælge statistik
Use case: ”Visning af overordnet statistik”
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
Brugeren er oprettet i systemet og logget ind
Et projekt er oprettet
Success guarantee (postconditions):
Der vises en statistik over alle projekter
For hvert project vises det aktuelle tidsforbrug i dage og det estimeret tidsforbrug samt den samlede difference.
Desuden vises en total difference på alle projects.
Main success scenario:
Brugeren markerer et projekt som aktuelt
Brugeren vælger at se statistikken for projektet.
Statistikken vises
Extensions:
Brugeren har ikke markeret et projekt
Brugeren kan ikke vælge statistik
Use case: ”Ændring af estimeret tidsforbrug på subproject”
Scope: Programmet under udvikling
Level: User-goal
Primary actor: Studerende
Stakeholders and interests: Studerende
Preconditions:
Brugeren er oprettet i systemet og logget ind
Et projekt er oprettet
Success guarantee (postconditions):
Det fremgår af GUI'en, at slut- eller starttidspunkt er ændret
Main success scenario:
Brugeren vælger et subproject
Brugeren præsenteres for muligheden for at ændre start- og sluttidspunkt
Det aktuelle subproject bliver opdateret
Extensions:
Brugeren vælger en dato der ligger efter projektets løbetid
Brugeren bliver meddelt om fejlen
Brugeren vælger en slutdato, der ligger før startdato
Brugeren bliver meddelt om fejlen
4. iteration: Statistik
Eftersom vi er fire i gruppen, er vi sideløbende med 3. iteration begyndt på de indledende øvelser til statistikfunktionaliteten - og dermed 4. iteration. I forbindelse med en diskussion omkring dette, fandt vi ud af at statistikken skulle være baseret på dage og, ikke som tidligere tænkt, på timer. Dermed blev "timeslice"-klassen overflødig.
Vi forester os umiddelbart at statistikken, skal udgøres af to specielle klasser i modellaget: Een til overordnet statistik og een til projektstatistik. Disse klasser skal så tage en gruppe, henholdsvis et projekt som argument ved oprettelsen og ved at spørge disse sammensætte en statistik. Projekter og grupper er information experts: Gruppen kender alle sine projekter, som igen kender subprojekterne.
Arbejdsgangen i systemet bliver så, at den oprindelige slutdato gemmes, når et subprojekt oprettes. Det er så muligt for brugeren at flytte slutdatoen, hvis tiden "skrider" og ud fra de to slutdatoer udregne henholdsvis overskridelser og "underskridelser".
Vi forester os umiddelbart at statistikken, skal udgøres af to specielle klasser i modellaget: Een til overordnet statistik og een til projektstatistik. Disse klasser skal så tage en gruppe, henholdsvis et projekt som argument ved oprettelsen og ved at spørge disse sammensætte en statistik. Projekter og grupper er information experts: Gruppen kender alle sine projekter, som igen kender subprojekterne.
Arbejdsgangen i systemet bliver så, at den oprindelige slutdato gemmes, når et subprojekt oprettes. Det er så muligt for brugeren at flytte slutdatoen, hvis tiden "skrider" og ud fra de to slutdatoer udregne henholdsvis overskridelser og "underskridelser".
2007/05/25
3. iteration: GUI
Efter at have afleveret kommunikationseksamensopgaven, er vi på programmeringshesten igen. Vores tredje iteration går ud på at få en funktionel GUI op at stå. Deadline er søndag. Herunder en skitse:
2007/05/01
2. Iteration
Mål for 2. iteration
Målet for denne iteration er at udtænke, designe og implementere muligheden for at oprette projektaftaler i projektstyringssystemet.
Brugsmønstre
Oprettelse af ’appointment’
Scope: Programmet under udvikling
Level: User-goal
Primary actor: studerende
Stakeholders and interests: studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er oprettet i systemet og logget ind
• Et projekt skal være oprettet
Success guarantee (postconditions):
• En aftale oprettes, gemmes i databasen og ses i kalenderen med en farve der afspejler subprojektet.
Main success scenario:
1. Brugeren vælger at oprette en ny aftale
2. Brugeren angiver en overskrift, en beskrivelse, en dato og start- og sluttidspunkt. Desuden spørger systemet om den aktuelle aftale skal være fast knyttet til en ugedag eller en engangsaftale.
3. Aftalen vises i kalenderen.
Extensions:
1. Brugeren opretter en aftale et sted hvor der allerede findes en aftale
a. Brugeren bliver spurgt om man vil oprette en aftale der og vælger.
De sidste kategorier i use-case diagrammet har ikke givet mere mening at bruge her, så dem har vi undladt.
Opsamling
Denne iteration er ikke så stor, da vi har en stram deadline i denne fase og vores mål med ’appointment har derfor også været forholdsvis enkle og mindet meget om implementeringen af ’projekt’. Da det har mindet så meget om ’projekt’ har vi af den grund heller ikke gjort så meget ud af deciderede diagrammer, men blot implementeret koden med det samme. ”Obvious implementation” jævnfør Henrik Bærbak.
Vi er ved at have den grundlæggende struktur på plads og er derfor nået til et sted i processen hvor vi igen skal til at overveje hvad der vil være den bedste fremgangsmåde i forhold til bl.a. kalender elementerne.
Målet for denne iteration er at udtænke, designe og implementere muligheden for at oprette projektaftaler i projektstyringssystemet.
Brugsmønstre
Oprettelse af ’appointment’
Scope: Programmet under udvikling
Level: User-goal
Primary actor: studerende
Stakeholders and interests: studerende
Preconditions:
• Brugerens computer er forbundet til Internettet
• Brugeren er oprettet i systemet og logget ind
• Et projekt skal være oprettet
Success guarantee (postconditions):
• En aftale oprettes, gemmes i databasen og ses i kalenderen med en farve der afspejler subprojektet.
Main success scenario:
1. Brugeren vælger at oprette en ny aftale
2. Brugeren angiver en overskrift, en beskrivelse, en dato og start- og sluttidspunkt. Desuden spørger systemet om den aktuelle aftale skal være fast knyttet til en ugedag eller en engangsaftale.
3. Aftalen vises i kalenderen.
Extensions:
1. Brugeren opretter en aftale et sted hvor der allerede findes en aftale
a. Brugeren bliver spurgt om man vil oprette en aftale der og vælger.
De sidste kategorier i use-case diagrammet har ikke givet mere mening at bruge her, så dem har vi undladt.
Opsamling
Denne iteration er ikke så stor, da vi har en stram deadline i denne fase og vores mål med ’appointment har derfor også været forholdsvis enkle og mindet meget om implementeringen af ’projekt’. Da det har mindet så meget om ’projekt’ har vi af den grund heller ikke gjort så meget ud af deciderede diagrammer, men blot implementeret koden med det samme. ”Obvious implementation” jævnfør Henrik Bærbak.
Vi er ved at have den grundlæggende struktur på plads og er derfor nået til et sted i processen hvor vi igen skal til at overveje hvad der vil være den bedste fremgangsmåde i forhold til bl.a. kalender elementerne.
Opsamling på 1. Iteration
Vi har lavet et program der foreløbigt kan oprette projekter, subprojekter og appointments. Fundamentet for modellen er lagt og en foreløbig GUI er oppe.
bemærkninger: Det er ikke muligt at gemme noget i en database endnu, vi overvejer desuden at bruge en flad fil i stedet for, muligvis xstream som gemmer i xml-format som er nemt at bruge. Vi har desuden ikke implementeret kalenderen endnu, det viste sig at være mere tidskrævende end som så. Disse ting vil blive håndteret i en senere iteration, hvis det ligger inden for den tidshorisont vores projekt er begrænset af.
Vi har ændret i vores klassediagram der efter nyeste update ser således ud:
bemærkninger: Det er ikke muligt at gemme noget i en database endnu, vi overvejer desuden at bruge en flad fil i stedet for, muligvis xstream som gemmer i xml-format som er nemt at bruge. Vi har desuden ikke implementeret kalenderen endnu, det viste sig at være mere tidskrævende end som så. Disse ting vil blive håndteret i en senere iteration, hvis det ligger inden for den tidshorisont vores projekt er begrænset af.
Vi har ændret i vores klassediagram der efter nyeste update ser således ud:
Abonner på:
Opslag (Atom)
