Programming III Introduction

Objectives Programming as a software construction activity and part of the engineering process Continuous focus on the quality factors OO Programming Java as an OOP language

Examination Final exam: 4p Lab Project: 5p Start: 1p Participation bonus: 1p Expected: Participation Reading the specified chapters in the references Working in OO languages (Java) for an average of at least 2h/day Using OOP on other projects during the semester Pro-activity

References Bruce Eckel: Thinking in Java (3rd or 4th edition), 2002, 2006: http://www.mindviewinc.com/Books/downloads.html Bertrand Meyer: Object-Oriented Software Construction, SECOND EDITION, ISE Inc. Santa Barbara (California), 1997 Steve McConnel: Code Complete Ivor Horton: Beginning Java 2, Jdk 5, 7 (http://it-ebooks.info/book/810/) Joshua Bloch: Effective Java, Second Edition, 2008 API: javadocs Java Specification: Tutorial: java.oracle.com

Software Engineering Requirements ANALYSIS Specifications DESIGN Architecture PROGRAMMING Code TESTING Tested Program DEPLOYMENT Delivered Program MAINTENANCE *** New Versions

GCD Sample (1) #include <stdio.h> int a, b; int main() { printf("First number: "); fflush(stdout); scanf("%d", &a); printf("Second number: "); scanf("%d", &b); if (a < 0) a = -a; if (b < 0) b = -b; if (a == 0) { printf("GCD=%d", b); return 0; } if (b == 0) { printf("GCD=%d", a); while (1) { if (a > b) { a = a - b; } else if (b > a) { b = b - a; } else { break;

GCD (2) /** * Computes the GCD of the provided values /** * first - the first integer * second - the second integer */ int gcd(int first, int second) { if (first < 0) { first = -first; } if (second < 0) { second = -second; if (first == 0) { return second; if (second == 0) { return first; while (1) { if (first > second) { first = first - second; } else if (second > first) { second = second - first; } else { return 0; /** * Read an int value from the keyboard. Display the provided text first. * textToDisplay - the text to display before reading the value */ int read_number(char* textToDisplay) { int number; printf("%s", textToDisplay); fflush(stdout); scanf("%d", &number); return number; } * Read two integer values from the keyboard and printout their GCD int main() { int first, second; first = read_number("First number: "); second = read_number("Second number: "); printf("GCD=%d", gcd(first, second)); return 0;

Discussion Both variants works the same way First variant: Mixes responsibilities (gcd and printing) GCD logic not reusable No modularity Not readable (no comments) Do not properly consider the scope of variables Second variant: Does better in any mentioned problems above Still: Do not allows for selling GCD separate from its current context (as a library) Do not favor multiple developers on the same program (multiple source files) Do not test on wrong input (lack of robustness) Do not favor a different implementation of GCD (e.g. a recursive one)

Software Quality Factors (Meyer) reliable, usable, readable, maintainable, modular, structured, performant, scalable, robust, extendable, safe, secure, etc, etc External factors: how the users perceive the system Internal factors: how the developers look at the system External ones are the most important in the end but HIGHLY influenced by the Internal ones.

External Factors (1) Correctness: the ability of software products to perform their exact tasks, as defined by their specification Robustness: is the ability of software systems to react appropriately to abnormal conditions Reliability = Correctness + Robustness

External Factors (2) Extendibility: is the ease of adapting software products to changes in specifications extendibility principles: design simplicity (coherent design) and decentralization Continuity: a design method satisfies this criterion if it yields stable architectures, keeping the amount of design change commensurate with the size of the specification change Reusability: the ability of software elements to serve for the construction of many different applications Modularity = Extendibility + Reusability

External Factors (3) Compatibility: the ease of combining software elements with others Efficiency: is the ability of a software system to place as few demands as possible on hardware resources, such as processor time, space occupied in internal and external memories, bandwidth used in communication devices (similar to performace) Portability: the ease of transferring software products to various hardware and software environments Usability: the ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems. It also covers the ease of installation, operation and monitoring Functionality: the extent of possibilities provided by a system Timeliness: the ability of a software system to be released when or before its users want it

External Factors (4) Verifiability: is the ease of preparing acceptance procedures, especially test data, and procedures for detecting failures and tracing them to errors during the validation and operation phases Integrity: the ability of software systems to protect their various components (programs, data) against unauthorized access and modification (security) Repairability: is the ability to facilitate the repair of defects Documentation: the extent the system is documented from both external and internal points of view

Internal factors Modularity Structure Readability Documentation

Actions and Objects Actions and Objects as programming ingredients What is the appropriate criteria for building modules? Focusing on actions (functional and procedural) vs. focusing on objects (OO)

Top Down

Top-Down Advantages Disadvantages: Logical and well organized: decomposition favors the understanding of the design Follow well understood mathematical conceptualization Encourages an orderly development of the systems by decreasing the level of abstraction as going down in the hierarchy Disadvantages: Characterizing a system by just one function is subject to doubt; instead consider several business processes or services Does not account for the evolutionary nature of the systems Enforce (too) early commitment on decomposition Does not explicit some real world processes outside decomposition like delegation or specialization: a design method should stay as close as possible to the real world concepts Does not favor reusability as the decomposition is mostly related to the actual problem to solve

Object Orientation Main objectives (Meyer): Extendibility: meeting the goal of continuity Reusability: a functional unit is not a good reusable unit; it often only makes sense with the appropriate data to act on Compatibility: combining pieces (data and actions) DEF: Object-oriented software construction is the software development method which bases the architecture of any software system on modules deduced from the types of objects it manipulates (rather than the function or functions that the system is intended to ensure). OBS: functions still need to be part of the method

Bottom-Up Postpone the decision on what the main function would be Build around minimal implementation commitments Successively improve the design by combining reusable pieces New challenges: Finding the object types Describing object types at the right level of abstraction Describing relations between object types How to use the object types to structure the software

Programming Languages Procedural Functional OO Declarative Favoring a method and allowing for a method Also see Object Oriented Programming with ANSI C, Axel Schreiner http://www.cs.rit.edu/~ats/books/ooc.pdf

Course references Meyer: chapter 1, 5