How irani-ewu/trello_project_management_system_c works
1. This repository is a small, single-process C application that models a Trello-style project management system for a data structures course. The architecture is centered on in-memory linked lists rather than files, databases, or network services.
2. The system is split into a few clear modules:
• main.c as the program entry and top-level coordinator
• user_entry.c/.h for user interaction and command/input handling
• cards.c/.h for card/task-related behavior
• search.c/.h for lookup and retrieval operations
• lists.c for the linked-list container logic and list management
3. The core data model is likely built around linked-list nodes representing project entities such as lists/columns and cards/tasks. The README explicitly says linked lists are the base data structure, so the main architectural boundary is between the console interaction layer and the in-memory list structures.
4. main.c is the orchestration layer. It probably initializes the system state, displays the main menu, and routes user choices into the feature modules. In the diagram, this is the control center that connects input handling to the underlying data structures.
5. user_entry.c acts as the presentation/input boundary. Its role is to collect user commands and fields, validate or normalize them, and pass them into the operational modules. This keeps interactive prompting separate from the actual list/card manipulation logic.
6. cards.c encapsulates card-level operations. In Trello terms, this is where a task/card is created, updated, moved, displayed, or removed. This module should be treated as the business-logic layer for individual work items.
7. lists.c is the main data-structure module. It likely owns the linked-list implementation and the operations that add, remove, traverse, or reorganize project lists/columns and their contained cards. This is the structural backbone of the system.
8. search.c provides lookup functionality across the in-memory model. It is the navigation layer that helps find a card/list/user entry by name, ID, or other key, then returns a pointer or reference for the caller to operate on. In an architecture diagram, it connects UI requests to the data structure traversal paths.
9. The header files (cards.h, search.h, user_entry.h) define the public interfaces between modules. They are the contract points that keep each C file focused and reduce coupling between the UI layer, search utilities, and card/list logic.
10. The data flow is straightforward: user input enters through user_entry, main dispatches the request, the relevant feature module (cards or lists) mutates the in-memory linked lists, and search is used whenever the operation needs to locate an existing entity before updating it. Results are then presented back to the user through the console.
11. There is no evidence of persistence, server communication, or third-party infrastructure in the repository. That means the architecture diagram should show a local CLI application with transient in-memory state, not a client-server or database-backed system.
12. For an accurate diagram, represent the main boundary as:
• Console user
• Input/menu handling
• Operation modules (cards, lists, search)
• Linked-list based in-memory project data
with main.c sitting above these modules as the execution coordinator.
Main entry points: main.c main.c · cards.c cards.c · lists.c lists.c · search.c search.c
Components 12
Presentation
Console entry and user interaction boundary
- Console user · Person interacting with the CLI
- main.c · Program startup and top-level control flow
main.c - user_entry.c · Prompts, reads, and normalizes user commands
user_entry.c - user_entry.h · Public contract for input handling routines
user_entry.h
Operations
Feature modules that coordinate card, list, and lookup behavior
- cards.c · Create, update, move, display, and remove cards
cards.c - cards.h · Public contract for card operations
cards.h - lists.c · Linked-list management for lists and contained cards
lists.c - search.c · Finds lists, cards, or other entities in memory
search.c - search.h · Public contract for search helpers
search.h
In-memory Data
Linked-list based project state
- Project state · Transient linked-list representation of the Trello-style system
- List nodes · Linked-list elements representing columns or lists
- Card nodes · Linked-list elements representing tasks or cards
Connections 18
- Console user → user_entry.c: commands · User provides menu choices and fields
- user_entry.c → main.c: dispatch · Collected input is handed to the program coordinator
- main.c → cards.c: route · Main routes card-related actions to the card module
- main.c → lists.c: route · Main routes list-management actions to the list module
- main.c → search.c: route · Main invokes lookup helpers when an operation needs a target
- main.c → Project state: owns · Main coordinates the transient in-memory application state
- user_entry.c → user_entry.h: exposes · Input routines are declared through the header
- cards.c → cards.h: exposes · Card operations are declared through the header
- search.c → search.h: exposes · Search helpers are declared through the header
- cards.c → search.c: finds · Card actions use search to locate existing entities
- lists.c → search.c: finds · List operations use search for traversal and retrieval
- cards.c → Project state: mutates · Card changes update the in-memory model
- lists.c → Project state: mutates · List structure operations update the in-memory model
- Project state → List nodes: contains · The project is built from linked list containers
- Project state → Card nodes: contains · Each list contains card/task nodes
- List nodes → Card nodes: links · List nodes reference contained cards in the chain
- cards.c → Card nodes: operates on · Card logic manipulates card nodes directly
- lists.c → List nodes: operates on · List logic manipulates list nodes directly