1. Group 9 “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them”

2. Group members Mirela Divic Anders Magnus Braathen Hans Rasmussen Bjørn-Erik Stenbakk

3. Introduction Quality attributes in focus  Performance  Availability

4. Approach Phase 1:  Started out with Req. Spec. & Arch. design.  ….and doing it all over again Phase 2:  The ATAM Phase 3:  Implementation

5. Quality tactics Performance  Algorithm  Representation of the encountered world in the robots memory Availability  Preventing faults  Recovery

6. Our architecture Changed during implementation Described with three different views UML class diagram most valuable during implementation

7. Logical view

9. Development view 3. Controller 2. StateManager, PathRecorder 1. SensorInterpreter, Engine, Paths

10. Implementation Plan:  App. 1+ week figuring out the existing code and implemententing simple tasks  App. 1+ week making our Controller as we wanted it  App. 1+ week testing and writing final report  (NB! Everybody had other courses to attend as well)

11. Implementation The plan worked fairly well More time-consuming to implement simple tasks than expected More time-consuming to implement the final Controller Testing was done during implementation

12. Lessons learned (1/2) Framework:  Architecture depends on existing framework  Made a lot of ”hacks” to make it work

13. Lessons learned (2/2) ATAM  Evaluating another team’s architecture  Having our own architecture evaluated Programming AI

14. Results (1/3) Difficult to draw map by sensor-readings  Had to use a different approach  Robot best suited for following walls Excluding the need for complex search- algorithms

15. Results (2/3) The robot is able to:  Find and recognize balls  Find and recognize light  Record path when searching Efficient movement between encountered items  Avoid crashing and getting stuck (in most situations)

16. Results (3/3) Areas of improvement  Better recognition of balls  Controlled termination when finished or stuck  What to do when encountering a second ball

17. Conclusion Unable to fulfill all the requirements  Time consuming Final implementation differs somewhat from the original architecture Hard to keep architecture in focus  Simulator offers limited flexibility Low level experience in AI programming  Challenging task