DOCSEARCHbyAlgolia
Submit Docs

AddressBook Level 3 (AB3) Documentation

website·Indexed 29 days ago

https://nus-tic4002-ay2021s2.github.io/website/schedule/

A desktop address book application used for teaching Software Engineering. This documentation includes a User Guide for managing contacts via a command line, a Developer Guide covering system architecture (UI, Logic, Model, and Storage), setup instructions, testing procedures using JUnit 5, and logging configurations using java.util.logging.

Tokens
202.9K
Snippets
350
Records
1.4K
Agent score
69%

What's inside AddressBook Level 3

  2. Overview of Project Duke chatbot requirements

    Project Duke is a personal assistant chatbot designed to help users keep track of tasks. The project is built incrementally through a series of levels. The core functionality involves processing user commands to add, list, and mark tasks as complete. The chatbot should provide a conversational interface, though specific formatting (like horizontal lines or indentation) is optional.

  3. Overview of Design-by-Contract (DbC)

    Design-by-Contract (DbC), a term coined by Bertrand Meyer, is a software design approach that requires defining formal, precise, and verifiable interface specifications for software components. It treats the relationship between a supplier and a client as a formal contract.

  4. Overview of common software architectural styles

    Beyond primary styles like N-tier or Client-Server, other well-known architectural styles include:

    • Pipes-and-Filters: Processes data through a series of elements (filters) connected by pipes.
    • Broker: Used to structure decoupled applications, where components interact via a broker.
    • Peer-to-Peer (P2P): A decentralized network where participants act as both clients and servers.
    • Message-Oriented/Message-Driven: Systems that communicate by sending and receiving messages.

  5. Overview of TIC4002 Software Engineering Practicum

    TIC4002 is a Software Engineering practicum module designed to strengthen practical SE skills by working with existing codebases (brownfield projects). It builds upon the foundations of TIC2002 and TIC4001. The module consists of two primary practical phases: first, improving an individual project from TIC4001, and second, participating in a team project where students take over and enhance the AddressBook-Level3 (AB3) project, a generic product of approximately 6 KLoC.

  6. Overview of the Practical Exam (PE) and Dry Run

    The Practical Exam (PE) is a peer-based evaluation designed to assess testing and product evaluation skills. It consists of two main parts: finding and defending bug reports in other software, and defending your own product against reported bugs. To prepare for the graded PE (v1.4), a Practical Exam Dry Run (PE-D) is conducted during the week 11 lecture slot to simulate the process using the latest v1.3 release.

  7. Overview of the TIC4002 Individual Project (iP)

    The TIC4002 Individual Project (iP) is a continuation of the project started in TIC4001. It is based on the generic 'Project Duke' framework. For TIC4002, the project requirements evolve in the following ways: optional increments from TIC4001 may become mandatory, new increments are added, and the grading criteria for full marks are more stringent. Students are encouraged to strengthen any components of the TIC4001 iP that were not implemented to a high standard.

  8. Overview of Software Development Life Cycle (SDLC) stages

    The Software Development Life Cycle (SDLC) is a collective set of stages that software development progresses through. The core stages typically include: requirements, analysis, design, implementation, and testing. Process models provide a 'roadmap' that defines the aims of these stages, the resulting artifacts, and the workflow between them.

  9. Overview of the Practical Exam (PE) and PE Dry Run (PE-D)

    The Practical Exam (PE) is a peer-based acceptance and system testing evaluation designed to increase grading rigor and encourage the development of bug-free software. It consists of two main parts: finding and defending bugs in other students' software, and defending your own product against reported bugs. The PE Dry Run (PE-D) is a non-graded version of this process used for preparation, typically conducted on the latest release of the v1.3 period.

  10. Understand and apply software abstraction

    Abstraction is a technique for managing complexity by establishing a specific level of interest and suppressing lower-level details. The guiding principle is that only details relevant to the current perspective or task need to be considered. Abstraction can be applied repeatedly to reach higher levels of abstraction.

    There are two primary types of abstraction:

    1. Data Abstraction: Abstracting lower-level data items into larger entities (e.g., treating a User object as a single entity while ignoring specific fields like name or date of birth).
    2. Control Abstraction: Abstracting the actual control flow to focus on high-level tasks (e.g., using a print("Hello") function instead of managing the computer's hardware output mechanism).

    General examples of abstraction include OOP classes (abstracting related data and behaviors), software architectures, and UML models.

  12. Understand the two main aspects of software design

    Software design is the creative process of transforming a problem into a solution. It is divided into two primary aspects:

    1. Product/External Design: Focuses on designing the external behavior of the product to ensure it meets user requirements. This process typically involves product designers, business analysts, UX experts, and user representatives.
    2. Implementation/Internal Design: Focuses on how the product will be technically implemented to achieve the required external behavior. This process is typically handled by software architects and software engineers.