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.

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.

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.

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

  1. For hvert subproject vises det aktuelle tidsforbrug i dage og det estimeret tidsforbrug samt forskel på disse.

  2. Desuden vises en total difference på alle subprojects.

Main success scenario:

1. Brugeren markerer et projekt som aktuelt

2. Brugeren vælger at se statistikken for projektet.

3. Statistikken vises

Extensions:

1. Brugeren har ikke markeret et projekt

   1. 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

  1. For hvert project vises det aktuelle tidsforbrug i dage og det estimeret tidsforbrug samt den samlede difference.

  2. Desuden vises en total difference på alle projects.

Main success scenario:

4. Brugeren markerer et projekt som aktuelt

5. Brugeren vælger at se statistikken for projektet.

6. Statistikken vises

Extensions:

2. Brugeren har ikke markeret et projekt

   1. 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:

7. Brugeren vælger et subproject

8. Brugeren præsenteres for muligheden for at ændre start- og sluttidspunkt

9. Det aktuelle subproject bliver opdateret

Extensions:

3. Brugeren vælger en dato der ligger efter projektets løbetid

   1. Brugeren bliver meddelt om fejlen

4. Brugeren vælger en slutdato, der ligger før startdato

   1. 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".

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:

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.

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:

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.

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. )

SD: Nyt projekt

Ovenstående figur viser et sekvensdiagram for hvordan et projekt oprettes i systemet netop nu.

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.

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å.

Overordnet systemmodel

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.

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: