Informatics 122 Software Design II Lecture 2 André van der Hoek Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. April 18, 2019 – 13:12:25 (c) 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek Today’s Lecture Implementation design objectives Examples Day MultiPlotter ServiceCallDatabase Assignment 2a April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Three Goals of Implementation Design Provide a shared plan to follow Consistency Ensure the plan meets its recipients’ needs Helpfulness Ensure the solution is appropriate Effectiveness April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek But How to Get There? Practice, practice, practice… April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek But How to Get There? Practice, practice, practice… Examples, examples, examples… April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek But How to Get There? Practice, practice, practice… Examples, examples, examples… Some guidelines exist April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Fundamental Principles Rigor Separation of concerns modularity abstraction Anticipation of change Generality Incrementality April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

During the Design Process Strive for grouping related functionality (high cohesion) metaphor guides decisions understandability Strive for ungrouping semi-related functionality (high cohesion) untangling concerns that do not need to be tangled evolvability Strive for reducing interdependency (low coupling) changes do not propagate reuse is facilitated maintainability All aid in dividing work April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek Class Design Cohesion Completeness Convenience Clarity Consistency April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Interfaces – The Key to Class Design (Good) Interfaces are rigorously and formally defined (Good) Interfaces separate concerns (good) interfaces modularize a system (good) interfaces abstract implementation details (Good) Interfaces anticipate change (Good) Interfaces present generalizations (Good) Interfaces promote incrementality April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek Software Qualities Correctness Reliability Robustness Performance User friendliness Verifiability Maintainability Repairability Safety Evolvability Reusability Portability Understandability Interoperability Productivity Size Timeliness Visibility These qualities may be in conflict with each other April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

© 2006 University of California, Irvine – André van der Hoek Example 1: Day April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Example 2: MultiPlotter April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Example 3: ServiceCallDatabase April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Assignment 2a: Basic Structure Implement the game “Theseus and the Minotaur” according to the UML design provided on the course web site You are free to make any updates to the design you desire, but if you do so they must be properly documented and your implementation has to follow your new design A sample running version of the game is available on the web http://www.logicmazes.com/theseus.html compared to this game, we do not use walls, but blocks to delineate possible paths April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Assignment 2a: Game Rules Neither the player nor the Minotaur can move through blocks During the game, first, the player gets a turn, where they can move, up, down, left or right, or simply delay without moving After the player's turn, the Minotaur takes two turns, and on each it does the following: it tests if it can move horizontally and get closer to the player if it can, it will move one square horizontally if it cannot, it will test if it can move vertically and get closer to the player if it can, it will move one square vertically if it cannot move either horizontally or vertically, then it just skips that turn After the Minotaur takes its two turns, the player takes another turn, and so on The game ends if the player reaches the exit (victory!), or if the Minotaur is on the same space as the player (defeat!) April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Assignment 2a: Input File Encoding The game is to be run from the command line, with a filename as parameter this filename must point to an input file containing a maze from which Theseus has to escape a sample input file is provided on the course web site Encoding of the input file 0 = empty space (accessible to Theseus and the Minotaur) 1 = brick (not accessible to Theseus and the Minotaur) E = exit (the Minotaur can move over an exit) P = player M = Minotaur April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Assignment 2a: Game Input Input will be through the keyboard only Keys to use a = move left d = move right w = move up x = move down s = delay (choose not to move) April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Assignment 2a: A Wrinkle Since the basic design was completed, the customer has asked for the addition of one new game element: water the Minotaur cannot move over water the player can move over water In the sample maze, water is denoted by a “w” April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek

Assignment 2a: Deliverables A print-out of your final, updated UML design with updates as you see fit to adjust for the presence of water, and to make any other improvements that you deem necessary A print-out of your design rationale which changes did you make to the original design, and why? A print-out of your source code A running version of your game (as a JAR) Print-outs are to be handed in in class, the JAR must be e-mailed to andre@ics.uci.edu and abaker@ics.uci.edu April 18, 2019 – 13:12:25 © 2006 University of California, Irvine – André van der Hoek