コンテンツへ移動

Edexcel GCSE Computer Science

GCSE · EdexcelComputer Science6個のフォルダーに32件のノート、168 KB

試験勉強用ノート32件。cookieが作成。コースのトピックに沿った6個のセクションに分かれています。

Notes for Pearson Edexcel GCSE Computer Science (1CP2), in folders for the specification's six topics in its order: computational thinking, data, computers, networks, issues and impact, and problem solving with programming. Each folder has one note per sub-topic or small group of them, and the code is Python 3. Follows the specification (Issue 1, January 2020) for exams from 2027.

追加すると、そのコピーがノートに保存されます。専用のフォルダに下のフォルダ構成ごと入り、編集してフラッシュカードや問題デッキにできます。ダウンロードすると、どのノートアプリでも開けるマークダウンファイルのzipが取得できます。

内容

  • Computational thinking
    • Decomposition, abstraction and subprograms5 KB
    • Algorithms, flowcharts and trace tables6 KB
    • Errors, test data and evaluating algorithms6 KB
    • Searching algorithms5 KB
    • Sorting algorithms5 KB
    • Truth tables4 KB
  • Data
    • Binary and integers5 KB
    • Binary arithmetic, shifts, overflow and hexadecimal5 KB
    • Characters and bitmap images5 KB
    • Sound4 KB
    • Storage units, file sizes and compression5 KB
  • Computers
    • The CPU and the fetch-decode-execute cycle5 KB
    • Secondary storage and embedded systems5 KB
    • Operating systems, utility software and reliable software5 KB
    • Programming languages and translators5 KB
  • Networks
    • Networks, the internet and topologies6 KB
    • Wired and wireless connections, and transmission calculations5 KB
    • Protocols and the TCP/IP model6 KB
    • Network security5 KB
  • Issues and impact
    • Environmental issues5 KB
    • Personal data: ethical and legal issues5 KB
    • AI, machine learning and robotics5 KB
    • Protecting intellectual property5 KB
    • Malware and cyberattacks6 KB
    • Protecting digital systems and data6 KB
  • Problem solving with programming
    • Developing and refining code7 KB
    • Data types, variables, constants and operators6 KB
    • Selection and iteration5 KB
    • Strings4 KB
    • Lists, two-dimensional lists and records4 KB
    • Input, validation, authentication and files6 KB
    • Subprograms and scope5 KB

最初のノート

Computational thinking / Decomposition, abstraction and subprograms

Decomposition

Decomposition means breaking a large problem into smaller parts, each of which is easier to understand, solve and test than the whole. The parts are then broken down again until every one is small enough to write as a single piece of code. It is applied to the problem before any program is written, and the result is a list of separate jobs rather than one tangle.

Suppose a school wants a program to run a library. The whole problem is too big to hold in your head, but it splits naturally:

  • looking up a book by title or author
  • lending a book to a member and recording the return date
  • working out fines for late returns
  • adding new members and removing old ones

Each of these can be split further. Working out fines needs the number of days late, the fine per day and a cap on the total, and each of those is a small question with a definite answer.

The benefits are practical ones. Different people can write different parts at the same time, so a team finishes sooner. Each part can be tested on its own, so a fault is found in a small piece of code and not somewhere in thousands of lines. A part that already exists, such as the fines calculation, can be reused or replaced without touching the rest. And a large problem stops being intimidating once it is a set of small ones.

Abstraction

Abstraction means removing the detail that does not matter for the problem and keeping the detail that does, so that a model of the real world is simple enough to work with. The model is never the whole truth; it is a version of the truth that has been trimmed to fit a purpose.

A map of the London Underground is the standard example. It leaves out the real distances between stations, the curves of the tracks and everything above ground, and it keeps only the order of the stations, the lines and where they interchange. That is all a passenger planning a trip needs, and the extra detail would make the map harder to read.

Abstraction appears in programs in several places:

  • a variable called total_cost stands for a value without the program needing to say where in memory it is held
  • a function such as len(name) hides the steps used to count the characters, and the programmer only needs to know what it returns
  • a model of a bank account might keep the account number, the owner and the balance, and leave out the account holder's height, favourite colour and everything else that has no effect on the work the program does

Deciding what to leave out is part of the skill. A model that leaves out something the program depends on gives wrong answers, and one that keeps everything is as hard to use as the real thing. A parcel-delivery program needs the address, the weight and the size of each parcel, but not the colour of the box.

Decomposition and abstraction are used together. Decomposition divides the problem into parts, and abstraction decides, for each part, which details it needs to deal with.

Subprograms

A subprogram is a named block of code that does one job and can be run from anywhere in a program by using its name. In Python a subprogram is written with def. Using its name to run it is called calling it. Subprograms are a direct way of putting decomposition into code, since each small part of the problem becomes one subprogram.

def calculate_fine(days_late):
    fine = days_late * 20
    if fine > 1000:
        fine = 1000
    return fine

print(calculate_fine(3))
print(calculate_fine(80))

The fine is held in pence. The first call prints 60, and the second prints 1000 and not 1600, because the fine is capped at 10 pounds.

The benefits of using subprograms are these.

  • Code is written once and used many times, which makes the program shorter. A subprogram that formats a date can be called in fifty places without fifty copies of the code.
  • A change or a fix is made in one place. If the fine per day changes, only calculate_fine is edited, and every call uses the new rule.
  • Each subprogram can be tested by itself, before the program that uses it is finished.
  • A team can share out the work, because each member writes subprograms that other members simply call.
  • The main program is easier to read, because its lines name what is being done (calculate_fine) instead of showing every step.
  • Subprograms that already exist, such as those in a library, can be used without the programmer knowing how they work inside, which is abstraction again.

The detail of how subprograms take values in through parameters, hand values back with return and treat variables inside and outside them is set out in the programming notes.

追加またはダウンロードすると、さらに31件あります。

レビュー

文章でのレビューはまだありません。このノートを自分のノートに追加して、最初のレビューを投稿できます。