Welcome to Unit AS 1: Introduction to Object Oriented Development
Hello and welcome to your study notes for Unit AS 1: Introduction to Object Oriented Development! Whether you are completely new to programming or already have some coding experience, these notes will guide you step-by-step through the core concepts of software, system architecture, programming constructs, and object-oriented design.
Don't worry if some terms feel new or challenging at first. We will break down every concept with clear everyday analogies, memory aids, and exam tips to help you build solid confidence for your CCEA examination.
1. Computer Architecture & Language Translators
Before software can run, it needs hardware to execute instructions and translators to convert human-readable code into something the computer hardware can process.
Memory and Storage Foundations
A computer relies on different types of memory to execute programs efficiently:
• Registers: Extremely fast, small memory locations directly inside the Central Processing Unit (CPU) used to hold temporary data and instructions currently being processed.
• Cache: Very fast memory located on or near the CPU that stores frequently accessed instructions to speed up processing.
• Random Access Memory (RAM): Volatile primary internal memory that holds the operating system, currently running applications, and active program data. When the computer turns off, data in RAM is lost.
• Read Only Memory (ROM): Non-volatile internal memory that permanently stores essential startup instructions (such as the basic boot-up firmware).
• Secondary Storage: Non-volatile storage (such as hard drives and solid-state drives) used to store software applications, files, and data permanently when not actively in use.
System Software & Language Translators
Computers only understand machine code (binary 1s and 0s). Because humans write code in high-level programming languages (source code), we need language translators to convert our code into machine instructions:
• Assembler: Translates low-level assembly language mnemonics into machine code.
• Compiler: Translates the entire high-level source code into machine code in one go before execution. If errors exist, it produces an error list. Once compiled, an executable file is produced which runs very quickly without needing the original source code.
• Interpreter: Translates and executes high-level source code line-by-line. If an error is found, execution stops immediately at that line. This makes debugging easier during development, but execution is slower.
Compilation Models: Native Code vs Intermediate Bytecode
How does source code turn into a running program? There are two main models you must know:
1. Native Machine Code Compilation: The compiler converts source code directly into specific machine code for a particular operating system and CPU architecture.
2. Intermediate Bytecode / CIL (Common Intermediate Language): The compiler first translates source code into an intermediate format (often called bytecode or CIL). This intermediate code is not direct machine code. Instead, it is executed by a Virtual Machine / Runtime Environment, allowing the program to run across different platforms without changing the source code.
Key Takeaway: Translators convert human-readable source code into machine code. Compilers translate the whole program at once; interpreters translate line-by-line; modern managed languages often compile source code into intermediate bytecode executed on a virtual machine runtime.
2. Software Development Life Cycle (SDLC) & Methodologies
Creating reliable software requires a structured process known as the Software Development Life Cycle (SDLC).
The Phases of the SDLC
• 1. Analysis: Understanding the problem. Requirements are gathered from stakeholders to produce a clear specification of what the software must do.
• 2. Design: Planning the solution. System architecture, user interfaces, database structures, algorithms, and class diagrams are designed.
• 3. Implementation / Coding: Writing the actual program code in the chosen programming language based on the design specifications.
• 4. Testing: Running the software with planned test data to detect and fix bugs, ensuring it meets all requirements.
• 5. Documentation: Creating technical documentation for developers and user guides for end users.
• 6. Deployment: Installing and releasing the completed software into the live environment for the client or public.
• 7. Maintenance: Fixing bugs discovered after release, updating software for new operating systems, or adding new user requirements over time.
Software Development Methodologies
Software teams follow different approaches depending on project size, risk, and flexibility:
• Waterfall Model (Predictive): A linear, sequential approach where each phase must be fully completed and signed off before the next phase begins. It is easy to manage and works best when project requirements are completely fixed and well-understood from the start. However, it is rigid and hard to adapt if requirements change late in development.
• Iterative / Agile Models: A flexible approach where software is developed in small, repeated cycles (iterations) resulting in frequent incremental releases. It emphasizes continuous collaboration with customers and adapts quickly to changing requirements.
Memory Aid for SDLC: Remember All Developers Invent Terrific Digital Devices Monthly (Analysis, Design, Implementation, Testing, Documentation, Deployment, Maintenance).
3. Object-Oriented Programming (OOP) Fundamentals
Object-Oriented Programming is a way of designing software by modeling real-world entities as software objects.
Classes vs Objects
• Class: The blueprint, template, or definition of a data type. It specifies what attributes (data) and methods (behaviours) instances of that class will have.
• Object: A concrete, instantiated entity created from a class template. An object has its own state (values stored in its fields/attributes) and behaviour (the methods it can execute).
Analogy: An architectural blueprint of a house is the class; the physical brick-and-mortar house built on your street is the object.
Constructors and Instantiation
To create an object from a class, we use the new keyword. This process is called instantiation. When an object is instantiated, a special initialization method called a constructor is automatically executed to set up initial attribute values.
The Four Pillars of OOP
Object orientation rests on four core principles:
1. Encapsulation:
Encapsulation is the bundling of data (attributes) and the methods that operate on that data into a single unit (a class), while restricting direct access to internal components from outside code.
• We achieve this using access modifiers: private (accessible only within the class), public (accessible from any code), and protected (accessible within the class and its derived subclasses).
• Access to private attributes is safely managed through accessor methods (getters) and mutator methods (setters), or properties, which allow validation before changing data.
2. Abstraction:
Hiding complex, low-level implementation details and showing only the essential features to the outside world. The user knows what an object does without needing to know how it does it internally.
3. Inheritance:
A mechanism where a derived class (subclass/child) inherits attributes and methods from an existing base class (superclass/parent).
• It establishes an "is-a" relationship (e.g., a Car "is-a" Vehicle).
• It promotes code reuse, because common code is written once in the base class and reused by child classes.
4. Polymorphism:
The ability of different classes to respond to the same method call in their own unique way ("many forms"). There are two forms:
• Method Overloading (Compile-Time / Static Polymorphism): Defining multiple methods within the same class that share the same name but have different parameter lists (different number, types, or order of parameters).
• Method Overriding (Runtime / Dynamic Polymorphism): A subclass provides its own specific implementation of a method that is already defined in its base class, using the exact same name and signature.
Key Takeaway: The 4 Pillars are Encapsulation (protecting data), Abstraction (hiding complexity), Inheritance (code reuse via parent/child), and Polymorphism (methods taking multiple forms via overloading or overriding).
4. Programming Constructs, Data Types, and Collections
Core Control Structures
Every algorithm can be constructed using three fundamental building blocks:
• Sequence: Executing statements one after another in order from top to bottom.
• Selection: Making decisions to follow different paths of execution based on a condition (e.g., if-else statements, switch/case structures).
• Iteration: Repeating a block of code. This includes definite loops (e.g., for loops, where the number of repetitions is known beforehand) and indefinite loops (e.g., while and do-while loops, which repeat until a condition changes).
Data Types and Variables
• Primitive Data Types: Basic data values stored directly in memory, such as integers (whole numbers), floating-point numbers (decimals), booleans (true/false), and characters (single letters or symbols).
• Reference Data Types: Data types where the variable stores a reference (memory address) pointing to the actual data located elsewhere in memory. Examples include strings, arrays, and user-defined class objects.
Variable Scope and Lifetime
• Local Variables: Declared inside a method or block; accessible only within that block; destroyed when the block finishes execution.
• Parameters: Variables passed into a method signature to receive input data for that method.
• Instance Variables: Declared inside a class but outside methods; each instantiated object holds its own copy.
• Class / Static Variables: Declared with a static keyword; shared across all instances of a class (only one copy exists in memory).
Collections of Data: Arrays and Lists
• Arrays: Fixed-size collections storing elements of the same data type. Arrays can be single-dimensional or multidimensional.
• Zero-Based Indexing: Array indices start at \(0\). For an array of size \(N\), the first element is at index \(0\) and the final element is at index \(N - 1\). Attempting to access index \(N\) results in an "Index Out of Bounds" error.
• Dynamic Lists / Collections: Unlike standard fixed arrays, dynamic collections can grow and shrink in size dynamically as elements are added or removed.
• Linear Traversal: Iterating through an array sequentially from the start to the end using a loop to process, display, or search for elements.
5. Testing and Documentation Procedures
Software must be verified to ensure it works correctly, handles unexpected user behaviour safely, and can be maintained in the future.
Testing Classifications
• Unit / Component Testing: Testing individual methods, functions, or classes in complete isolation to verify that each small unit works correctly on its own.
• Integration Testing: Combining individual units/modules together and testing their interfaces to ensure they interact correctly.
• System / Acceptance Testing: Testing the complete, fully integrated software system against the user requirements to ensure it satisfies business needs and customer expectations.
Test Data Selection
When creating a test plan, you must choose three specific categories of test data:
• Normal Test Data: Valid, typical data that falls squarely within the acceptable range and should be processed normally.
• Boundary / Extreme Test Data: Data values situated at the absolute outer edges of the acceptable input limits.
• Erroneous / Abnormal Test Data: Invalid data (such as incorrect data types or values strictly outside allowable limits) that should be rejected by validation routines or trigger appropriate exception handling.
Example Test Plan Scenario: If an input field accepts an integer exam score between \(1\) and \(100\) inclusive (\(1 \le x \le 100\)):
• Normal data: \(50\), \(75\)
• Boundary / Extreme data: \(1\), \(100\)
• Erroneous / Abnormal data: \(-5\), \(101\), "abc"
Software Documentation Types
• User Documentation: Targeted at end users who will operate the system. Includes installation guides, user manuals, troubleshooting FAQs, and screen walk-throughs.
• Technical Documentation: Targeted at software engineers and system maintainers. Includes annotated source code, API specifications, UML class diagrams, database schemas, and data dictionaries.
6. Common Exam Pitfalls & Examiner Tips
Make sure to avoid these frequent exam mistakes highlighted in examiner reports:
• Pitfall 1: Confusing Class vs Object.
Remember: The class is the written code template/blueprint. The object is the actual instance living in memory during program execution.
• Pitfall 2: Incomplete Definition of Encapsulation.
Remember: Encapsulation is not just "hiding code." It is the bundling of data and methods together inside a class combined with restricting direct access using access modifiers (like private) and providing controlled access via getters and setters.
• Pitfall 3: Mixing up Overloading and Overriding.
Remember:
• Overloading = Same class, same method name, different parameter signatures (Compile-time).
• Overriding = Subclass replaces a base class method with the identical signature (Runtime).
• Pitfall 4: Boundary Test Data Errors.
Remember: Boundary values are valid values on the very edge of the allowed range. For \(1 \le x \le 100\), the boundary values are \(1\) and \(100\). Do not give \(0\) or \(101\) as boundary data (those are erroneous data values!).
• Pitfall 5: Array Off-By-One Indexing.
Remember: In zero-based indexing, an array with \(N\) items has valid indices from \(0\) up to \(N - 1\). An index of \(N\) is out of bounds!
Quick Chapter Summary
• System Software & Architecture: RAM, ROM, cache, and registers work together with the CPU. Compilers translate everything in one pass, interpreters translate line-by-line, and modern virtual machines execute intermediate bytecode/CIL.
• SDLC: Structured sequential phases (Analysis \(\rightarrow\) Design \(\rightarrow\) Coding \(\rightarrow\) Testing \(\rightarrow\) Documentation \(\rightarrow\) Deployment \(\rightarrow\) Maintenance). Waterfall is linear and predictive; Agile is iterative and flexible.
• OOP Pillars: Encapsulation (data bundling & access restriction), Abstraction (hiding details), Inheritance (parent-child reuse), Polymorphism (overloading & overriding).
• Testing & Docs: Unit \(\rightarrow\) Integration \(\rightarrow\) System testing. Use Normal, Boundary (edge of valid), and Erroneous data. Provide User docs for operators and Technical docs for developers.