---
type: practical
---
### Point: Trying to avoid technical debt

In software development and other information technology fields, technical debt (also known as design debt or code debt) is the implied cost of future reworking because a solution prioritizes expedience over long-term design.


## Assignment explanation

![[assignment_app.canvas|assignment_app]]
![[assignment_organization.canvas|assignment_organization]]

So essentially, each team specifies a module, then they exchange the specifications and start working. Then, each team PRs into each other's repo and we get a working thing.


## Diagramming
Diagramming *is very important* when it comes to communication. Doesn't seem like they ***need*** us to use UML, but I'm gonna learn it anyway.

### C4 model
C4 stands for Context, Containers, Components, and Code.
1. **Context Diagram:**
    - Shows the system being modeled and its interactions with external entities such as users, systems, or services.
    - Provides a high-level overview of the system's purpose and relationships with the outside world.
2. **Container Diagram**:
    - Breaks down the system into high-level containers (e.g., web applications, databases, microservices).
    - Shows how these containers interact with each other and with external systems.
    - Defines technologies used within each container.
    3. **Component Diagram**:
    - Focuses on the components within a container and their relationships.
    - Components represent significant building blocks like classes, libraries, or microservices.
4. **Code** (***UML***):
    - Provides a detailed view at the code level, such as classes, methods, and relationships.

### Key UML Diagram Types

1. **Structural Diagrams**: Describe the static structure of a system.
    - **Class Diagram**: Shows classes, their attributes, methods, and relationships among objects. Fundamental to object-oriented design.
    - **Object Diagram**: Represents instances of classes (objects) at a particular moment.
    - **Component Diagram**: Illustrates the organization and dependencies among software components (e.g., libraries).
    - **Deployment Diagram**: Depicts the physical deployment of artifacts on nodes like servers or devices.
2. **Behavioral Diagrams**: Capture the dynamic behavior of a system.
    - **Use Case Diagram**: Visualizes functional requirements and interactions between users (actors) and the system.
    - **Sequence Diagram**: Shows object interactions arranged in a time sequence.
    - **Activity Diagram**: Represents workflows of stepwise activities and actions.
    - **State Machine Diagram**: Depicts states and transitions of an object throughout its lifecycle.
3. **Interaction Diagrams**: Focus on object interactions.
    - **Communication Diagram**: Focuses on the communication between objects and the associations between them.
    - **Timing Diagram**: Represents timing constraints on object interactions.

#### Relationships
- **Association**: Related but **independent**.
- **Aggregation**: One contains the other, but the **parts can exist independently**.
- **Composition**:  Parts **cannot exist** without the whole.
- **Dependency**: Self-explanatory
- **Realization**: `implements`
- **Generalization**: `extends`

#### Key Components of a Sequence Diagram

1. **Objects/Participants**: These are the entities involved in the interaction, such as classes, components, or subsystems.
    
2. **Lifelines**: A lifeline is a dashed vertical line that represents the passage of time.
    
3. **Activation Bars**: Represent duration an object is active while processing messages
    
4. **Messages**: Arrows between lifelines that show communication between objects. Messages can be of different types:

    - **Synchronous Messages**: Represented by a solid line with a filled arrowhead, indicating a call that waits for a return.
    - **Asynchronous Messages**: Represented by a solid line with an open arrowhead, indicating a call that doesn't wait for a response.
    - **Return Messages**: Dashed arrows that show the return of control or data after a message is processed.

5. **Loops and conditions**: Control flow

![[sequence_diagram.png]]