6. iteration er slut, rapporten er ved at være færdig, systemet er ved at få implementeret de sidste detaljer og deadlinen er nær. Det sidste opdateret klassediagram vil blive vist herover. Vi siger tak for denne gang.
2007/06/05
Projektet er snart færdigt...
6. iteration er slut, rapporten er ved at være færdig, systemet er ved at få implementeret de sidste detaljer og deadlinen er nær. Det sidste opdateret klassediagram vil blive vist herover. Vi siger tak for denne gang.
2007/06/03
Status
Vi har påbegyndt 6. iteration, som handler om persistens, altså at gemme programmets tilstand. Det bliver den sidste iteration. Når den er færdig, har vi angrebet de vigtigste ting i systemet og er dermed ved at være i construction-fasen. Sideløbende med iterationen skriver og forfiner vi vores rapport, som vi har gjort i de tidligere iterationer.
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:
2007/04/27
Dagens arbejde
Og hvad har vi så lavet i dag? Det er efterhånden muligt at lave et subproject. Vi har anvendt polymorfi-mønstret til at finde ud af hvilke projekt brugeren aktuelt kigger på og som derfor skal have et subproject tilknyttet, når man vælger nyt subproject i menuen. Problemet er, at vi også har et pane i vores primære tabbed pane, som tænkes at indeholde en oversigt over alle projekter, og som derfor ikke kan have underprojekter. Vha. et interface kan vi behandle alle panes ens, og bede dem om et project (getProject). Hvis forespørgslen returnerer null, ved vi det er panen med alle projekter.
2007/04/26
GRASP-overvejelser
High Cohesion / Low Coupling: Den måde vi har lavet hele modellen på. Den måde vi har skåret tingene fra – i pakker – konstruktionen – iform af pakker viser lav kobling og høj samhørighed.
Infomation expert: En gruppe ved og holder styr på hvilket/hvilke projekter den har.
Creator: GUI-controlleren opretter alle vinduer – holdt sammen – gør det nemmere for senere ændring. Smart at have en creator der åbner alle vinduer.
Polymorphism: (Calendar nedarver fra Gregoriancalendar-klassen) En overvejelse som at vi måske kan bruge senere når GUI-controlleren skal oprette en aftale der både kan være et appointment og et sub-project.
Controller: Vi har 2 controllere – ansvaret bliver delt ud i nogle controllere og facader. Hvis ikke man gør det bliver klasserne for hårdt koblet.
Pure Fabrication: Vi har fx opdigtet en controller.
Indirection: Ansvarsfordeling – Hvert enkelt klasse skal kende sin facade og ikke engang controlleren. Hvis der skal ændres noget skal det kun ændres et sted. Dette lever desuden op til MVC – perspektivet.
Protected variation: Man kobler noget helt af – det har vi gjort i projektpanelet. Hvis der skal tilføjes noget eller ændres skal der ikke tilføjes noget til controlleren men kun til project panel. Dette er en fremtidssikring, da vi helt sikkert kommer til at ændre i vores project panel (flere attributter, mere beskrivelse osv. )
2007/04/25
SD: Nyt projekt
Ovenstående figur viser et sekvensdiagram for hvordan et projekt oprettes i systemet netop nu.
2007/04/24
Designmodel v. 2.
Vi havde en diskussion i forhold til hvordan vinduerne i projektstyringssystemet skal lyttes på: Vi overvejede om det ville være smart at lave en lytterklasse som lyttede på alle vinduer eller om der skulle være en selvstændig lytter på hvert vindue. Vi endte med at vælge den sidste model da det gav mest mening i forhold til informationexpert pattern.
Efter disse overvejelser ændrede vi lidt på designmodellen der nu ser således ud:
Vi er begyndt at modellere vores designmodel, dvs. vi har lavet skallen af programmet og implementeret metoder dog uden metodekroppe, desuden er vi begyndt på kodning af GUI'en.
2007/04/20
Commence programming!
Vi har nu produceret den første kode i vores projekt, jævnfør vores klassediagram og skitsen af det overordnede system. Det har givet anledning til en diskussion om programmets overordnede struktur.
Pt. forestiller vi os at en GUI-listeneren lytter på GUI'en og rapporterer videre til controlleren. Begrundelsen er, at vi ikke ønsker at vores controller skal blive alt for "bloated", som den potentielt kunne blive hvis den skulle håndtere begge dele. Desuden skaber det overblik ved at definere et konkret ansvar for begge klasser med henblik på at opnå lavest mulig kobling: Listeneren samler op på beskeder fra GUI-elementer (knapper etc.), så controlleren kan få nogle meningsfyldte beskeder.
Controlleren taler med model-laget, men GUI'en (i form af en GUI-controller) er ikke direkte koblet på de forskellige klasser i modellen (lav kobling). I stedet observerer GUI-controlleren på en model-facade, som giver besked når der skal opdateres, hvorefter selve programvinduet bliver opdateret. En af overvejelserne bag model-facaden, er, at hvis alle klasser i modellen skulle extende Observable, ville de ikke kunne extende noget andet, som vi senere kunne finde på.
Pt. forestiller vi os at en GUI-listeneren lytter på GUI'en og rapporterer videre til controlleren. Begrundelsen er, at vi ikke ønsker at vores controller skal blive alt for "bloated", som den potentielt kunne blive hvis den skulle håndtere begge dele. Desuden skaber det overblik ved at definere et konkret ansvar for begge klasser med henblik på at opnå lavest mulig kobling: Listeneren samler op på beskeder fra GUI-elementer (knapper etc.), så controlleren kan få nogle meningsfyldte beskeder.
Controlleren taler med model-laget, men GUI'en (i form af en GUI-controller) er ikke direkte koblet på de forskellige klasser i modellen (lav kobling). I stedet observerer GUI-controlleren på en model-facade, som giver besked når der skal opdateres, hvorefter selve programvinduet bliver opdateret. En af overvejelserne bag model-facaden, er, at hvis alle klasser i modellen skulle extende Observable, ville de ikke kunne extende noget andet, som vi senere kunne finde på.
2007/04/18
Mål for 1. iteration
I den første iteration er målet, at vi i vores system kan oprette projekter og subprojekter jævnfør vores use-cases. Det betyder at vi skal have udvidet vores klassemodel så den svarer til Model-View-Controller-mønstret og lavet nogle kommunikationsdiagrammer, som beskriver den indre arbejdsgang i systemet.
2007/04/17
Klassediagram v. 1
Med henblik på at komme videre i elaborationsfasen blev vi enige om at udforme et klassediagram for at danne grundlag for de kommende interaktionsdiagrammer. I udformningen af klassediagrammet, som tog udgangspunkt i vores domænemodel fik vi opklaret et par uklarheder. Kalenderen, for eksempel viste sig at være mere en konceptuel ting, end en egentlig klasse. Vi fik en del attributter på plads og føler os nu klar til at bevæge os yderligere ind i elaborationsfasen af vores første iteration.
Klassediagrammet har foreløbigt taget følgende form:
Klassediagrammet har foreløbigt taget følgende form:
2007/04/13
Use Case: Oprettelse af subprojekt
Scope: Programmet under udvikling
Level: User-goal
Primary actor: studerende
Stakeholders and interests: studerende
Preconditions:
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
- Der er oprettet et projekt i systemet
- Subprojektet er gemt i systemet og fremgår i kalenderen i den angivne tidsperiode.
- Brugeren vælger at oprette et subprojekt under det aktuelle projekt
- Brugeren angiver projektnavn, beskrivelse, tidsperiode, evt. andre tilknyttede brugere og evt. sideantal, hvis subprojektet er en tekst der skal skrives.
- Brugeren har ikke angivet et påkrævet felt
- Brugeren får besked om det (fx dialogbox)
- Brugeren har angivet en tidsramme, som koliderer med andre subprojekter/aftaler
- Brugeren får besked om det og kan vælge at acceptere eller afvise
2007/04/11
2007/04/10
Glossary
Appointment: Et tidsrum, hvor en eller flere gruppemedlemmer aftaler at mødes.
Calender: Brugerens personlige kalender, som holder styr på tidspunkter for "private events".
Group: En læsegruppe.
Private event: En privat begivenhed som udspiller sig i et bestemt tidsrum. Ex: Frokostaftale den 9/4 fra kl. 12.30 - kl. 13.30.
Project: Et projekt, som er defineret ved at have et start og et sluttidspunkt, en titel og en beskrivelse. Fungerer som
ramme for delprojekter.
Subprojekt: Et underprojekt, en del af et projekt, en delopgave. Har en en titel og en beskrivelse og udspiller sig i "timeslices".
Timeslice: Et tidsrum, som defineret som tiden mellem to tidspunkter. Ex: Mandag den 9/4-2007 fra kl. 14.00 - kl. 16.00.
User: En bruger, som er medlem af en læsegruppe ("group"). Den der benytter programmet.
Calender: Brugerens personlige kalender, som holder styr på tidspunkter for "private events".
Group: En læsegruppe.
Private event: En privat begivenhed som udspiller sig i et bestemt tidsrum. Ex: Frokostaftale den 9/4 fra kl. 12.30 - kl. 13.30.
Project: Et projekt, som er defineret ved at have et start og et sluttidspunkt, en titel og en beskrivelse. Fungerer som
ramme for delprojekter.
Subprojekt: Et underprojekt, en del af et projekt, en delopgave. Har en en titel og en beskrivelse og udspiller sig i "timeslices".
Timeslice: Et tidsrum, som defineret som tiden mellem to tidspunkter. Ex: Mandag den 9/4-2007 fra kl. 14.00 - kl. 16.00.
User: En bruger, som er medlem af en læsegruppe ("group"). Den der benytter programmet.
Use Case: Oprettelse af projekt
Scope: Programmet under udvikling
Level: User-goal
Primary actor: studerende
Stakeholders and interests: studerende
Preconditions:
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
- Projektet gemmes i databasen og fremgår af kalenderen
- Brugeren vælger at oprette et nyt projekt.
- Brugeren indtaster start- og slutdato, titel, og evt. en kort beskrivelse af projektet.
- Systemet viser kalenderen for det oprettede projekt.
Vision
"Vores projektsstyringssystem skal gøre det nemmere at organisere læsegruppens projekter. Det skal give overblik når gruppen har flere bolde, dvs. projekter, i luften på een gang."
Yderligere idé:
Det skal ske gennem et kalender-interface, hvor brugeren kan placere projekter. Hvert projekt kan bestå af flere underprojekter med et eller flere læsegruppemedlemmer tilknyttet. Hvert medlem har således sin egen kalender udover den fælles kalender. På hvert medlems kalender kan man indskrive private begivenheder og faste begivenheder (fx "fodbold hver onsdag fra 15-17"), så tiden kan planlægges. Når et projekt eller underprojekt er færdigt, kan det reelle tidsforbrug indskrives og en statistik genereres over dette. Desuden skal det fremgå af statistikken, hvor langt et projektet et nået i forhold til gennemførsel af alle underprojekter. Data ligger i en database på www, så den kan tilgåes fra alle steder. I øvrigt skal systemet naturligvis overholde de øvrige krav i projektbeskrivelsen.
Yderligere idé:
Det skal ske gennem et kalender-interface, hvor brugeren kan placere projekter. Hvert projekt kan bestå af flere underprojekter med et eller flere læsegruppemedlemmer tilknyttet. Hvert medlem har således sin egen kalender udover den fælles kalender. På hvert medlems kalender kan man indskrive private begivenheder og faste begivenheder (fx "fodbold hver onsdag fra 15-17"), så tiden kan planlægges. Når et projekt eller underprojekt er færdigt, kan det reelle tidsforbrug indskrives og en statistik genereres over dette. Desuden skal det fremgå af statistikken, hvor langt et projektet et nået i forhold til gennemførsel af alle underprojekter. Data ligger i en database på www, så den kan tilgåes fra alle steder. I øvrigt skal systemet naturligvis overholde de øvrige krav i projektbeskrivelsen.
Brainstorm
"Flytte kasser" = "variabel" GUI
Faste begivenheder (hver uge, fx. forelæsninger)
Database på nettet
Repository/fildeling
Dele kalender mellem medlemmer
Marker perioder, hvor alle har fri - den 5. kalender.
Programmet giver forslag til hvordan tiden skal fordeles.
Deadline-view (hvornår er hvilke deadlines? Evt. mulighed for at rykke alt hvis deadline skrider)
Forskellige views: Uge, dag, måned
Flere projekter med hver sin farve.
Forum til udveksling af beskeder
Status på projekt(er): Søjlediagram og "to-do", hvor mange sider har vi? Færdige projekter.
Medlemsskab af flere læsegrupper
Faste begivenheder (hver uge, fx. forelæsninger)
Database på nettet
Repository/fildeling
Dele kalender mellem medlemmer
Marker perioder, hvor alle har fri - den 5. kalender.
Programmet giver forslag til hvordan tiden skal fordeles.
Deadline-view (hvornår er hvilke deadlines? Evt. mulighed for at rykke alt hvis deadline skrider)
Forskellige views: Uge, dag, måned
Flere projekter med hver sin farve.
Forum til udveksling af beskeder
Status på projekt(er): Søjlediagram og "to-do", hvor mange sider har vi? Færdige projekter.
Medlemsskab af flere læsegrupper
2007/03/21
Eksamensvalg
Vi har valgt projektstyrings-projektet. Sporadiske overvejelserne omkring valget:
- Det er interessant at lave et projekt til studerende, så vi kan bruge os selv som brugere i bl.a. de iterative faser og under udviklingen af problem-domænet.
- Projektet lægger op til nogle spændende overvejelser om hvordan information skal repræsenteres i brugergrænsefladen.
- Vi forventer en proces hvor Larman's begreber vil blive brugbare, og medvirke til en god rappport.
Abonner på:
Opslag (Atom)
