Computer Science Principles - Big Idea 1

Collaboration

• A computing innovation includes a program as an integral part of its function. (CRD - 1.A.1)
• A computing innovation can be physical (e.g., self-driving car), nonphysical computing software (e.g., picture editing software), or a nonphysical computing concept (e.g., e-commerce). (CRD - 1.A.2)
  • Examples:
    • Facebook
    • Instacart
    • Online Shopping
• Effective collaboration produces a computing innovation that reflects the diversity of talents and perspectives of those who designed it. (CRD - 1.A.3)
• Collaboration that includes diverse perspectives helps avoid bias in the development of computing innovations. (CRD - 1.A.4)
• Effective collaborative teams practice interpersonal skills, including:
  • Communication
  • Consensus Building
  • Conflict Resolution
  • Negotiation (CRD - 1.C.1)
• Pair Programming:
  • Two programmers work together.
  • The driver writes code.
  • The observer (pointer/navigator) reviews each line.
• Think-Pair-Share:
  • Students think alone, pair to share ideas, and then share with the class.
• Leave comments in code to:
  • Communicate to partners.
  • Communicate to yourself.
  • Acknowledge code segments from other sources.
  • Acknowledge media from other sources.
  • Differentiate work between partners.
  • Clarify code functionality.
  • If the programming language doesn't allow comments, add them in an editor.
• Online collaboration tools:
  • repl.it - multiplayer
  • GitHub - collaboration and repository
  • Shared document or folder
• Get feedback by asking friends and family to test the program.

Computing Innovations

• Categories of Innovations:
  • Applications:
    • Games
    • Social Media
    • Business
    • Productivity
  • Physical Devices:
    • Computers
    • Smart Phones/tablets
    • Smart "Things" (without physical interactions)
    • Wearables
  • Systems:
    • E-commerce
    • Cloud services
    • E-mail
• Examples of Computing Innovations and Their Purpose:
  • Social Media Applications:
    • Allows users to connect from a distance and archive their activities.
  • E-commerce:
    • Allows users to save time and money by being able to shop from home.
  • Digital Assistant Device:
    • Allows users to control their devices hands-free, making them safer while driving or more convenient when trying to multitask.
• Guiding Questions for Computing Innovations:
  • Why does the computing innovation exist?
  • What problem(s) does the computing innovation solve?
  • What does the computing innovation allow us to do that we could not do before?

Program Function and Purpose

• Identifying Inputs to Programs:
  • Computer Programs accept input in a variety of different forms:
    • tactile (touch)
    • audio
    • visual
    • text (including numerical values)
  • Examples of input types for various devices:
    • Smart phone/tablet -> touch, audio, visual, text
    • Laptop computer -> text, visual, audio
    • Gaming Console -> touch, text
• How Programs Receive Input:
  • Most programs are written in an event-driven environment.
  • "Events" are triggered by some action, which usually sends input to the program.
  • Types of "events" a user can trigger:
    • mouse clicks
    • screen taps/swipes (force touch)
    • physical button clicks
    • keyboard entries
    • audio trigger (key word or phrase)
• How a Program Knows What To Do Upon an Event:
  • An action triggers an event.
    • Action may be initiated by the user or another program/device.
  • The program "jumps" to the code segment according to the event.
    • The code segment is executed.
    • Output is triggered by the code segment (or additional events are triggered).
  • The program code is not necessarily executed "in order".
    • Code segments are executed as they are called, according to the events triggered.
• Input usually affects the output.
• Types of Outputs Produced by a Device:
  • visual
  • audio
  • tactile (touch/feel)
  • text
  • Examples of output types for various devices:
    • Smart phone/tablet
    • Laptop computer
    • Gaming Console
• Essential Knowledge:
  • CRD-2.B.1: A program is a collection of program statements that performs a specific task when run by a computer. A program is often referred to as software.
  • CRD-2.B.2: A code segment is a collection of program statements that is part of a program.
  • CRD-2.B.3: A program needs to work for a variety of inputs and situations.
  • CRD-2.B.4: The behavior of a program is how a program functions during execution and is often described by how a user interacts with it.
  • CRD-2.B.5: A program can be described broadly by what it does, or in more detail by both what the program does and how the program statements accomplish this function.
• What is a program?
  • A program is a collection of statements.
  • A statement is a single command.
  • A group of statements is called a code segment.
  • Code segments are executed according to the rules of the programming language.
  • A program is often referred to as software.

Program Design and Development

• Essential Knowledge:
  • CRD-2.E.1: A development process can be ordered and intentional or exploratory in nature.
  • CRD-2.E.2: There are multiple development processes. The following phases are commonly used when developing a program:
    • investigating and reflecting things needed to create
    • designing
    • prototyping
    • testing
  • CRD-2.E.3: A development process that is iterative requires refinement and revision based on feedback, testing, or reflection throughout the process. This may require revisiting earlier phases of the process.
  • CRD-2.E.4: A development process that is incremental is one that breaks the problem into smaller pieces and makes sure each piece works before adding it to the whole.
  • CRD-2.F.1: The design of a program incorporates investigation to determine its requirements.
  • CRD-2.F.2: Investigation in a development process is useful for understanding and identifying the program constraints, as well as the concerns and interests of the people who will use the program.
  • CRD-2.F.3: Some ways investigation can be performed are as follows:
    • collecting data through surveys
    • user testing
    • interviews
    • direct observations
  • CRD-2.F.4: Program requirements describe how a program functions and may include a description of user interactions that a program must provide.
  • CRD-2.F.5: A program's specification defines the requirements for the program.
  • CRD-2.F.6: In a development process, the design phase outlines how to accomplish a given program specification.
  • CRD-2.F.7: The design phase of a program may include:
    • brainstorming
    • planning and storyboarding
    • organizing the program into modules and functional components
    • creation of diagrams that represent the layouts of the user interface
    • development of a testing strategy for the program
• How is a program developed?
  • Developers start investigating the problem/purpose and reflect.
  • Investigation is an important step in the process.
  • Developers must:
    • determine the requirements of the program
    • understand the constraints
    • understand the user concerns and interests
  • How do developers investigate?
    • surveys
    • user testing
    • interviews
    • direct observations
  • After initial investigation and reflection, developers design the program by
    • brainstorming (draw on investigation)
    • storyboarding the program
    • planning user experience how the user is
    • laying out the user interface
    • organizing into modules
    • develop a testing strategy the requirements after giving it what it is going to need in a software.
  • Developers decide on the program requirements that
    • describe how a program should behave
    • include a list of user interactions
    • The program specifications outline all of the requirements.
  • Developers create a prototype of the program (or components):
    • an incremental process is frequently used so developers can refine small parts (modules) of the program
  • Testing, testing, and more testing!
    • Developers test the program every step of the way.
    • Testing occurs at the micro level and macro level.
    • Developers refine and revise through testing, feedback, and reflection.
  • CRD-2.H.1: It is important to acknowledge any code segments that were developed collaboratively or by another source.
  • CRD-2.H.2: Acknowledgement of a code segment(s) written by someone else and used in a program can be in the program documentation. The acknowledgement should include the origin or original author's name.
  • Program development is rarely a solo endeavor.
  • Programs are usually developed by teams of people.
  • Individuals/teams work on different functional components.
  • Each member of the project deserves to receive credit for their work.
  • Their names must be written in the documentation of the program indicating their contributions to the project.
  • While documentation is an important place to give credit:
    • Many projects use comments within the programming language to give credit. This is an important part of the development of the program.
    • When developers find a bug (or an error in a program), they need to be able to determine who can/should fix the problem. This may be most useful after a program is completed, and users find additional bugs. to knew which person make the error.
  • Many times developers use code segments, procedures, algorithms, and more that are written by others.
  • These other individuals are not necessarily a part of the the project, but they still deserve to be credited.
  • This is similar to quoting someone in a research paper or article.
  • Any code segments, procedures, algorithms are considered intellectual property of the author.
  • The program documentation should include the author's name and the source of any code segments being used.
  • This portion of the documentation may resemble a bibliography or a works cited page in a research paper.
  • All of the following require crediting the original author(s) and/or source in program documentation except: Use of your own original code segments in a program you are writing.
  • CRD-2.G.1: Program documentation is a written description of the function of a code segment, event, procedure, or program, and how it was developed.
  • CRD-2.G.2: Comments are a form of program documentation written into the program to be read by people, and do not affect how a program runs.
  • CRD-2.G.3: Programmers should document a program throughout its development.
  • CRD-2.G.4: Program documentation helps in developing and maintaining correct programs when working individually or in collaborative programming environments.
  • CRD-2.G.5: Not all programming environments support comments, so other methods of documentation may be required.
  • How is a program developed?
    • Programmers create something called program documentation in order to:
      • describe the overall program
      • list program specifications
      • describe:
        • functions/procedures/methods within the code
        • specific code segments
        • list of events and corresponding outputs
        • the development of the program
        • how other programs may interact with the program
      • list of contributors/authors of the program
    • When does documentation happen?
      • Documentation happens throughout the development of the program:
      • At the beginning: list specifications
      • During: to keep track of process
      • After: to explain the overall process
    • Documentation throughout can improve:
      • efficiency of overall programming process
      • programmers' ability to test and refine the program
      • programmers' response to bugs.
    • How do programmers document while programming?
      • Most programming languages offer a commenting feature, although some do not.
      • Commenting allows programmers to write text within the program.
      • This text does not affect the program.
      • Comments are for programmers to read.
      • This is a form of documentation and can be very useful when programmers collaborate or work individually.
    • Examples of comments in text languages:
      • Python: # Comments appear on lines that follow the pound symbol (#)
      • Java: // Comments Single line comments appear after double forward slashes (//), /* Comments / Multiple line comments appear between forward slash asterisk combinations, /* Documentation */ Multiple line Documentation comments appear between forward slash - double asterisk combinations
      • Javascript, C/C++, Swift - similar to Java
      • XML/HTML: Comments can be single or multi line and appear after less than, exclamation point dash-dash, and terminate with dash-dash, greater than
      • Applescript/Pascal: (* Comments *) Comments can be single or multi line and appear after open parenthesis asterisk and terminate asterisk close parenthesis
    • Examples of comments in block-based languages:
      • Scratch
      • MIT AppInventor

Identifying and Correcting Errors

• Essential Knowledge:
  • CRD-2.I.1: A logic error is a mistake in the algorithm or program that causes it to behave incorrectly or unexpectedly.
  • CRD-2.I.2: A syntax error is a mistake in the program where the rules of the programming language are not followed.
  • CRD-2.I.3: A run-time error is a mistake in the program that occurs during the execution of a program. Programming languages define their own runtime errors.
  • CRD-2.I.4: An overflow error is an error that occurs when a computer attempts to handle a number that is outside of the defined range of values.
• Errors and programming go hand-in-hand!
  • Programmers are constantly running into errors when they program.
  • In fact, it is an expectation that errors are a part of the programming process.
  • Proficient programmers can identify errors as one of the following types:
    • Logic error
    • Syntax error
    • Run-time error
    • Overflow error
• Types of Errors:
  • Logic Error:
    • This error is caused by the programmer making a mistake in the algorithm, which causes the program to behave unexpectedly.
    • Example Code Segment:
      • grade = INPUT("Enter a grade")
      • IF (grade > 89) { DISPLAY ("A") }
      • IF (grade > 79 ) { DISPLAY ("B") }
      • IF (grade > 69 ) { DISPLAY ("C") }
      • IF (grade > 59 ) { DISPLAY ("D") }
      • ELSE { DISPLAY ("F")}
      • An "A" grade such as 90 would display "A" as intended, but would also display "B," "C," and "D" as well.
  • Syntax Error:
    • This is a mistake when a programmer makes a typo or writes some code (or forgets to write some code) that doesn't follow the rules of the language.
    • Syntax errors cause the program to fail to run/compile.
    • Common examples of this are forgetting to include:
      • colon/semicolon
      • parenthesis
      • curly braces
      • indentation
      • quotes
      • variable definition
    • Example Code Segment:
      • grade = INPUT("Enter a grade")
      • IF (grade > 89 { DISPLAY ("A") }
      • IF (grade > 79 ) { DISPLAY ("B")
      • IF (grade > 69 ){ DISPLAY ("C)}
      • IF (grade >59){ DISPLAY ("D") }
      • ELSE DISPLAY ("F")}
  • Run-time Error:
    • A run-time error is when a program fails in the midst of running.
    • This error is commonly referred to as a "bug."
    • The key to identifying a run-time error is that the program runs/compiles initially, but fails and cannot complete its processes.
    • A run-time error may result from:
      • dividing by zero
      • inappropriately entered data typer
    • Example Code Segment:
      • grade = INPUT("Enter a grade")
      • IF (grade > 89 ) { DISPLAY ("A") }
      • IF (grade > 79 ) { DISPLAY ("B") }
      • IF (grade > 69 ) { DISPLAY ("C") }
      • IF (grade > 59 ) { DISPLAY ("D") }
      • ELSE { DISPLAY ("F")}
      • If the user were to enter a non-numerical character, most programming languages would result a run-time error when trying to compare a word to the number 89.
  • Overflow Error:
    • An overflow error is when a program is required to perform a calculation that is outside of defined range of values.
    • Due to memory allocation constraints that programming languages require, certain values are too big to calculate and/or display.
    • Imagine you have a calculator that has 4 display digits, what is the largest value this calculator could display? 9,999
    • What would be the result if you tried to calculate 100*100? 10,000 is the result.
    • But this calculator cannot display that value, so the result would be an overflow error.
  • CRD-2.I: For errors in an algorithm or program:
    • b. Correct the error.
  • CRD-2.I.5: The following are effective ways to find and correct errors:
    • test cases
    • hand tracing
    • visualizations
    • debuggers
    • adding extra output statement(s)
  • What do we do once we have identified an error?
    • The easiest error to correct is usually the syntax error.
    • Most integrated development environments (IDES) display information when there is a syntax error.
    • This information usually directs the programmer to the line in the program where the error has occurred.
    • Sometimes the user needs to do a little digging to find the error.
  • The more difficult errors to find and correct are logic errors.
    • A logic error is not always immediately noticed.
    • Using test cases is the first strategy programmers use to find logic errors.
    • Example Code Segment:
      • grade = INPUT("Enter a grade")
      • IF (grade > 89 ) { DISPLAY ("A") }
      • IF (grade >79){ DISPLAY ("B") }
      • IF (grade > 69 ) { DISPLAY ("C") }
      • IF (grade >59) { DISPLAY ("D") }
      • ELSE { DISPLAY ("F") }
      • We should use a number of test cases such as a percentage in each grade category like 95, 82, 76, 61, and 58.
    • The next strategy to try is hand tracing
      • Hand tracing can be most useful with iteration (loops).
      • Hand tracing is simply writing out the values of the variables within the loop as it iterates to determine if the outcome is correct.
      • Hand tracing can be useful for small code segments and loops that iterate a small number of times.
    • List = [2, -3, 5, 1, 10, 8]
    • Another strategy is adding extra output statements
      • A programmer would use this strategy to help find and fix an error.
      • Once the error is corrected, the extra output statements are usually removed.
      • This has a similar effect as hand tracing, but allows the computer to do more of the work.
    • If those strategies fail…
      • Some IDEs allow programmers to use visualizations and/or debuggers.
      • Visualizations show graphs, images, color, etc. (things that can be visualized) that can help determine if a program is working correctly.
      • Debuggers use software designed to run a program, allowing it to be paused and tested in the midst of running to determine if it is working properly.
  • CRD-2.J.1: In the development process, testing uses defined inputs to ensure that an algorithm or program is producing the expected outcomes. Programmers use the results from testing to revise their algorithms or programs.
  • CRD-2.J.2: Defined inputs used to test a program should demonstrate the different expected outcomes that are at or just beyond the extremes (minimum and maximum) of input data.
  • CRD-2.J.3: Program requirements are needed to identify appropriate defined inputs for testing.
  • Specifications influence testing
    • Recall that the program specifications list the behaviors, events, and corresponding responses/ outputs the program is to support.
    • Programmers need to define inputs that will determine whether or not the program specifications are met.
  • When do we start testing a program?
    • Programmers start testing a program at the onset of development.
    • Or at least, they start thinking about testing. As soon as programmers determine the program specifications. they start trying to answer the question: "How will we know if the program is working properly?"
  • Before ever writing this code segment, we must think about the lists we will use to test the algorithm. By the way, this algorithm does not work, or at least it does not always work.
  • temp ← INPUT("Enter the temperature")
    • IF (temp <32) {
    • DISPLAY ("Watch out for snow!")}
    • ELSE {
    • IF (temp > 90) {
    • DISPLAY ("Turn on AC!") }
    • ELSE {
    • DISPLAY ("Enjoy the weather.") }
    • }
  • How does this influence program development?
    • Once the inputs and corresponding outputs are determined, programmers test, test, and test.
    • After testing, programmers use the results the revise, refine, and improve their programs.
    • And then they test them again and again.
    • After the programmers test, then users test, and then the programmers refine even more,
    • And finally, the program is released.