1 / 31

Introducing Computer Science

Introducing Computer Science. CSCI N341: Client-Side Programming. Goals. By the end of this lecture you should … … understand Computer Science as the study of algorithms … recognize HIPO charts as one of several tools available for problem analysis

khanh
Download Presentation

Introducing Computer Science

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introducing Computer Science CSCI N341: Client-Side Programming

  2. Goals By the end of this lecture you should … … understand Computer Science as the study of algorithms … recognize HIPO charts as one of several tools available for problem analysis … understand how programming languages work in general … recognize different categories of programming languages … understand the program development cycle

  3. One Dimension of Web Programming Personal Computer - a computer operated by one person at a time, i.e. “Client” computer. N341 focuses on Client-Side computing Server – a computer whose resources and processors are shared by multiple users. N342 focuses on Server-Side programming

  4. What is Computer Science? • NOT about coding or hardware or software! • Computer Science is about PROBLEM SOLVING • Computer Science is about DEVELOPING ALGORITHMS to solve complex problems • Computers are merely tools for solving problems!

  5. Algorithms • Well-developed, organized approaches to solving complex problems • Test of a good algorithm: • Does the algorithm solve the stated problem? • Is the algorithm well-defined? • Does the algorithm produce an output? • Does the algorithm end in a reasonable length of time?

  6. Developing an Algorithm • Identify the Inputs • What data do I need? • How will I get the data? • In what format will the data be? • Identify the Processes: • How can I manipulate data to produce meaningful results? • Identify Outputs: • What outputs do I need to return to the user? • What format should the outputs take?

  7. Develop a HIPO chart – Hierarchy, Input, Processing, Output Developing an Algorithm

  8. Developing an Algorithm • Identify relevant modules • How can I break larger problems into smaller, more manageable pieces? • What inputs do the modules need? • What processes need to happen in the modules? • What outputs are produced by the modules?

  9. Programs • Sets of instructions that get the computer to do something • Instructions are translated, eventually, to machine language using an interpreter or a compiler (or both!). You can think of an interpreter as translating one “line” of code at a time, while a compiler translates an entire program before executing it • Programs may be a few lines or millions of lines of code

  10. Programming Tasks • All computer programs are written so they can take data, manipulate and then produce a result. • This process uses three distinct tasks: • INPUT – getting data from an external source (the user, a database, a file, etc.) • PROCESSING – actual manipulation of the data • OUTPUT – reporting the results of data manipulation back (using the monitor, writing information to a database, etc.)

  11. Categories of Languages • Machine Language • Binary digits (bits – 1s and 0s) which are translated to electrical impulses that get the computer to do something • “Native” language of computers • Assembly Languages • Group of basic commands, written as mnemonics, ie, jmp, hlt, etc. • Tied to specific processors • Still need to be translated to machine language

  12. Categories of Languages • High Level Languages • In terms of syntax, very close to human language (mostly English) • Lower error rate than writing machine language or assembly language programs • Need to be translated to machine language before execution • Compilers • Interpreters

  13. More on High-Level Languages • Features common to all HL languages: • Sequential Operations – Operations in which lines of code execute in order, one right after another • Control Structures • Conditional Operations – Operations in which execution depends on the outcome of a previous condition (usually evaluated to be TRUE or FALSE) • Looping Operations – Operations designed to repeat until a given condition is satisfied. • Branching Operations – Operations designed to identify mutually exclusive sections of code • Data Structures – allow programming optimization, ie, arrays, linked lists, etc.

  14. More Features • Variables – named storage locations for data • Data types – integers, strings, boolean, etc. • Delimiters – symbols that designate beginning and endings of programming structure, ie, “;”, “{“, etc. • Modularity – section of code that performs a task • Comments – Information for programmers for better code maintenance • Input and output – mechanisms for moving information in and out of a program • Key reserved words – words with predefined meaning within a language

  15. Levels of High-Level Languages • Procedural Languages • Early high level languages • Focus on structures • Examples include QuickBasic, Fortran, Pascal, Visual Basic (early versions) • Object-Oriented languages (OOP) • More recent development • Focus on data, not structures (Primacy of Data) • Examples include Java, C#, C++, Visual Basic.Net

  16. The Programming Development Cycle • Done after identifying inputs, processing & outputs • Steps • Analyze the problem using customer input and technical training • Plan a solution to the problem (algorithm) • Design the user interface • Prototype design to customer • Revise design based on customer feedback • Iterate and test to product release • Maintenance cycle • Product Obsolescence

  17. Notes on Development Cycle • 1. Analyze the Problem: Questions to ask: • Who is my intended audience? • What SPECIFIC outcomes does my audience expect? • What business rules do my audience expect to have incorporated into the solution? • What is the SCOPE of the problem?

  18. 2. Plan a Solution (Algorithm) • What types of programming structures are needed? • Sequential structures • Conditional structures • Looping structures • What data structures are needed? • Variables • Lists • Arrays

  19. 3. Design the User Interface • i.e. , The “UI” • Is the UI “learnable”? • Is it simple? (Limit user choices) • Does the UI promote error-proof use? • Is the layout of the UI arranged in a fashion conducive to the user’s culture and expectations?

  20. 4. Code the Solution • Develop an actual program from an algorithm • Should be the “easiest” part of the process – all the work should already be done!

  21. 5. Test & Debug the Solution • Alpha Testing – Internal testing done with expected client data (NOT LIVE DATA) • Beta Testing – Testing done at the client site with their data (USUALLY LIVE DATA) • Try to predict common user errors • Test subjects should be Power Users, Normal Users and Neophytes

  22. 6. Make Sure Documentation is Complete • User Documentation: • User Manual • Technical Documentation (for System Administrators) • Internal Documentation: • Documentation comments • Code comments • Procedural comments • Should be done while coding!

  23. 7. Plan Next Release • What bugs need to be fixed? • Are bugs “critical”? (Need to be fixed in a minor release) • If bugs are not critical, they can be fixed in next major release • What product enhancements do the users want for the next release?

  24. Internal Commenting • Comments are non-executable lines (the computer ignores them) which are used to communicate valuable information about code to others • Types of Internal Commenting: • Documentation Comments • Code Comments • Procedural Comments • Comment Syntax: • C-like Syntax (C, C++, Java, JavaScript): /* This will work for multi-line comments */ // This is a single-line comment

  25. Documentation Comments • Used to given specific information about a program • Usually found at the beginning of a code window • Include information about the author, creation date, purpose, modification date & modification history

  26. Documentation Comment /* • TITLE: Hello World, v2.0* AUTHOR: Susie Student* PURPOSE: To demonstrate changing of textbox properties using event procedures.* CREATED ON: 09.10.2002* LAST MODIFIED ON: 09.18.2002* LAST MODIFIED BY: RSM* MODIFICATION HISTORY:* 08.12.2009 - Renamed form to frmMain to conform with accepted naming standards (MJK) *11.18.2008 - Created a Clear Button enabling users to clear output (RSM) */

  27. Code Comments • “Tell the story” of the code, in English • For this class, you should use code comments to indicate what lines of code do • Define how variables are being used • Describe sections of code

  28. Code Comments /* Initialize loop counter to 1 */var counter = 1;/* Set loop to repeat 10 times */while(counter <= 10){ /* Display loop number*/alert(“You are on loop number” + counter); /* update counter*/counter++; } /* end while */

  29. Procedural Comments • Identify purpose, arguments & return values for procedures • Can be used in: • Event Procedures • Sub-Procedures • Function Procedures

  30. Procedural Comments /* Function touchRock Used to capture user name and produce custom greeting. If name is provided, upon image mouse click change image to happy rock */ Function touchRock(){ varuserName = prompt(“What is your name?”, “Enter your name here.”); if (userName) { alert(“It is good to meet you, “ + userName + “.”); document.getElementById(“rockImg”).src = “rock_happy.png”; } //end if } // end function touchRock

  31. Questions?

More Related