Fall 2007CS 2251 Software Engineering Intro

Fall 2007CS 2252 Topics Software challenge Life-cycle models Design Issues Documentation Abstraction

Fall 2007CS 2253 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 2007CS 2254 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 2007CS 2255 Waterfall Model

Fall 2007CS 2256 More realistically

Fall 2007CS 2257 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 2007CS 2258 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 2007CS 2259 Key Design and Implementation Issues Modularity Modifiability Ease of use Fail-safe programming Efficiency Generality and Reusability

Fall 2007CS 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 2007CS 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 2007CS 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 2007CS Documentation Comments –information about the program directed toward other programmers README file –Information about the program aimed at the user of the program

Fall 2007CS 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 – – _support.htmhttp:// _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 2007CS 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 hinder protected int numerator; // numerator of ratio A bad comment is one that is misleading public class Ratio { /* this class does whatever you want */

Fall 2007CS 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 2007CS 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 2007CS 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 –just above every class member declaration

Fall 2007CS 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 2007CS 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