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

2. © 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

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

4. © 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

5. © 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

6. © 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

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

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

9. © 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

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

11. © 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

12. © 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

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

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

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

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

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

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

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

20. 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 ed to and
April 18, 2019 – 13:12:25
© 2006 University of California, Irvine – André van der Hoek