DOCSLIB.ORG

NAHS Technology and Business Department Introduction to Programming Curriculum Map

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
NAHS Technology and Business Department Introduction to Programming Curriculum Map NAHS Technology and Business Department Introduction to Programming Curriculum Map NAHS Technology and Business Department Introduction to Programming Curriculum Map Overview In this course, students are introduced to the fundamentals of computer programming. Students will explore programming concepts such as input/output, variables, methods, control logic, looping, arrays, classes, encapsulation, inheritance, and exception handling using both a graphical and text-based interface. Students will become proficient in code design, development, and testing process by applying these concepts to create various puzzles, forms, and games Curriculum Components • History of computers o Original needs that led to computer development o Historical figures related to the development of computers o The role of government in the development of computers o Computer generations & their characteristics • History of programming languages o The role of a computer program o Differences between computers and humans o Programming language generations and their characteristics o Characteristics of structured programming • Number Systems o Understanding number systems used by computers, understanding why they are used, and physical conversion among them • Programming concepts o Object oriented programming o Information hiding/encapsulation o Concepts related to classes, objects, and instances • Programming Lifecycle o Designing o Building the interface o Adding code o Testing o Concepts involved with building the final application (stand-alone) and understanding the difference between source code and object (executable) code Revised 10/31/10 1 NAHS Technology and Business Department Introduction to Programming Curriculum Map • Objects and Event Handlers o Understand what causes events to be “fired” o Using the appropriate event handler o Using the appropriate object for the intended job • Programming concepts o Assigning values to properties o The concept of datatypes o New dataype: strings o Handling basic syntax errors. o Operators -- mathematical & string o New datatypes – integer, double, single, boolean • Programming concepts o Object hierarchy o Superclass, subclass o inheritance • Effectively using the Language Reference as a source of information • Color o Physics of light – how we all see differently o Color psychology o Additive synthesis (computers – RGB), Subtractive Synthesis (printing – CMYK) o How computers store color data o Using color in programs to set background and to change text color • Working with windows o Adding windows within the IDE o Adding windows during program execution – instantiation, placement o Window order-of-events (and under what conditions) firing compared to objects on the window • Working with images o (External application) Basic image usage – resizing images, creating gradients, adding effects o Importing images into projects o Adding images to the background of a window and to objects • Building projects o Actual project build – awareness of operating system intention (end product) o Adding project notes Revised 10/31/10 2 NAHS Technology and Business Department Introduction to Programming Curriculum Map • Variables o Concept o Methodology and application of declaring, initializing and using variables appropriately o Program scope o Variable type -- local variables • String operations o Manipulation functions, casting, formatting for output • Decision constructs o Methodology and application of basic, nested, and compound decision constructs o Truth tables – AND, OR, XOR, NOT and their application to programming logic • Handling single & multiple user choice o Using objects that allow single and multiple user selections • Programming concepts o Commenting code – for general program information & within code o Operator overloading (comparison) o Code efficiency • Methods o Understanding the concept o Built-in vs user defined o Types of methods – functions, subroutines o Analysis of built-in methods o Method creation The design process Implementation with each method type o Method scope • Exception handling o Syntax vs runtime errors o Internal problems o User data validation and resulting notification and event handling • Global variables o Scope o Use Revised 10/31/10 3 NAHS Technology and Business Department Introduction to Programming Curriculum Map • Looping constructs o Concepts o Infinite loops o Usage – for, while • Non-scalar (object) datatypes o Declaration, instantiation • Programming Concepts o Manual instantiation of objects o Nil objects, nilobjectexception – graceful exit • Arrays o Creating, populating, accessing, converting • Timers o Concept o Use • Career Exploration o Video game design o Video game programming o Programming languages & platforms o Higher education opportunities in computer programming and in gaming Revised 10/31/10 4 .
Load more

Recommended publications
  • Why Do Developers Neglect Exception Handling?
    Why Do Developers Neglect Exception Handling? Hina Shah, Carsten Görg, Mary Jean Harrold College of Computing, Georgia Institute of Technology, Atlanta, Georgia, U.S.A. {hinashah,goerg,harrold}@cc.gatech.edu ABSTRACT code. However, in these proposed approaches both types of code In this paper, we explore the problems associated with exception (main functionality code and exception handling code) would still handling from a new dimension: the human. We designed a study be implemented by the same developer. Filho and colleagues [2, that evaluates (1) different perspectives of software developers to 3] suggest lexically separating error-handling code from normal understand how they perceive exception handling and what meth- code so that both code types can be independently modified. In ods they adopt to deal with exception handling constructs, and (2) addition they propose leveraging aspect-oriented programming to the usefulness of a visualization tool that we developed in previ- enhance the separation between error-handling code and normal ous work for exception handling. We describe the design of our code. Zhang and colleagues [10] propose a different approach that study, present details about the study’s participants, describe the provides programmers with more intuitive exception-handling be- interviews we conducted with the participants, present the results havior and control. of the study, and discuss what we learned from the study. Based All these approaches concentrate on enhancing the separation on our analysis, we suggest several
    [Show full text]
  • SWI-Prolog 5.8.1 Reference Manual In
    University of Amsterdam Kruislaan 419, 1098 VA Amsterdam VU University Amsterdam De Boelelaan 1081a, 1081 HV Amsterdam The Netherlands SWI-Prolog 5.8 Reference Manual Updated for version 5.8.1, November 2009 Jan Wielemaker [email protected] http://www.swi-prolog.org SWI-Prolog is a Prolog implementation based on a subset of the WAM (Warren Ab- stract Machine). SWI-Prolog was developed as an open Prolog environment, providing a powerful and bi-directional interface to C in an era this was unknown to other Prolog implementations. This environment is required to deal with XPCE, an object-oriented GUI system developed at SWI. XPCE is used at SWI for the development of knowledge- intensive graphical applications. As SWI-Prolog became more popular, a large user-community provided requirements that guided its development. Compatibility, portability, scalability, stability and provid- ing a powerful development environment have been the most important requirements. Edinburgh, Quintus, SICStus and the ISO-standard guide the development of the SWI- Prolog primitives. This document gives an overview of the features, system limits and built-in predicates. Copyright c 1990–2009, University of Amsterdam Contents 1 Introduction 10 1.1 SWI-Prolog....................................... 10 1.1.1 Books about Prolog............................... 10 1.2 Status.......................................... 11 1.3 Compliance to the ISO standard............................ 11 1.4 Should you be using SWI-Prolog?........................... 11 1.5 The XPCE GUI system for Prolog........................... 12 1.6 Release Notes...................................... 13 1.7 Donate to the SWI-Prolog project........................... 19 1.8 Acknowledgements................................... 19 2 Overview 21 2.1 Getting started quickly................................
    [Show full text]
  • Accepting Blame for Safe Tunneled Exceptions
    Accepting Blame for Safe Tunneled Exceptions Yizhou Zhang∗ Guido Salvaneschiy Quinn Beightol∗ Barbara Liskovz Andrew C. Myers∗ ∗Cornell University, USA yTU Darmstadt, Germany zMIT, USA [email protected] [email protected] [email protected] [email protected] [email protected] Abstract 1. Introduction Unhandled exceptions crash programs, so a compile-time Exceptions make code more reliable by helping programmers check that exceptions are handled should in principle make handle abnormal or unusual run-time conditions. The core software more reliable. But designers of some recent lan- idea is to transfer control in a nonlocal way to handler code guages have argued that the benefits of statically checked ex- that can be factored out from common-case code. This sepa- ceptions are not worth the costs. We introduce a new stati- ration of concerns simplifies code and prompts programmers cally checked exception mechanism that addresses the prob- not to forget about exceptional conditions. lems with existing checked-exception mechanisms. In partic- There has been disagreement since the 1970’s about how ular, it interacts well with higher-order functions and other or whether exceptions should be subject to static check- design patterns. The key insight is that whether an excep- ing [19, 28]. This disagreement continues to the present tion should be treated as a “checked” exception is not a prop- day [17]. Some currently popular languages—Java [20] and erty of its type but rather of the context in which the excep- Swift [46]—offer checked exceptions that the compiler stati- tion propagates. Statically checked exceptions can “tunnel” cally ensures are handled.
    [Show full text]
  • Dissertation Presented to the Faculty of the Graduate School of Cornell University
    DESIGNING FLEXIBLE, MODULAR LINGUISTIC ABSTRACTIONS A Dissertation Presented to the Faculty of the Graduate School of Cornell University in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy by Yizhou Zhang August 2019 © 2019 Yizhou Zhang ALL RIGHTS RESERVED DESIGNING FLEXIBLE, MODULAR LINGUISTIC ABSTRACTIONS Yizhou Zhang, Ph.D. Cornell University 2019 Programming-language design is more active than ever: existing languages are evolving continually and rapidly, and new languages keep springing up. While this constant iteration of language design aims to help programmers manage a growing software complexity, programmers are still frequently frustrated by poor design decisions in even the most essential aspects of modern program- ming languages. Less than satisfactory solutions to generic programming and exception handling typify this situation: the inadequacy of current solutions has even forced language designers to abandon these problematic language features. This is an unfortunate state of affairs. Language design does not have to be about abandoning old features or piling on new ones. This dissertation proposes novel linguistic abstractions for the aforementioned design problems, offering ease of use, expressive power, strong guarantees, and good performance all at the same time. It introduces a new mechanism for generic programming, embodied in the Genus programming language. Genus adds expressive power and strengthens static checking, while handling common usage patterns simply. The power of Genus is then integrated into a second language design, Familia, that unifies several polymorphism mechanisms in a lightweight package. Evaluation sug- gests the design of Genus and Familia addresses the need for genericity and extensibility in developing large, complex software.
    [Show full text]
  • Expressive Checked Exceptions
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by eCommons@Cornell Accepting Blame: Expressive Checked Exceptions Yizhou Zhang∗ Guido Salvaneschiy Quinn Beightol∗ Barbara Liskovz Andrew C. Myers∗ ∗Cornell University yTU Darmstadt zMIT [email protected] [email protected] [email protected] [email protected] [email protected] April, 2016 Abstract Unhandled exceptions crash programs, so a compile-time check that exceptions are handled should in principle make software more reliable. But designers of some recent languages have argued that the benefits of statically checked exceptions are not worth the costs. We introduce a new statically checked exception mechanism that addresses the problems with existing checked-exception mechanisms. In par- ticular, it interacts well with higher-order functions and other design patterns. The key insight is that whether an exception should be treated as a “checked” exception is not a property of its type but rather of the context in which the exception propagates. Statically checked exceptions can “tunnel” through code that is oblivious to their presence, but the type system nevertheless checks that these exceptions are handled. Further, exceptions can be tunneled without being accidentally caught, by expanding the space of exception identifiers to identify the exception-handling context. The resulting mechanism is ex- pressive and syntactically light, and can be implemented efficiently. We demonstrate the expressiveness of the mechanism using significant codebases and evaluate its performance. We have implemented this new exception mechanism as part of the new Genus programming language, but the mechanism could equally well be applied to other programming languages.
    [Show full text]
  • Technical Report on C++ Performance
    ISO/IEC TR 18015:2004(E) 2005-06-15 Information Technology — Programming languages, their environments and system software interfaces Technical Report on C++ Performance Technical Report on C++ Performance ISO/IEC TR 18015:2004(E) Contents Contents ......................................................................................2 Foreword ......................................................................................4 Introduction ......................................................................................5 1 Scope ......................................................................................7 2 Normative References .....................................................................8 3 Terms and definitions .....................................................................9 4 Typical Application Areas ............................................................. 18 4.1 Embedded Systems.......................................................................................................18 4.2 Servers.............................................................................................................................20 5 Language Features: Overheads and Strategies .......................... 21 5.1 Namespaces ...................................................................................................................21 5.2 Type Conversion Operators........................................................................................22 5.3 Classes and Inheritance................................................................................................23
    [Show full text]