System Modeling with Unified Modeling Language (UML)

System Modeling & UML Overview

This document summarizes key concepts from our System Modeling with UML lecture and shows how we can apply them to the Affordable & Healthy Eating Hub project. By defining system boundaries, actors, interactions, and internal structures, we can better understand and communicate our overall system design.

---

1. Why System Modeling?

System modeling uses abstract representations (models) to describe:

• The system context and environment (what is inside vs. outside),
• The way different parts of the system interact,
• The structure of data and components in the system,
• The behavior of the system and its responses to events.

Benefits for our Affordable & Healthy Eating Hub:

• Clarifies project scope (what features are inside our platform, and what external services we might integrate),
• Helps the team and stakeholders (dietitians, store owners, developers, testers) understand and discuss requirements,
• Serves as a reference during development for verifying features.

---

2. Overview of UML Diagrams

UML (Unified Modeling Language) offers several diagram types. Here are the ones we are most likely to use:

1. Context Diagram (informal or UML-based)

   • Shows high-level boundaries and external systems.

2. Use Case Diagram (behavioral/interaction)

   • Illustrates interactions between actors (people or other systems) and the system.

3. Class Diagram (structural)

   • Depicts classes, attributes, and relationships (associations, inheritance, etc.) among classes.

4. Sequence Diagram (interaction)

   • Details object interactions over time for a specific use case or scenario.

5. Activity Diagram (behavioral)

   • Shows process flows, decisions, and concurrency (fork/join).

6. State Diagram (behavioral)

   • Portrays the states a system or component can be in, and transitions between those states.

Below, we describe each diagram briefly and provide examples relevant to our project.

---

3. Context Diagram (System Boundaries)

A context diagram illustrates the system as a single box (our platform) and the external entities with which it interacts. This helps define what’s inside (Affordable & Healthy Eating Hub) and what’s outside (e.g., external payment gateways, local store APIs).

Example (informal notation):

In our case, major external actors might be:

• User (general consumer, dietitian, store owner),
• Local Grocery API (if we decide to fetch real-time pricing),
• External Payment Gateway (if we handle online payments).

---

4. Use Case Diagram

A Use Case Diagram describes what the users (actors) can do with the system and which features the system provides in response. It’s especially helpful during requirements elicitation.

Key Actors for Our Project

• General User: Can search recipes, view meal plans, create shopping lists.
• Dietitian: A special user who can post nutrition tips, share verified advice.
• Store Owner: A user who lists products (grocery options) and manages inventory.

Sample Use Case Diagram

Each use case can be further detailed with a Use Case Description:

• Actor: Who is involved.
• Description: High-level overview of the task.
• Stimulus: Trigger event (e.g., user clicks “Search”).
• Response: System response (e.g., displays matching recipes).
• Comments: Additional notes or constraints.

---

5. Class Diagram (Structural Model)

A Class Diagram shows the static structure of the system by detailing classes, their attributes, and their relationships.

Example Classes & Relationships

A possible conceptual diagram for some core entities:

• User

  • Attributes: username, email, passwordHash, allergies, etc.
  • Relationships: can create Post items.

• Post (general forum post)

  • Attributes: postID, content, creationDate, etc.

• Recipe inherits from Post

  • Additional Attributes: list of Ingredients, steps, cost breakdown, nutrition info.

• Dietitian, Store Owner might be specialized types of User.

• Ingredient

  • Attributes: name, nutritionScore, cost, etc.

---

6. Sequence Diagram (Interaction Model)

A Sequence Diagram focuses on how objects (or actors) interact step by step over time. It’s especially useful for showing the flow of data for specific use cases.

Example: User Creating a Meal Plan

1. User selects “Create Meal Plan.”
2. System fetches user’s allergies and budget.
3. System suggests possible recipes.
4. User finalizes selections and saves the meal plan.

A textual representation might look like this:

---

7. Activity Diagram (Behavioral Process)

An Activity Diagram describes a flow of actions, decisions, and possible parallel steps.

Example: Posting a Recipe

---

8. State Diagram (Event-Driven Behavior)

A State Diagram shows how an entity moves between states based on events. For example, a Post might transition from Draft → Published → Reported → Removed or Resolved.

Simplified Post Lifecycle

9. Practical Tips for the Team

1. Decide on a Modeling Scope

   • We don’t need to model everything. Focus on critical or complex processes, like meal planning or inventory management.

2. Keep Diagrams Understandable

   • Use short labels, limit diagram size, and add textual explanations.

3. Refine Diagrams Iteratively

   • Start with high-level overviews and add details (e.g., method calls, data flows) over time.

4. Update the Glossary

   • Refer to the Glossary page for consistent terminology (e.g., “Recipe,” “Nutrition Score,” “Grocery Option,” “Allergy”).
   • Continue adding or revising terms as the system evolves to ensure alignment within the team.

---

10. Conclusion

Modeling the Affordable & Healthy Eating Hub using UML diagrams helps our entire team—from developers to dietitians—visualize the system’s structure and behavior. These diagrams serve as a blueprint for discussing requirements, refining designs, and ensuring everyone has a shared understanding of how features fit together.

If you have feedback or terms that need further explanation, please contribute to the Glossary section in our repository. After review and final approval, we will integrate the glossary into the main requirements page.