1. Group 3 Ballfinder a highly modifiable system

2. Introduction Quality attribute: Modifiability Environment: Random maze Known number of balls One light source

3. Quality attribute scenario 1 The developer wishes to change or add modules to the system

4. Quality attribute scenario 2 The user changes the maze. The robot should still be able to do its tasks

5. Other scenarios The user changes the number of balls. The robot incorporates the new value. The user changes the drop-off-point (light intensity treshold). The robot is able to deliver the balls appropriately. The user increases the robots speed; the robot starts moving faster and it is still able to handle its tasks without crashing. The robot gets stuck, then gets unstuck.

6. Logical view 1 Toolkit classes AIControllers Abstract AIController

7. New AIController subclass

8. Main controllers

9. Complete logical view

10. Process view

11. FindBall algorithm

12. DropBallCloseToLight algorithm

13. What have we learned? Architecture driven software development The architecture design process was more time consuming than expected Hard to share the workload among the architecture developers The ATAM process can be a useful evaluation tool, although it might be more suited for larger projects.

14. Achievements/Findings A highly modifiable architecture The controller works quite well, despite some minor quirks and the buggyness of the simulator Poorly documented simulator; We discovered things about the simulator during implementation which we would have liked to have known during architecture design

15. Conclusion We have achieved our goals The usefulness of software architecture design increases dramatically with experience The architecture was helpful during implementation

16. ?