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:

Use Case: Oprettelse af subprojekt

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
  
• Der er oprettet et projekt i systemet

Success guarantee (postconditions):

• Subprojektet er gemt i systemet og fremgår i kalenderen i den angivne tidsperiode.
  

Main succes scenario:

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

Extensions:

• 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

Domænemodel v. 5

Efter diskussion reducerede vi v. 1 til denne model.

Domænemodel v. 1

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.

SSD - Oprettelse af projekt

Use Case: Oprettelse af projekt

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
  

Success guarantee (postconditions):

• Projektet gemmes i databasen og fremgår af kalenderen

Main success scenario:

1. Brugeren vælger at oprette et nyt projekt.
2. Brugeren indtaster start- og slutdato, titel, og evt. en kort beskrivelse af projektet.
3. Systemet viser kalenderen for det oprettede projekt.

Første skitse af GUI

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.

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

Begyndelsen

Så er vi i gang med den indledende fase - forskellige artefakter følger.

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.