75 lines
4.1 KiB
Markdown
75 lines
4.1 KiB
Markdown
|
---
|
||
|
|
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]]
|