Assignment Chef icon Assignment Chef
All English tutorials

Programming lesson

Mastering Modularity, Testing, and Git for Your ISEN1000 Timetable Manager

A comprehensive tutorial covering modular design, black-box/white-box testing, and version control for the ISEN1000 timetable management assignment. Learn how to structure your code, write test cases, and use Git effectively.

ISEN1000 software engineering assignment modularity principles black-box testing white-box testing Git version control timetable management system unit testing test case design code refactoring software engineering tutorial college timetable project Git branching strategy input validation cohesion and coupling student project help

Introduction

In the ISEN1000 Introduction to Software Engineering assignment, you are tasked with building a college timetable management system. This tutorial will guide you through three core areas: modularity, testing, and version control. By the end, you will be able to design clean, modular code, write effective test cases, and track your project using Git. These skills are essential not only for this assignment but also for real-world software development, where teams rely on modular design and continuous testing to build reliable applications.

1. Version Control with Git

Setting Up Your Repository

Start by creating a local Git repository. Use your surname and student ID in the repository name following the format <Surname>_<ID>_ISErepo. For example, if your surname is Smith and ID is 123456, your repository would be Smith_123456_ISErepo. Initialize the repository with git init and create two directories: code for your source files and documents for your documentation.

Planning Your Branches

Think of branches like parallel universes for your code. For this project, you might create a main branch for stable releases and a develop branch for ongoing work. Feature branches like feature/add-unit or feature/test-cases allow you to work on specific tasks without breaking the main code. Merge them back into develop once completed. This approach mimics how professional teams manage projects, similar to how a game development studio might branch off to prototype a new mechanic while the main game remains playable.

Making Meaningful Commits

Commit often with descriptive messages. Instead of 'fix stuff', write 'Add Unit class with name and ID validation'. Each commit should represent a logical unit of work. For example, after creating the Unit module, commit with message 'Implement Unit module with display methods'. This practice helps you and others understand the project history.

2. Modularity: Designing Your Modules

Identifying Modules

Based on the scenario, the main entities are Unit, Class, and Student. Each should be a separate module. Additionally, you need a Validator module for input validation and a DataManager module to handle adding/removing entities. This separation follows the principle of high cohesion (each module has a single, clear purpose) and low coupling (modules interact through simple interfaces).

Module Descriptions

For each module, define its name, inputs, outputs, and task. For example:

  • Unit: Inputs – unit ID, name, UC name, contact. Outputs – display methods. Task – store and display unit information.
  • Class: Inputs – class name, teacher, contact, time, list of students. Outputs – display methods. Task – manage class data.
  • Student: Inputs – student ID, name, contact, enrolled classes. Outputs – display methods. Task – manage student data.
  • Validator: Inputs – data to validate. Outputs – boolean or error messages. Task – validate IDs, names, contact details.
  • DataManager: Inputs – commands (add/remove) and data. Outputs – updated collections. Task – orchestrate CRUD operations.

Design Decisions

Use different input/output methods across modules to demonstrate testing flexibility. For instance, the Validator could take keyboard input for a console-based test, while the DataManager reads from a text file. This aligns with the assignment requirement to test various I/O methods. Also, ensure your modules are reusable; for example, the Validator could be used by both Unit and Student modules.

3. Testing: Black-Box and White-Box

Black-Box Testing

Black-box testing focuses on inputs and outputs without looking at internal code. Design test cases for each module. For the Validator, test valid and invalid unit IDs (e.g., 'CS101' vs. empty string). For the Unit module, test that display methods output the correct format. This is like testing a mobile app by tapping buttons without caring how the code works.

White-Box Testing

White-box testing examines internal logic. For the Validator, ensure that all branches (e.g., if-else for ID length) are executed. Write test cases that cover each path. For example, test a unit ID that is exactly 5 characters, longer, and shorter. This ensures your code handles edge cases.

Implementing Test Code

Write a separate test module that imports your production code and runs test cases. For each test, print whether it passed or failed. For example, test_validator.py could call Validator.is_valid_unit_id('CS101') and assert the result is True. Document your test cases in the documents folder.

4. Putting It All Together

Start by implementing the modules in the code directory. Commit each module as you complete it. Then write test cases and test code. Finally, document your work in the documents directory. Use Git branches to separate these phases: a feature/modules branch for coding, a feature/tests branch for testing, and merge them into develop after review.

Conclusion

By following this tutorial, you will create a well-structured, testable, and version-controlled timetable management system. These practices will serve you well in future software projects, whether you are building a school project or contributing to a popular app like a study planner or a gaming leaderboard. Remember to commit early and often, keep your modules focused, and test thoroughly. Good luck with your ISEN1000 assignment!