CSE 219 Computer Science III Program Design Principles

Why are we here? To learn a methodology for constructing software systems of high quality What properties make a software system high quality? –correctness –efficiency –ease of use (by other programmers in the case of frameworks) –reliability/robustness –maintainability –modifiability –extensibility ( also modifiable at run-time without recompiling ) –scalability –portability As programs get larger, these become much more difficult to achieve. Why? –program complexity –team complexity (more people are involved)

How can these properties be achieved? By using well proven, established processes –preferably while taking advantage of good tools Bottom Line: –don’t be a flying by the seat of your pants software engineer Requirements Analysis Design & Document CodeTest Debug Profile Deploy Evaluate Design

Software Jobs Not all of you are going to be programmers –but you should know how to design, program, test, debug software Other types of jobs: –Designer –Tester –Database, Network, Security Administrator –Project Leader –Manager –Researcher or Professor –etc … NOTE: designers & programmers on a project may not be the same people

Design, then develop Starting with HW 2, you should design all classes before development (coding) –not easy to do –UML is used for software design You cannot design a system unless you really understand the necessary technology –designs cannot be created without a little testing trying out different small-scale examples (HW 1)

Where to begin? Understand the problem –the point of a requirements analysis –What are system input & output? –How will users interact with the system? –What data must the system maintain? Generate a problem specification document –defines the problem –defines what needs to be done to solve the problem –for us, most of this has been done by HW descriptions (1-4)

Design Approaches Have other “similar” problems been solved? –Do design patterns exist to help? What are the “easy” and “hard” parts? –Why is this important? work measurement Employ: –data-driven design –top-down design

Data-driven Design From the problem specification, extract –nouns (objects, attributes of objects) –verbs (methods) Divide data into separate logical, manageable groupings –these groupings will form your objects Among these, note those that may need sophisticated data structures or algorithms –design your data management classes early on such that you abstract out complexity Ex: a deck of cards

Top-down class design Top-down class design strategy: –Decompose the main problem into sub-problems (large chunks). –Write skeletal classes for sub-problems. –Write skeletal methods for sub-problems. –Repeat for each sub-problem. If necessary, go back and redesign higher-level classes to improve: –modularity –information hiding –information flow –etc.

Designing Methods Decide method signatures –numbers and types of parameters and return values Write down what a method should do –use top-down design to decompose methods into helper methods Use javadoc comments to describe methods Continually review method specs during implementation

Results of Top-down class design UML Class Diagrams Skeletal Classes instance variables static variables class diagrams method headers with fully documented method descriptions

HWs HW1: Initial program for game of Life with a GUI and limited functionality. HW2: Design of fully functioning game of Life with a GUI and the use of a design pattern. HW3: Implementation of fully-functioning game of Life with a GUI and the use of a design pattern. HW4: Implementation of AI logic for computer based players and make a plugin. You will also use CVS during development.

Our project this semester Crucial design decisions: –Class relationships –Modularity –Functionality vs. Presentation –Choosing data structures

Class relationships Think data flow: –What HAS what? –What IS what? –What USES what? –Where should a particular piece of data be placed? –How will event handler X change data in class Y? –Static or non-static? Design patterns will help us make these decisions Bottom line: think modular –no 1000 line classes or 100 line methods NOTE: these numbers are somewhat arbitrary

Modularity How reusable are your classes? –can they be used for implementing the full version, or apply the old rules, etc.? Think of programmers, not just users Can individual classes be easily separated and re-used Data vs. Mechanics

Functionality vs. Presentation What’s the infrastructure? –general classes that do the work of running the game –a general engine Why separate the engine and the UI –So we can change the engine without changing the UI –So we can change the UI without changing the engine –So we can design several different UIs for an engine –Reuse code that is proven to work This is a common principle throughout GUI design –Even for Web sites –Different programmers for each task

Choosing Data Structures Internal data structures –What is the natural representation of the given data? game board data should be stored in its natural state (2D) –Setup vs. access speeds –Keep data ordered? Which access algorithms? E.g., player information –Ordered by what?

Evaluating the Design Periodic reviews are necessary –redesign is less costly during the design stage than during implementation Is the design correct? –according to the problem description Will it work efficiently? Are the classes independent? –Encapsulation – Do they manage & protect their own data? –Can they be tested individually? –Do they produce code reuse? Is there redundancy? Is it necessary? –Reduce redundancy wherever possible. Makes maintenance much easier Is data and control flow clear or complex?

Software Longevity The FORTRAN & COBOL programming languages are almost 50 years old Many mainframe systems still use code written in the 1960s Remember: software maintenance is more than ½ a project Moral of the story: the code you write may outlive you, so make it: –Easy to understand –Easy to modify & maintain Software must be ready to accommodate change

Software Maintenance What is software maintenance? Improving or extending existing software –incorporate new functionality –incorporate new data to be managed –incorporate new technologies –incorporate new algorithms –incorporate use with new tools –incorporate things we cannot think of now

Summary Always use data driven & top-down design: –identify and group system data –identify classes, their methods and method signatures, in that order –flesh out method bodies (what they should do), to identify helper methods Write down step by step algorithms inside methods to help you!!! –document each class, method and field –make explicit all conditions that need to be enforced or checked decide where to generate exceptions add to documentation –evaluate design, and repeat above process several times until all decisions are verified and implementation instructions are well-defined