Informatics 122 Software Design II

Informatics 122Software Design II Lecture 2André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. © 2009 University of California, Irvine – André van der Hoek

Aesthetics “a particular theory or conception of beauty or art : a particular taste for or approach to what is pleasing to the senses and especially sight” [Merriam-Webster] © 2009 University of California, Irvine – André van der Hoek

Design Aesthetics • What makes a given software design “beautiful”? • What is it that makes someone appreciate a particular software design? • What are the qualities that determine whether a particular software design is “good” or “bad”? • What is it, then, that we can strive for in creating a software design that will help others in appreciating it? © 2009 University of California, Irvine – André van der Hoek

Design Aesthetics • Different people will have a different aesthetic appreciation of different designs • as informed by their own, pre-existing knowledge • as informed by their own understanding of the design goals • as informed by their own ideas • Different roles in the software development project may have different aesthetic appreciation of different designs • coder • software performance engineer • software maintenance specialist • software tester • … © 2009 University of California, Irvine – André van der Hoek

goals (langs) knowledge (langs) knowledge (langs) activities tools tools activities ideas (langs) ideas (langs) Design Aesthetics • Subjective, as it should be goals (langs) representations (langs) © 2009 University of California, Irvine – André van der Hoek

Design Aesthetics • Subjective, as it should be • But we need some kind of shared “language”, some common touchstones that we can use to: • understand the underlying implications of certain designs • understand the intentions of designers • effectively frame our communication about designs © 2009 University of California, Irvine – André van der Hoek

Purpose of Implementation Design • An implementation design is a road map • An implementation design describes a path from application design to the outcome • An implementation design describes what the implementers should do • An implementation design is a guide towards future change © 2009 University of California, Irvine – André van der Hoek

Purpose of Implementation Design • An implementation design is a road map • understandable, unambiguous, consistent, helpful, … • An implementation design describes a path from application design to the outcome • correct, complete, concise, verifiable, effective, … • An implementation design describes what the implementers should do • elegant, partitionable, recomposable, resilient, … • An implementation design is a guide towards future change • evolvable, … © 2009 University of California, Irvine – André van der Hoek

More of a Shared Understanding (Not Perfect!) • An implementation design is a road map • understandable, unambiguous, consistent, helpful, … • An implementation design describes a path from application design to the outcome • correct, complete, concise, verifiable, effective, … • An implementation design describes what the implementers should do • elegant, partitionable, recomposable, resilient, … • An implementation design is a guide towards future change • evolvable, … © 2009 University of California, Irvine – André van der Hoek

Less of a Shared Understanding • An implementation design is a road map • understandable, unambiguous, consistent, helpful, … • An implementation design describes a path from system design to the outcome • correct, complete, concise, verifiable, effective, … • An implementation design describes what the implementers should do • elegant, partitionable, recomposable, resilient, … • An implementation design is a guide towards future change • evolvable, … © 2009 University of California, Irvine – André van der Hoek

Approaches to Date • Enumerate objectives • overall process • overall design • individual classes • Define principles • Provide strategies © 2009 University of California, Irvine – André van der Hoek

Objectives for Overall Process • Apply rigor • Separate concerns • modularize • abstract • Anticipate change • Generalize • Work incrementally © 2009 University of California, Irvine – André van der Hoek

Objectives for Overall Design • Strive for grouping related functionality (high cohesion) • Strive for ungrouping semi-related functionality (high cohesion) • Strive for reducing interdependency (low coupling) © 2009 University of California, Irvine – André van der Hoek

Approaches to Date • Enumerate objectives • Define principles • keep it simple, stupid! (KISS) • information hiding • acyclic dependencies • … • Provide strategies © 2009 University of California, Irvine – André van der Hoek

Keep It Simple, Stupid! (KISS) • Nothing should be more complicated than absolutely essential and, even then, everything should be analyzed as to whether it can be done simpler © 2009 University of California, Irvine – André van der Hoek

Information Hiding • Hide design decisions that are most likely to change, thereby protecting other parts of the program from change if the design decision is changed © 2009 University of California, Irvine – André van der Hoek

Acyclic Dependencies • Structure packages (grouping classes and interfaces) of a software system in such a manner that the dependencies among them form a directed acyclic graph (DAG) © 2009 University of California, Irvine – André van der Hoek

Approaches to Date • Enumerate objectives • Define principles • Provide strategies • program to the interface • refactor • apply software patterns • use aspects © 2009 University of California, Irvine – André van der Hoek

Purpose of Implementation Design • An implementation design is a road map • understandable, unambiguous, consistent, helpful, … • An implementation design describes a path from system design to the outcome • correct, complete, concise, verifiable, effective, … • An implementation design describes what the implementers should do • elegant, partitionable, recomposable, resilient, … • An implementation design is a guide towards future change • evolvable, … © 2009 University of California, Irvine – André van der Hoek

Purpose of Implementation Design • An implementation design is a road map • understandable, unambiguous, consistent, helpful, … • An implementation design describes a path from system design to the outcome • correct, complete, concise, verifiable, effective, … • An implementation design describes what the implementers should do • elegant, partitionable, recomposable, resilient, … • An implementation design is a guide towards future change • evolvable, … The approaches to date help, but much more remains to be done © 2009 University of California, Irvine – André van der Hoek

Why Aesthetics? • Aesthetics aims higher than “usable” or “complete” or … • It aims to set a bar for design for which we as professional designers should strive • designs that are elegant • designs that communicate their intent seamlessly • designs that overall exude an air of sophistication that sets them apart from ordinary designs • designs that others will appreciate, for the right reasons © 2009 University of California, Irvine – André van der Hoek

First Assignment: Ogre (Overview) • Your client reminisces about the classic DOS game Beast, wherein you push blocks to try to crush beasts which, in turn, try to eat you. • You are to create a UML, object-oriented design for a software implementation of a rough remake of Beast, called Ogre Beast Screenshot © 2009 University of California, Irvine – André van der Hoek

First Assignment: Ogre (Rules) • The game takes place on a 38 x 21 grid, which randomly contains: • A single hero • A large number of blocks and superblocks • A small number of enemies (ogres and superogres) • The player moves the hero orthogonally, with the keyboard. • Every time the player moves, each enemy also moves one space. • If an enemy touches a player, the player loses one life and the enemy disappears. If a player loses 3 lives, the game is over. • A player can push blocks in a line, but a superblock stops all movement. • Superblocks cannot be pushed. • The outer walls of the level are considered superblocks. • If an enemy is behind a pushed block, it is moved. If there is another block in the way, and it is a regular ogre, it is crushed and killed. • Superogres, however can only be crushed against superblocks and will just continue the push chain otherwise. • When all enemies are dead, the game is repopulated with objects. © 2009 University of California, Irvine – André van der Hoek

First Assignment: Ogre (Other details) • Graphics may be done as text output, you do not need to worry about building complex designs for the GUI. • Other game design decisions, such as the number of blocks and the method used to determine how the enemies move, is up to you. • The customer is not sure what will make the game fun, and may demand new block types, enemy types, or other changes in the future. © 2009 University of California, Irvine – André van der Hoek

First Assignment: Ogre (Assignment Details) • You should provide additional documentation beyond the raw UML diagrams, where needed. • You should feel free to use any UML or diagramming tool. • You should bring one printed copy of your design to class. • This is merely part 1 of this assignment, it will continue for several more lectures • you will be evaluating and implementing each other’s designs • Due: January 12th, start of class © 2009 University of California, Irvine – André van der Hoek

First Assignment: Grading • Understandability • can someone pick it up and implement it? • Flexibility • can the design support future changes? © 2009 University of California, Irvine – André van der Hoek

Informatics 122 Software Design II