You will refactor the design from Part (a) so that the formatting behaviour is implemented using

Goal: No if/else/switch may be used to select the message-type behaviour.

Required output format rules:

• Email: EMAIL to <user>: <text>
• SMS: SMS to <user>: <text> (truncate text to 20 characters)
• Push: PUSH to <user>: <optional URGENT><text>

  (if priority ≥ 4, add

  URGENT before the text)

Task:

Complete the code template below by writing the missing class hierarchy.

You must only fill the

#include <iostream>
#include <string>
#include <memory>
#include <array>
using namespace std;
// =====================
// TODO 1: Base class
// =====================
// Create an abstract class named MessageBase with:
// - a virtual destructor
// - virtual string format() const = 0;
// =====================
// TODO 2: Derived classes
// =====================
// Implement these derived classes (each must override format()):
// - EmailMessage
// - SMSMessage
// - PushMessage
//
// Each derived class should store the data it needs (user, text, priority if needed).
// Do NOT store a "kind" field in the polymorphic design.
int main() {
  // Do not change main()
  array<unique_ptr<MessageBase>, 3> msgs = {
    make_unique<EmailMessage>("u100", "Welcome to the system", 2),
    make_unique<SMSMessage>("u101", "Your verification code is 123456", 3),
    make_unique<PushMessage>("u102", "Server maintenance tonight", 5)
  };
  for (const auto& m : msgs) {
    cout << m->format() << "\n";
  }
}

Expected output:

EMAIL to u100: Welcome to the system
SMS to u101: Your verification code
PUSH to u102: URGENT Server maintenance tonight

Constraints (must follow):

• No conditional logic (if/else/switch) is allowed to select the message type behavior.
• No dynamic_cast and no typeid.
• Use the provided array<unique_ptr<MessageBase>> to demonstrate polymorphism.

Part B-1: Relationship Justification (Manual Grading)

For each relationship below, explain your reasoning in one sentence only.

1. Ward – Bed
2. Department – Ward
3. Doctor – Ward
4. SmartHospital – ExternalLab

Constraints:

• One sentence per item

Video Streaming Service (Scenario)

• Service manages multiple Channels. Channels can move between services via licensing changes.
• A Channel owns Episodes; removing a channel removes its episodes.
• LiveEpisode is a specialized type of Episode.
• PlayerApp temporarily uses the DRM_API when starting playback.
• RecommendationRule connects multiple Episodes, but episodes exist independently of recommendations.

Answer the following based on the scenario:

1. What relationship fits Service – Channel?
2. What relationship fits Channel – Episode?
3. What relationship fits LiveEpisode – Episode?
4. What relationship fits PlayerApp – DRM_API?
5. What relationship fits RecommendationRule – Episode?

Select one or more:

In the MediSched system, explain the reasoning behind the relationship between Schedule Appointment and Insurance Verification.

Focus your answer on how these two use cases interact in the system.

Maximum length: 100 words.

Match each version control concept to its correct description.

In the MediSched system, explain the reasoning behind the relationship between Make Payment and the payment-specific use cases.

Focus your answer on how different payment options relate to the overall payment functionality.

Maximum length: 100 words.

In the MediSched system, explain the reasoning behind the relationship between Cancel Appointment and Refund Request.

Focus your answer on when and why a refund request occurs.

Maximum length: 100 words.