© 2009 University of California, Irvine – André van der Hoek1June 10, 2015 – 18:31:15 Informatics 122 Software Design II Lecture 2 André van der Hoek &

© 2009 University of California, Irvine – André van der Hoek 1April 18, 2023 – 20:34:56

Informatics 122Software Design II

Informatics 122Software 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.

© 2009 University of California, Irvine – André van der Hoek 2April 18, 2023 – 20:34:56

Today’s LectureToday’s Lecture

Design aesthetics

Assignment 1

© 2009 University of California, Irvine – André van der Hoek 3April 18, 2023 – 20:34:56

AestheticsAesthetics

“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 4April 18, 2023 – 20:34:56

Design AestheticsDesign 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 5April 18, 2023 – 20:34:56

Design AestheticsDesign Aesthetics

Some brainstorming…

© 2009 University of California, Irvine – André van der Hoek 6April 18, 2023 – 20:34:56

Design AestheticsDesign 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 7April 18, 2023 – 20:34:57

Design AestheticsDesign Aesthetics

Subjective, as it should be

representations (langs)

goals (langs)

activities

goals (langs) knowledge (langs)

ideas (langs)

tools

activities

knowledge (langs)

ideas (langs)

tools

© 2009 University of California, Irvine – André van der Hoek 8April 18, 2023 – 20:34:57

Design AestheticsDesign 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 9April 18, 2023 – 20:34:57

Shared Design AestheticsShared Design Aesthetics

Individual

Project

Organization

Community

School of Thought

© 2009 University of California, Irvine – André van der Hoek 10April 18, 2023 – 20:34:57

But…But…

…what kind of shared understandings exist?

…where do these shared understandings come from?

© 2009 University of California, Irvine – André van der Hoek 11April 18, 2023 – 20:34:57

Purpose of Implementation DesignPurpose 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 12April 18, 2023 – 20:34:57

Purpose of Implementation DesignPurpose 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 13April 18, 2023 – 20:34:57

More of a Shared Understanding (Not Perfect!)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 14April 18, 2023 – 20:34:57

Less of a Shared UnderstandingLess 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 15April 18, 2023 – 20:34:57

Approaches to DateApproaches to Date

Enumerate objectives

Define principles

Provide strategies

© 2009 University of California, Irvine – André van der Hoek 16April 18, 2023 – 20:34:57

Approaches to DateApproaches to Date

Enumerate objectives– overall process– overall design– individual classes

Define principles

Provide strategies

© 2009 University of California, Irvine – André van der Hoek 17April 18, 2023 – 20:34:57

Objectives for Overall ProcessObjectives for Overall Process

Apply rigor Separate concerns

– modularize– abstract

Anticipate change Generalize Work incrementally

© 2009 University of California, Irvine – André van der Hoek 18April 18, 2023 – 20:34:57

Objectives for Overall DesignObjectives 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 19April 18, 2023 – 20:34:57

Objectives for Class DesignObjectives for Class Design

Cohesion Completeness Convenience Clarity Consistency

© 2009 University of California, Irvine – André van der Hoek 20April 18, 2023 – 20:34:57

Approaches to DateApproaches 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 21April 18, 2023 – 20:34:57

Keep It Simple, Stupid! (KISS)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 22April 18, 2023 – 20:34:57

Information HidingInformation 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 23April 18, 2023 – 20:34:57

Acyclic DependenciesAcyclic 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 24April 18, 2023 – 20:34:57

Approaches to DateApproaches 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 25April 18, 2023 – 20:34:57

Program to the InterfaceProgram 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 26April 18, 2023 – 20:34:57

RefactorRefactor

(to be discussed in future lectures)

© 2009 University of California, Irvine – André van der Hoek 27April 18, 2023 – 20:34:57

Apply Software PatternsApply Software Patterns

(to be discussed in future lectures)

© 2009 University of California, Irvine – André van der Hoek 28April 18, 2023 – 20:34:57

Use AspectsUse Aspects

(discussed in Informatics 102)

© 2009 University of California, Irvine – André van der Hoek 29April 18, 2023 – 20:34:57

Approaches to DateApproaches to Date

Enumerate objectives

Define principles

Provide strategies

© 2009 University of California, Irvine – André van der Hoek 30April 18, 2023 – 20:34:57

Purpose of Implementation DesignPurpose 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 31April 18, 2023 – 20:34:57

Purpose of Implementation DesignPurpose 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 32April 18, 2023 – 20:34:57

Why Aesthetics?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 33April 18, 2023 – 20:34:57

First Assignment: Ogre (Overview)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

First Assignment: Ogre (Rules)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 34April 18, 2023 – 20:34:57

First Assignment: Ogre (Examples)First Assignment: Ogre (Examples)

P P

P O P

P O P

O

P S P S

P S P

P P

© 2009 University of California, Irvine – André van der Hoek 35April 18, 2023 – 20:34:57

First Assignment: Ogre (Video)First Assignment: Ogre (Video)

http://www.youtube.com/watch?v=gtDq0EGSDSg

© 2007 University of California, Irvine – André van der Hoek 36April 18, 2023 – 20:34:57

First Assignment: Ogre (Other details)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 37April 18, 2023 – 20:34:57

© 2009 University of California, Irvine – André van der Hoek 38April 18, 2023 – 20:34:57

First Assignment: Ogre (Assignment Details)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 39April 18, 2023 – 20:34:57

First Assignment: GradingFirst Assignment: Grading

Understandability– can someone pick it up and implement it?

Flexibility– can the design support future changes?