1 / 39

Informatics 122 Software Design II

Informatics 122 Software Design II. Lecture 2 André van der Hoek & Alex Baker Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. Today’s Lecture. Design aesthetics Assignment 1. Aesthetics.

lynton
Download Presentation

Informatics 122 Software Design II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Today’s Lecture • Design aesthetics • Assignment 1 © 2009 University of California, Irvine – André van der Hoek

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

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

  5. Design Aesthetics • Some brainstorming… © 2009 University of California, Irvine – André van der Hoek

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

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

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

  9. Shared Design Aesthetics Individual Project Organization School of Thought Community © 2009 University of California, Irvine – André van der Hoek

  10. But… • …what kind of shared understandings exist? • …where do these shared understandings come from? © 2009 University of California, Irvine – André van der Hoek

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

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

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

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

  15. Approaches to Date • Enumerate objectives • Define principles • Provide strategies © 2009 University of California, Irvine – André van der Hoek

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

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

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

  19. Objectives for Class Design • Cohesion • Completeness • Convenience • Clarity • Consistency © 2009 University of California, Irvine – André van der Hoek

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

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

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

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

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

  25. Program to the Interface • Program to an interface, never directly to an implementation • Always wrap a class in an interface © 2009 University of California, Irvine – André van der Hoek

  26. Refactor • (to be discussed in future lectures) © 2009 University of California, Irvine – André van der Hoek

  27. Apply Software Patterns • (to be discussed in future lectures) © 2009 University of California, Irvine – André van der Hoek

  28. Use Aspects • (discussed in Informatics 102) © 2009 University of California, Irvine – André van der Hoek

  29. Approaches to Date • Enumerate objectives • Define principles • Provide strategies © 2009 University of California, Irvine – André van der Hoek

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

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

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

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

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

  35. First Assignment: Ogre (Examples) P P P P P O P O P O P P S P S P S P © 2009 University of California, Irvine – André van der Hoek

  36. First Assignment: Ogre (Video) • http://www.youtube.com/watch?v=gtDq0EGSDSg © 2007 University of California, Irvine – André van der Hoek

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

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

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

More Related