Fall 2007 CS 225 1

Software Engineering

Intro

Fall 2007 CS 225 2

Topics

• Software challenge• Life-cycle models• Design Issues• Documentation• Abstraction

Fall 2007 CS 225 3

The Software Challenge• In industry, a software product is expected to be used

for an extended period of time by a programming illiterate

• Initial specification for a software product may be incomplete

• Specification is clarified through extensive interaction between users (maybe) of the software and the system analyst

• A requirements specification should be generated at the beginning of any software project

• Designers and users should both approve the document

Fall 2007 CS 225 4

Software Life Cycle Models• Waterfall model: simplest way of organizing activities

that transforms software from one stage to another• Activities are performed in sequence and the results

of one flows into the next• Waterfall model is simple but unworkable

– Fundamental flaw is assumption that each stage can and must be completed before the next one occurs

• Sometimes, it is not until the product is finished that the user can fully express his or her requirements

Fall 2007 CS 225 5

Waterfall Model

Fall 2007 CS 225 6

More realistically

Fall 2007 CS 225 7

Software Life Cycle Activities

• Requirements Specification– System analyst works with software users to

clarify the detailed system requirements– Questions include format of input data, desired

form of any output screens, and data validation

• Analysis– Make sure you completely understand the problem

before starting the design or program a solution– Evaluate different approaches to the design

Fall 2007 CS 225 8

Software Life Cycle Activities

• Design– Top-down approach: breaking a system into a set

of smaller subsystems– Object-oriented approach: identification of a set of

objects and specification of their interactions– UML diagrams are a design tool to illustrate the

interactions between• Classes• Classes and external entities

Fall 2007 CS 225 9

Key Design and Implementation Issues

• Modularity• Modifiability• Ease of use• Fail-safe programming• Efficiency• Generality and Reusability

Fall 2007 CS 225 10

Achieving a Modular Design• Abstraction

– data – focuses on what operations do– procedural – separates the purpose of a method from the implementation– abstract data type (ADT) – a collection of data and a set of operations

• Information hiding – limits the ways that data and methods can be accessed

• Object Oriented Programming– Encapsulation– Inheritance– Polymorphism

• Top-Down design– Focuses on

• the nouns (objects needed by program)• the verbs (actions that are to be performed)

– Identifies the things that need to be done, subdivides tasks, etc.

Fall 2007 CS 225 11

Common Design Flaws - OOP• Classes that make direct modification to other

classes.• Weak within class cohesiveness, strong between

class cohesiveness.• Classes with too much responsibility.• Classes with no responsibility.• Classes with unused responsibility.• Misleading Names.• Unconnected Responsibility.• Innapropriate use of inheritance. Relationship is not

is-a, or class cannot inherit any useful behavior from super class.

• Repeated functionality.

Fall 2007 CS 225 12

Programming Style• Proper use of white space

– Indentation of code blocks– Blank lines

• Well-chosen identifiers– Class names – each word capitalized– Method names – first letter lower case, each word

capitalized– Named constants – all upper case, underscores separate

words– Method variables – all lower case– Object/class variables – append an underscore after the

name

• Documentation– see next page

Fall 2007 CS 225 13

Documentation

• Comments– information about the program directed toward

other programmers

• README file– Information about the program aimed at the user

of the program

Fall 2007 CS 225 14

Comments• A comment is text that is added to program code that is

ignored by the compiler– /* a multi-line comment */– /** Javadoc comment */– // single line comment

• See – http://java.sun.com/j2se/javadoc/writingdoccomments/– http://www.time2help.

com/doc/online_help/idh_java_doc_tag_support.htm

• A comment should describe – What a program segment should do– The circumstances under which it will do it

• You should have an opening comment for each– class– method

Fall 2007 CS 225 15

sample comments• A good comment brings clarity

public class Ratio {

/* an object for storing a fraction like 2/3 */

• A neutral comment is one doesn’t really help or hinderprotected int numerator; // numerator of ratio

• A bad comment is one that is misleadingpublic class Ratio {

/* this class does whatever you want */

Fall 2007 CS 225 16

When do you write comments?

• Comments should be created ASAP• Comments should not be added after the fact!

– However, we all do this

• Note: if you name your identifiers (variables and methods) appropriately, you generally don’t need as many comments

Fall 2007 CS 225 17

Preconditions and Postconditions

• Precondition: a statement of any assumptions or constraints on the method data before the method begins execution

• Postcondition: a statement that describes the result of executing a method

Fall 2007 CS 225 18

javadoc comments

• Surroundes by /** and */ • To document a class, you should have the

following javadoc comments– just above every class header– just above every public/protected method.

• description• @param• @return• @precondition• @postcondition

– just above every class member declaration

Fall 2007 CS 225 19

Using Abstraction to Manage Complexity

• An abstraction is a model of a physical entity or activity

• Abstraction helps programmers deal with complex issues in a piecemeal fashion

• Procedural abstraction: distinguish what is to be achieved by a procedure from its implementation

• Data abstraction: specify the data objects for a problem and the operations to be performed on them without concern for their representation in memory

Fall 2007 CS 225 20

Using Abstraction to Manage Complexity

• If a higher-level class references a data object only through its methods, the higher-level class will not have to be rewritten, even if the data representation changes

• Information hiding: Concealing the details of a class implementation from users of the class