Gruppe 5: Performance, Modifiability Tor-Erik Christian Bernt Johannes
Problem Lag en kontroller for en robot –Finn alle ballene og flytt de til lyset –Kan starte i 45 graders inkrementer –Kan starte hvor som helst på kartet –Problemet skal kunne løses i et vilkårlig kart
Kvalitetsattributter Problem: Performance og Modifiability gir konflikt Må prioritere Performance –Effektive algoritmer/løsninger –Minimal tidsbruk Modifiablity –Endre oppgaver –Endre sensorer –Bytte kart
Arkitektur
Tasks –definerer robotens oppførsel. –Svært gode tilpasningsmuligheter. Navigasjonsdata –Internt kart, oppdelt i celler. –Sensorinput via regelsett.
Arkitektur
Arkitektur: TaskList
Arkitektur: Navigasjon IMapObjectClassifie r interface ITask GridCell BehaviourController RobotController SensorCurrentRobotState TaskList SensorInterpreter Surroundings Planner Map MapAnalyzer MapObject interface IDebug ISensorRule interface IMapObjectSubscrib er
Arkitektur og performance Kunnskap om omverden –Map: Verdensbilde –Fjerner behovet for tidskritiske operasjoner. Prioritering av tasks Effektiv søkealgoritme
Arkitektur og modifiability Modularitet –Klar ansvarsfordeling –Veldefinerte grensesnitt Informasjonsgjemming Late binding
Hva har man lært Fokus på arkitektur på forhånd kan forbedre utviklingsprosessen. Revisjon av arkitektur er ikke til å unngå. Ukjent applikasjonsområde medfører endringer i arkitekturen. En arkitektur blir sterkt påvirket av arkitektene bak. ATAM krever mye forberedelser og trolig et større prosjekt.
Oppdagelser/resultater Laget en arkitektur som har vist seg å fungere, med kun begrensede endringer under implementasjonen Vanskelig å tolke sensordata Implementasjonen vår er ubrukelig for en ekte robot (Alt for stor, for mange antakelser :-)
Konklusjon Fokus på arkitektur og design har hjulpet noe Mangel på kunnskap rundt problemet medførte svært mye ekstraarbeid uten sammenheng med arkitektur Vanskelig å se sammenheng med andre applikasjonsområder, eksempelvis informasjonssystemer