18
Design and Planning Or: What’s the next thing we should do for our project?

Design and Planning Or: What’s the next thing we should do for our project?

Embed Size (px)

Citation preview

Page 1: Design and Planning Or: What’s the next thing we should do for our project?

Design and Planning

Or:

What’s the next thing we should do for our project?

Page 2: Design and Planning Or: What’s the next thing we should do for our project?

Think about Program Architecture

The organization of code components

The objective of system architecture is to simplify maintenance by

putting code together that will be changed at the same time

Page 3: Design and Planning Or: What’s the next thing we should do for our project?

Architectural Philosophies

Requirements Driven Data Driven Dialog Driven Event Driven

Page 4: Design and Planning Or: What’s the next thing we should do for our project?

Coding Standards

StructuredLimit control structures to sequence,

iteration, and selection Event Driven

Interactive systems driven by user actions

Object orientedEncapsulate data and code into objects

that can be called independently

Page 5: Design and Planning Or: What’s the next thing we should do for our project?

Good Code Maintenance is 80% of the cost of a

large system. Instructions that will be changed

together located together. Finding errors and bugs is

theoretically simplified (fewer possible places to look).

Page 6: Design and Planning Or: What’s the next thing we should do for our project?

Traditional Design

Traditional Life Cycle ApproachFormal MethodologiesCASE ToolsPurchased Systems

Newer ApproachesRADEvolutionary CodeGUI designObject Oriented Design

Page 7: Design and Planning Or: What’s the next thing we should do for our project?

Modular Program Design

Goal: software components that can be plugged into any project (like circuits)

Coupling the degree to which each program module

relies on other modules• Loose: modules are independent (roughly)• Tight: one module depends on another

… changes cause ripple effect …

Page 8: Design and Planning Or: What’s the next thing we should do for our project?

Modular Program Design

Goal: software components that can be plugged into any project (like circuits)

Cohesion Relatedness of actions of a module or class

• Low: module does lots of unrelated things• Hard to maintain, hard to understand

• High: module focused on one task• Aids maintainability and reusability

Page 9: Design and Planning Or: What’s the next thing we should do for our project?

Good Practice: Loose Coupling

Associations among code modules

Data passed by parametersavoid public variables

Method use of Interfaces as opposed calls to actual method names

Page 10: Design and Planning Or: What’s the next thing we should do for our project?

Good Practice: Loose Coupling

Measuring level of coupling

How many changes would be needed to do the following:

Changing the order of data elements Changing the names of data elements Changing the structures of data elements

Page 11: Design and Planning Or: What’s the next thing we should do for our project?

Good Practice: High Cohesion

Functions done by one code module.

A module is a set of code statements that is called and executed together. A cohesive module executes only statements that always go together.

Page 12: Design and Planning Or: What’s the next thing we should do for our project?

Typical Modules

methods and functions Forms, Reports and Queries Classes

Page 13: Design and Planning Or: What’s the next thing we should do for our project?

Programming Principles

KISS (Keep it Simple, Stupid)Volatility

Prototyped code will be revised frequently. Simple solutions are much better than elegant ones that are hard to understand.

Clarity over Efficiencymodern optimizing compilers remove many inefficiencies

Page 14: Design and Planning Or: What’s the next thing we should do for our project?

Programming Principles

Code should be written to be readGood communication principles

White spaceBoxesIndentationExplain complex logic

Modular constructionVery simple control structures

Mnemonic variables

Page 15: Design and Planning Or: What’s the next thing we should do for our project?

Programming Principles

Minimize external documentationDocument the objective rather than the

procedure. The next programmer can find his own solution too.

Include descriptive and complete title lines

Include an initial statement of program purpose

Line comments hard to maintain

Page 16: Design and Planning Or: What’s the next thing we should do for our project?

Programming Principles

Fully document data filesUse labels and file descriptionsUse original common data sources where

possibleCreate as few original data tables as

possibleDocument edits and modifications

Page 17: Design and Planning Or: What’s the next thing we should do for our project?

Programming Principles

Retain natural documentationKeep instructional memos and notes in

fileDocument objectives so that modules

can be reprogrammed as needed

Page 18: Design and Planning Or: What’s the next thing we should do for our project?

Next Time: Planning/Scheduling Setting a schedule of milestone

dates

How much time for each step and sub-step?

•How to estimate that