Chapter 1 Getting Organized

							Welcome to

Data Structures
class!
CSCI-260-W02

•Class Name: Data Structures •Class Number: CSCI-260-W02 •Semester: Fall 2007 •Class Meeting Thursdays 9/6-12/20, 5:45-8:25pm, Rm HSH101 Time & Place: NOTE: No classes on 9/13, make up ??? •Break Time: By agreement •Instructor: Lyublyana (Luba) Turiy (516) 704-3744 – business hours or leave message ltur@optonline.net – best!, put ‘CSCI 260’ in ‘Subject’ line •Office Hours: Before or after the class, or by appointment •Textbook: Nell Dell, Daniel T. Joice, Chip Weems, Object-Oriented Data Structures Using Java, 2nd Ed, Jones and Bartlett Publishers,Inc., 2003 ISBN: 0-7637-3746-1 •Add’l materials: Class notes from Instructor •Class Website: http://online.nyit.edu

Introduction

Requirements: Prerequisites, Attendance, W/D Policies
•Prerequisites: Math170 (Calculus I ), CSCI-180 (Programming II) •Attendance: Notify in advance if have to be absent. Still need to send assignments by due time. •Withdrawal ≤ 8th week of the semester = Grade W (W grade): After the 8th week, passing the course = Grade W, not passing the course = Grade WF. •Incomplete IF can’t finish due to unavoidable circumstances (I grade): AND student work is passing @ this point AND after consultation with Department Chair. I → F if not completed by next semester+summer. •Academic No Cheating Allowed! Integrity: 1st offence = Grade F on exam/assignment, 2nd offence = Grade F for class.

Requirements: Homework & Exams

•Homework: 10 Java programming exercises from textbook (group) Term summary report (individual) Due on the following class date except the exam days. Email to instructor by 5:45 pm on due date. Alternatively, bring in class on a floppy disk or CD. See syllabus for details. •Lateness: Programming assignments will incur 10% penalty for each day overdue up to one (1) week, after which the penalty will stay fixed at 70%. Term summary report is due by last day of the class, and will not be accepted any time after. •Reading: Material covered during the class after the end of each class. •Exams: Midterm: 10/25/07 (tentative). Final exam: 12/20/07. All class material. Format: multiple choice, short answers, small problems.

Grading
Requirement Percentage Comment

Homework:
Programming Exercises Term Summary Report

40%
30% 10%

Total
Divided equally, i.e. 3% each

Exams:
Midterm Final

60%
20% 40%

Total
Up to covered material All material

Total

100%

NOTES: Extra points will be given for:

– Class participation (Answer questions, review homeworks, volunteer ideas) – In class presentation on any course material is encouraged and will receive extra 10% if desire to improve the grade.

Class Overview
• Catalog Description:
Classic data structures: stacks, queues, lists, binary trees. Sorting, searching and computational analysis is studied. - Building blocks of every serious software written - Emphasis on Java
• Widely used language in today’s job environment • Built-in object-oriented programming structures

• Instructor’s Objectives:

– Foundations of algorithm analysis After successful completion of this course, the students will have the ability to: 1. Comfortably use studied structures in writing programs 2. Analyze and choose most efficient algorithms among several alternatives (incl. searching and sorting)
1. Start from scratch and move on gradually 2. No rush: progress with the class – Covered material and homework will be adjusted as we go 3. Learn by practice: a lot of exercises to master the concepts – Theory is nothing without application 4. Class is NOT easy… extra help is available! – Ask questions in class, before, after by email, …. 5. Your input is welcome! – Speak-up, send suggestions and comments by email, or on discussion board 6. Let’s try to make it fun!

• Instructor’s Method:

Sample Class Agenda
• Homework discussion
– All homeworks are due before the start of review!
• Emails must be postmarked by 5:45 on due date • Hand-ins must be on instructor’s desk before the start of the class
– If came late – put it on the desk before you go to your seat – There are penalties for late submissions!

• Short quiz on past material • New material • Homework assignment • Questions • Breaks
– Not graded, for review only

– Stay to the end of the class if you’d like to hear details – Will also be available on website in syllabus and class notes – Instructor will pause after each segment – Alternatively, can be asked any time during the class – Optionally one break approximately ~ 7:15pm – Can be substituted for earlier dismissal

Chapter 1 Getting Organized

Chapter 1: Getting Organized
1.1 – Software Engineering 1.2 – Object Orientation 1.3 – Classes, Objects, and Applications 1.4 – Organizing Classes 1.5 – Data Structures 1.6 – Basic Structuring Mechanisms 1.7 – Comparing Algorithms: Big-O Analysis

1.1 Software Engineering
• Was born in 1960s • The field concerned with all aspects of development of s/w systems, i.e.:
– – – – specification design production maintenance

in order to:
– produce high-quality products

– meet production time and cost estimates – handle the size and complexity of the resulting s/w products – manage non-trivial s/w products

• Encompasses all variations of techniques used during s/w development, including supporting activities such as
– – – – cost estimation documentation team organization use of tools

Software Life Cycle Activities
• Problem analysis
• Understand the nature of the problem to solve

• Implementation
• Coding in a computer language

• Requirements
– Elicitation
• From customer

• Testing and Verification
• Detecting & fixing errors (bugs) • Demonstrating correctness of the program • Checking if stated requirements are satisfied

– Specification
• Functional (what to do) • Nonfunctional (choice of language, etc.)

• Delivery
• Turning over tested product to the customer (user)

• Design
– High-level
• “Big picture”

• Operation
• Actual use

– Low-level
• Detailed description

• Maintenance
– Fixes in response to:
• Changing environment • Operational errors

– Additional or improved functionality

Waterfall Life-Cycle Model
• Classical model where each stage’s documented output is fed into the next stage • Pro
• Useful when the requirements are well-understood and unlikely to change
• Rare case in modern s/w development

• Con
• Inflexible partitioning into stages • Heavy emphasis on documentation

Spiral LifeCycle Model • Pro

• Activities repeat in a spiral manner from original concept to its final form • Useful for projects that don’t conform to waterfall cycle • Directly addresses major risks, i.e.:
• Creating unneeded product • Including unnecessary functions, etc…

• Con

• Emphasizes continuous re-assessment and goals adjustment
• Too rigorous for short life span s/w

Manifesto for Agile S/W Development
• Created on February 2001 (meeting of 17 agile method proponents) We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
– – – – Individuals and interactions Working software Customer collaboration Responding to change over processes and tools over comprehensive documentation over contract negotiation over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile (Lightweight) Methods
• More informal relaxed approach serving as “an alternative to document-driven, heavy-weight s/w development methods” • Specific methods:
– Heavy customer involvement in all stages of the project – Incremental delivery of the product – An openness to change in the specifications of the system
• Customer satisfaction is more important than conforming to the plans

– Developers work in pairs in a supportive, collaborative manner
• 2 programmers work side-by-side at a single workstation is discovered by studies to have less code defects than individual works

• Pro
– Useful for software project with:
• Short life span • Quick development for pressing need • Intended for rapidly changing environment

– Stress on customer satisfaction – Increase morale of the development team

• Con
– Lack of structure and limited testing can cause
• multiple operational errors (hence, customer dissatisfaction) • unplanned time and cost overruns • problems with maintenance (if needed)

Other Methods
• • • • Prototyping Real-time system development Creative program solving …

• Each organization has its own model that may combine ideas from different approaches that best fits with its goals.

How Is Programming Done?
Simplified Software Development Process Users star
t Gathering Requirements Design Requirement specification

• Requirement Gathering
– Communicate with non-technical customers (end users) – Convey gathered information in writing to technical audience

• Architecture & Design
Design specification

Programmers

Coding Testing yes “bugs ” found no ? done; deliver to customer Test report source code; user documentation

– Create an abstract representation of the system to be build – Make sure the software will meet the existing requirements and can address future upgrades

• Coding
– Transfer a design to code

• Bug

Users
Required by standards: ISO 9000, CMM, ...

• A mistake in a program • Debugging & Testing – A process of eliminating mistakes (bugs) • Syntax (compile) error • A grammar error • Implementation, user training, detected by compiler maintenance • Run-time error – cope with newly discovered problems • Execution stops abnormally (program aborts) or new requirements • Logic error • No troubles during compile or run, but results are incorrect

Some Goals of Quality Software
(no matter what approach you use)

• It works.
• It can be modified without excessive time and effort.

• It is reusable.
• It is completed on time and within budget.

Goal 1: Quality Software Works
• Determine software requirements
– What is to be provided by a computer system or s/w product, not how it is done

• Develop programs that meet requirements by fulfilling software specifications
– Detailed description of:
• • • • • • functions inputs processing outputs interfaces (including user interface (UI)) performance (response time, appearance), etc…

– Provides specific info needed to design and implement the product

• The program works if it is:
– – – – complete – should do everything that’s needed correct – should “do it right” usable – provide user interface “easy to work with” efficient – at least “as circumstances require”

S/W Requirement Specification
• Main parts:
1. Introduction
1.1 TOC, list of figures and tables, vocabulary and abbreviations defined 1.2 Statement of Scope
–
–

Describes generically what this program is trying to do
Where does this program fit into the “big picture”

1.3 Software Context

2. Usage scenarios
2.1 User profiles
– Who are the users (actors)

… F3. Display a text fragment
F3.1 Make text font Bold F3.2 Make it to fit into a textbox F3.2.1 Make it size 10

2.2 Use cases

3. Requirements
• divided into groups:
3.1 Functional (F) 3.2 Data (D) 3.3 Human User Interface (U) 3.4 Hardware Interface (H) 3.5 Performance (P) 3.6 Testing (T)

F4. Print a textbox (see U5.2 – cross-link) …

• • •

Hierarchically structured from more abstract to more precise Most important! Is used to validate written software against requirements

4. Traceability matrix

•
•

Prepared with:
– – Specialized software (big-scale projects) Word, Excel, Access, etc. (small-scale)

IMPORANT!!! This is a part of each homework (simplified) !

Traceability Matrix Structure
Req. Num ber Description Source (Who requested it?) Author Date last (Who wrote edited it?) Status Date Code: implemented (In review; Approved; In design; In coding; In testing; Completed; Deferred; Rejected) Product Cross- Notes subsys- links to tem other requirements

…

F1

Output text.

F1.1 Output on the screen

Prof Turiy Prof Turiy Prof Turiy

Prof Turiy Prof Turiy

09/18/ Design 06 09/18/ Design 06

F1.2 Text should read: “Hello World!”

Prof 09/18/ Design Turiy 06

Goal 2: Quality Software Can Be Modified
• Must be readable and understandable to humans
– Problem must be understood before it can be solved

• Must be well designed
– Easy to determine where to apply changes

• Must be able to withstand changes easily
– Partition programs into manageable pieces that work together to solve the problem, yet are relatively independent

Goal 3: Quality Software Is Reusable
• Purpose:
– Get as much value from the product as possible
• Quality s/w takes significant time and effort to be created

– Reuse from previous projects to save time and effort:
• Programs • Classes • Methods

• Must be well-documented and easy to read
– Time and effort spent on learning reusable s/w must not exceed the time and effort to develop new similar s/w

• Shall have simple interface
– To be easily plugged into a new system

• Shall be modifiable
– To alleviate changes necessary to adapt to the new system

• Attempt to make s/w more generally useable
– whenever it requires minimal extra effort

Goal 4: Quality Software Is Completed On Time and Within Budget
• A program that meets is functional requirements is not useful if it is not ready when needed • Possible consequences of being late:
– User dissatisfaction (may take business elsewhere) – Monetary penalties for missed deadlines – Be beaten by competitors and lose market share – Be forced out of business

1.2 Object Orientation
• • Started with Simula 67
– by Kristen Nygaard and Ole-Johan Dahl, 1967

Objects are:
– Prime modularization mechanism in OOP – Contain
• • information: we say the objects have attributes behavior: we say the objects have responsibilities (actions)

– Remember their internal state

•

Benefits of Object Orientation:
1. Can represent “real-world” entities, i.e. bank accounts 2. Objects are self-contained and are easy to:
• • • implement modify test for correctness

3. Object-oriented classes, when designed properly, are very easy to reuse

The Unified Method
• An organized approach (methodology) is needed to implement models of reality
– A collection of specific procedures for creating a system that meets users’ needs

• In 1994-1997 several ideas were consolidated to create Unified Method methodology • 3 key elements:
1. Use-case driven
– – – Describe a sequence of actions performed by a user within the system to accomplish some task Structured target system consisting of interacting components (not monolithic) Similar to spiral life-cycle model

2. Architecture-centric 3. Iterative and incremental

• Improved communication among the people working on the same project with the Unified Modeling Language (UML)
– – – A set of diagrams to specify, visualize, construct and document s/w de facto industry standard for modeling s/w http://www.uml.org/

Intro to UML: Use Case Diagrams
• Use-case view
• Functionality of the system as perceived by external actors while they interact with the system
• • Actor - user or other system Use case – a generic description of a system usage (a function requested)

System

• Example: insurance business

1.3 Classes, Objects, and Applications
• An object is an instantiation of a class • A class defines the structure of its objects. • A class definition includes:
– variables (data) – methods (actions determining the behavior of an object).

• Example: the Date class (next slide)

Date.java
public class Date { protected int year; protected int month; protected int day; public static final int MINYEAR = 1583; // Constructor public Date(int newMonth, int newDay, int newYear) { month = newMonth; day = newDay; year = newYear; } // Observers public int getYear() { return year; } } public int getMonth() { return month; } public int getDay() { return day; } public int lilian() { // Returns the Lilian Day Number // of this date. // Algorithm goes here. } public String toString() // Returns this date as a String. { return(month + "/" + day + "/" + year); }

Specific Class Methods
• Constructor
– An operation creating a new instance (object) of a class

• Observer (or accessor or getter)
– An operation allowing to observe the state of an object without changing it

• Transformer (or mutator or setter)
– An operation that changes the internal state of an object

Java Access Control Modifiers
Within Within the Subclass Class in the Same Package public protected X X X X Within nonsubclass in the Same Package X Within Subclass in Other Package Every where

X X

X

package
private

X
X

X

X

Class Diagram for Date Class

Objects

Date myDate = new Date(6, 24, 1951); Date yourDate = new Date(10, 11, 1953); Date ourDate = new Date(6, 15, 1985);

Applications
• An object-oriented application is a set of objects working together, by sending each other messages, to solve a problem. • In object-oriented programming a key step is identifying classes that can be used to help solve a problem. • An example – using our Date class to solve the problem of calculating the number of days between two dates (next 3 slides)

DaysBetween Design
display instructions prompt for and read in info about the first date create the date1 object prompt for and read in info about the second date create the date2 object IF dates entered are too early THEN print an error message ELSE use the date.lilian method to obtain the Lilian Day Numbers compute and print the number of days between the dates

//---------------------------------------------------------------------// DaysBetween.java by Dale/Joyce/Weems Chapter 1 // // Asks the user to enter two "modern" dates and then reports // the number of days between the two dates. //---------------------------------------------------------------------import java.util.Scanner; public class DaysBetween { public static void main(String[] args) { Scanner conIn = new Scanner(System.in); int day, month, year; System.out.println("Enter two 'modern' dates: month day year"); System.out.println("For example January 12, 1954 would be: 1 12 1954"); System.out.println(); System.out.println("Modern dates occur after " + Date.MINYEAR + "."); System.out.println(); System.out.println("Enter the first date:"); month = conIn.nextInt(); day = conIn.nextInt(); year = conIn.nextInt(); Date date1 = new Date(month, day, year);

System.out.println("Enter the second date:"); month = conIn.nextInt(); day = conIn.nextInt(); year = conIn.nextInt(); Date date2 = new Date(month, day, year); if ((date1.getYear() <= Date.MINYEAR) || (date2.getYear() <= Date.MINYEAR)) System.out.println("You entered a 'pre-modern' date."); else { System.out.println("The number of days between"); System.out.print(date1); System.out.print(" and "); System.out.print(date2); System.out.print(" is "); System.out.println(Math.abs(date1.lilian() - date2.lilian())); } } }

Homework
• Exercise 15b and 16
– Follow Syllabus guidelines for complete documentation and submission

• Extra credit:
– Exercise 4
• Prepare a short statement to discuss in class