IntaliqSE322
SE322 · Software Design & Architecture · Section 1340

Intaliq

The architecture of an outdoor fitness app for Saudi Arabia, designed with the 4+1 View Model.

Instructor
Dr. Suad Ramouni
Prepared by
Yara AlbugamiRose Al RakanShoug AlomranFajr AlghofailiMozoun AlmuqrinMunira Alfaris
Outline

What we'll cover

From the problem Intaliq solves to the architecture behind it, the design patterns that shape the code, and how we validated the design.

01
Deliverable 1 · 40%

Software Architecture Design

Submitted 30 Sep4+1 View Model
8SAD sections
5architectural views
11UML diagrams
3use-case scenarios
SAD 1.1 · Overview

Getting active outdoors is harder than it should be

Monitoring outdoor activity

Few tools accurately track how active people are outdoors.

Finding partners

Many struggle to find someone to join their preferred activity.

Joining group sessions

Large, professionally led group events are hard to find in Saudi Arabia.

Vision 2030 · Quality of Life targets
Population exercising weekly
13% 40%
Average life expectancy
74 80 yrs

Physical activity is key to reducing chronic disease — Intaliq helps citizens adopt a more active, healthier lifestyle.

SAD 1.2 · Purpose

Make running, cycling and hiking accessible and enjoyable

Intaliq is a mobile fitness app. Users track daily activity, set goals and join group sessions held daily by a trained team of coaches, through a simple design that makes outdoor activity feel less intimidating.

01

Easy navigation

Guide users through outdoor activities in Saudi Arabia with an easy-to-use interface.

02

Accurate tracking

Provide reliable tools for monitoring activity and setting activity goals.

03

Social connection

Connect people across Saudi Arabia who share an interest in outdoor activity.

SAD 1.3 · Scope

Eight features, two roles

A smartphone app that raises the accessibility, motivation and social side of outdoor fitness through tracking, connections and organised sessions.

User

Activity tracking

Log daily outdoor activities and track improvement.

User

Goal setting

Set and adjust activity goals to monitor progress.

User

AI analysis

Chat with an AI chatbot for an overview or goal tweaks.

User

Finding partners

Chat and pair up with partners to stay motivated.

User

Join group sessions

Running, hiking and cycling crews hosted by Intaliq coaches.

Coach

Create sessions

Create and schedule new group sessions.

Coach

Admit members

Accept applicants whose goals and level match the session.

Coach

Announce updates

Notify members ahead of time about session changes.

SAD 1.4 – 1.5 · Definitions & References

The data dictionary behind every view

Session class

date
DD/MM/YYYY, realistic
time
24-hour clock
location
In KSA, permitted for groups
capacity
> 1, fits the venue
intensity
Beginner · Intermediate · Advanced

User class

firstName
< 20 characters
lastName
< 35 characters
phone
+966 5X-XXX-XXXX or country code
email
Recognised domain, handle < 64
password
≥ 8, upper case, number, symbol

Coach class

name
First and last < 20 characters
phone
Same rules as User
email
Same rules as User
password
Same rules as User

Goal class

type
Hiking · Biking · Running
targetTime
HH:MM
calories
> 10 kCal
deadline
DD/MM/YYYY, not in the past

Partner class

location
In KSA, permitted for groups
goals
One of the three activities
activities
Hiking · Biking · Running

Activity class

type
Hiking · Biking · Running
duration
5 minutes to 1 day
1.5 References Intaliq Vision & Scope Document IEEE SRS Template Intaliq 2.0 SRS · SE311 v1.0
SAD 2 · Architectural Representation

The 4+1 View Model

Philippe Kruchten (1995). Users, coaches and developers each see Intaliq differently, so the architecture is split into four views, tied together by scenarios — the “+1”.

Logical View End users · functionality Development View Programmers · modules Process View Integrators · runtime Physical View Engineers · topology Scenarios User View · “+1”
+1 · User View

Use-case diagram and three scenarios

Logical

Class diagram and five sequence diagrams

Process

Two activity diagrams — user and coach

Development

Component diagram with interfaces

Physical

Deployment diagram — device, server, database, AI

SAD 3 · Architectural Goals & Constraints

What the architecture must protect and respect

Goals

Easy-to-use mobile interface

Encourage Saudi citizens to be active and connect through sport, without friction.

Protected user accounts

Keep user information safe — its integrity and its confidentiality.

Constraints

Language

JavaScript, building on the prototype stack: HTML, CSS, Vite, Supabase, Vercel.

Time

Four fixed milestones between 30 Sep and 4 Nov 2026.

Cost

Limits the services and hosting the app can rely on.

SAD 4.1 · User View · Use-Case Realization

Two actors, nine use cases

Intaliq use-case diagram with User and Coach actors

User

6 use cases
  • Log in
  • Log activity
  • Set activity goal
  • Perform AI analysis
  • Find partners
  • Join group sessions

Coach

3 use cases
  • Create session
  • Admit users
  • Announce updates
SAD 4.1 · User View · SE365 Prototype

The use cases, on screen

User home screen with weekly stats
HomeDashboard
Log activity screen
Use caseLog activity
Set your first goal screen
Use caseSet activity goal
Sessions list with request-to-join buttons
Use caseJoin group sessions
AI Coach chat screen
Use caseAI analysis
Profile with friends and requests
Use caseFind partners
Coach dashboard with session stats and quick actions
HomeCoach dashboard
Coach's list of sessions with pending requests
OverviewMy sessions
Create group session form
Use caseCreate session
Admissions screen with Admit buttons
Use caseAdmit users
Session detail with admission requests and announcement box
Use caseSession detail
Make announcement form
Use caseAnnounce updates
SAD 4.2 · Scenarios

Three scenarios, end to end

Actor

User

Stimulus

User selects and books a session

Response

Request submitted; user added if the coach accepts, notified if not

Normal scenario
  1. Open the Intaliq app
  2. Log in
  3. Browse available group sessions
  4. Select a session
  5. Review session and coach details
  6. Submit a booking request
  7. Coach reviews the request
  8. Coach accepts the request
  9. System confirms and notifies the user
Alternative scenarios
Not logged in → login pop-up
Session full → request blocked with a pop-up
Coach rejects → user is notified
System error → request not completed, user notified
Actor

User

Stimulus

User sends a query in the AI chat

Response

The AI answers and suggests further help

Normal scenario
  1. Open the Intaliq app
  2. Log in
  3. Select the “More” tab
  4. Select AI Chatbox
  5. Pick a suggested prompt or write one
  6. Submit the message
  7. AI coach answers the query
  8. User accepts the answer and closes the chat
Alternative scenarios
Not logged in → login pop-up
Medical advice requested → chatbox refuses and ends the chat; only specialists should advise
System error → chat request not completed, user notified
Actor

User

Stimulus

User enters an activity goal

Response

The system confirms the goal has been saved

Normal scenario
  1. Open the Intaliq app
  2. Log in
  3. Select “Activity”
  4. Select “Activity Goal”
  5. Enter the goal — activity type and target
  6. Submit the goal
  7. System validates and saves the goal
  8. System confirms it was created
Alternative scenarios
Not logged in → login pop-up
Missing field → prompted to complete it
Invalid data → error message shown
System error → goal is not saved
SAD 5.1 · Logical View · Class Diagram

Six classes model the domain

Class diagram: Session, User, Coach, Goal, Partner, Activity
Coach → Session

creates, admits into, announces

User → Session

books a group session

User → Goal · Activity

sets goals, logs activities

User · Coach → Partner

find and connect with partners

SAD 5.2 · Logical View · Sequence Diagrams

Five interactions, message by message

Click any diagram to open it full screen.

Log activity
Sequence diagram: logging an activity
Set goal
Sequence diagram: setting an activity goal
Book session
Sequence diagram: booking a group session
Create session
Sequence diagram: creating a group session
Admit members
Sequence diagram: admitting members
SAD 6.1 · Process View · Activity Diagrams

How the work flows at runtime

Setting an activity goal · User
Activity diagram: setting an activity goal
Admitting members · Coach
Activity diagram: admitting members
SAD 7.1 · Development View · Component Diagram

Components and the interfaces between them

Component diagram: mobile application, backend API, backend components and external services

Mobile application

User & coach screens, plus Offline Sync, which holds actions until the device is back online.

Backend API · IBackendAPI (HTTPS)

Account & profile, sessions, activities & goals, partner connections, partner chat, AI chatbox and notifications.

External services

Authentication, cloud database, AI recommendation and push notifications — each behind its own interface.

Partner Chat is only reachable once a Partner Connection exists.
SAD 8.1 · Physical View · Deployment Diagram

Where the software runs

Deployment diagram: smartphone, application server, database, AI service
«device»

User smartphone

Runs the Intaliq mobile app: UI, tracking, booking, goals, AI chat.

«server»

Application server

Intaliq backend: auth, users, activities, goals, sessions, matching.

«database»

Intaliq database

User, coach, activity, goal, session and partner data.

«external service»

AI service

Fitness advice, activity guidance and goal assistance.

Phone → server · HTTPS Server → DB · connection Server → AI · API / HTTPS
02
Deliverable 2 · 20%

Architecture Documentation

Submitted 10 OctQuality attributes · Style
4quality attributes
4measurable scenarios
1architectural style
4style components
D2 1 · Quality Attributes

The four qualities Intaliq is built around

Security

Accounts, logs and personal goals are private. Every user and coach is authenticated and limited to their own functions.

100%
unauthorised attempts rejected

Availability

Users rely on the app to track, book and connect. Failures are reported, and Offline Sync holds actions until reconnection.

100%
queued activities synced

Performance

Checking sessions, logging activity and recording goals should happen without noticeable delay.

95% < 3s
session-list requests

Usability

The goal is motivation: every feature is reachable without complex steps, with alerts confirming each action.

90%
first-time users succeed unaided
D2 2 · Quality Attribute Scenarios

Each quality, made testable

Source

An unauthorised user

StimulusTries to open another user's fitness data without authenticating
Environment
Artifact

Authentication & authorization component

Normal system operation

ResponseVerifies identity and permissions, then denies access
Response measure
100%

of unauthorised attempts in the security test cases rejected

Source

A user whose internet connection fails

StimulusTries to log an activity while offline
Environment
Artifact

Mobile app & Offline Sync component

App running without internet access

ResponseStores the activity locally and syncs it once back online
Response measure
100%

of queued test activities sync after reconnecting, with no data loss

Source

An authenticated user

StimulusAsks to view available group sessions
Environment
Artifact

Mobile app, backend API & database

Normal operation, active connection

ResponseRetrieves the sessions and displays their details
Response measure
95% · 3s

of session-list requests complete within 3 s under normal load

Source

A new Intaliq user

StimulusTries to create a personal fitness goal
Environment
Artifact

Mobile app user interface

Normal app operation

ResponseGuides activity choice, goal entry and saving, then confirms
Response measure
≥ 90%

of first-time test users create a goal without assistance

D2 3.1 & 3.3 · Architectural Style

Client–server, with a central backend

The mobile app is the client. One backend handles authentication, business logic and every call to the database and the AI service.

HTTPS DB connection API · HTTPS CLIENT Intaliq Mobile App Activity logging Goals · Booking Partners · AI chat ⟳ Offline Sync APPLICATION SERVER Intaliq Backend Authentication & authorization User management Activity & goal management Session management Partner matching AI Chatbox integration DATABASE Intaliq DB users · sessions · goals … EXTERNAL AI Service fitness tips · Q&A
D2 3.2 & 3.3 · Justification & Communication

Why this style fits Intaliq

Data centralization

Users, actions, goals and sessions controlled through one backend and database.

Security

Authentication and authorization enforced on the server.

Maintainability

App and backend evolve independently.

Performance

Heavy processing stays on the server; the app focuses on the user.

Integration

Clean exchange with third-party services such as the AI chatbox.

Communication process
  1. User performs an action in the mobile app
  2. App sends the request to the backend over HTTPS
  3. Backend authenticates and processes it
  4. Backend calls the database or AI service if needed
  5. Backend returns the outcome to the app
  6. App shows the result to the user
03
Deliverable 3 · 20%

Software Design Documentation

Issued 25 OctGang of Four patterns
5design concerns
3design views
3design patterns
5new diagrams
SDD 2.2 – 2.3 · Stakeholders & Design Concerns

Every decision answers someone's concern

End users, coaches, developers, testers and maintainers each need something different from the design.

01
Developers · maintainers

Add new activity types without changing existing code

02
End users · coaches

Get timely updates about sessions and booking decisions

03
Developers · product owners

Use external services without depending on one provider

04
Testers

Test each part of the system on its own

05
End users

Keep personal data secure

SDD 2.4 – 2.6 · Architectural Viewpoints

Inside the client, and inside the server

Mobile app · MVC
MVC design diagram: View, Controller and Model inside the Intaliq mobile application

View shows screens, Controller handles actions, Model holds data and calls the backend API — easier to maintain, extend and test.

Backend · Layered
Layered architecture diagram: presentation, business, services, persistence and database layers

Each layer talks only to its neighbour, so changes stay local, the database is reached only through the layers above it, and each layer is tested alone.

SDD 3.1 · Detailed Design

Three Gang of Four patterns, one of each kind

DP-01 · Factory Method · Creational

One logging process, any activity

How it's applied

RunningLogger, HikingLogger and CyclingLogger each override createActivity(). Pick hiking, and the HikingLogger builds a HikingActivity that the logging process uses without knowing its type.

Why Factory Method

Every activity is validated and saved the same way but counts calories differently. A new sport such as padel only needs its own logger and activity class — nothing else changes.

Factory Method class diagram: ActivityLogger with RunningLogger, HikingLogger and CyclingLogger creating RunningActivity, HikingActivity and CyclingActivity
DP-02 · Observer · Behavioural

One change, everyone informed

How it's applied

SessionService is the subject; UserNotification and ReminderService observe it. When a class is cancelled, each observer reacts on its own — one alerts the user, the other reschedules reminders.

Why Observer

Announcements reach every admitted member, and booking decisions reach the requester (Book a Session). Session never handles delivery, so new channels such as email plug in without changing it.

Observer class diagram: SessionService implements Subject and holds Observers; UserNotification and ReminderService implement Observer
DP-03 · Adapter · Structural

Any AI provider, one interface

How it's applied

ChatboxService only calls AIChatService.sendMessage(). AIServiceAdapter converts the question into the external service's format, sends it over HTTPS, and converts the answer back.

Why Adapter

Provider-specific formats stay out of the chatbox logic. If the external API changes, only the adapter changes; switching provider means writing a new adapter.

Adapter class diagram: ChatboxService uses AIChatService, implemented by AIServiceAdapter, which calls ExternalAIService
04
Deliverable 4 · 20%

Validation & Presentation

ValidatedReview every design decision
SRStraced to every view
SE365usability findings applied
17course requirements checked
Validation · Requirements Coverage

Does the design meet every requirement?

D1 · SAD outline 4+1

1 · Introduction (overview → references)Covered
2 · Architectural representationCovered
3 · Goals & constraintsCovered
4 · User view — use cases + ≥ 3 scenarios3 of 3
5a · Class diagramCovered
5b · Collaboration diagramOptional
5c · Sequence diagrams5 drawn
6 · Process — activity diagrams2 drawn
7 · Development — component diagramCovered
8 · Physical — deployment diagramCovered

D2 · Architecture QA + style

3–4 quality attributes4
Scenarios drawn & documented4
Style chosen, justified, implementedCovered

D3 · Design SDD

≥ 3 design patterns3
Justification for eachCovered
Software Design Document (SDD)Issued

D4 · Validation Review

Design document reviewed & validatedDone
Validation · Review Log

Checked against the SRS and the prototype

Review checklist

Every 4+1 view traced to SRS features FR-01 – FR-07

Done

SE365 prototype usability findings folded into design decisions

Done

Trade-off: security checks vs. unaided first-time goal creation

Done

Peer review of views and patterns with the instructor

Done
Result
  1. All 17 course requirements covered across the four deliverables
  2. SDD patterns checked against the SRS and Deliverables 1–2
  3. Every review item closed
  4. Final presentation — 4 Nov
Intaliq · SE322

Thank you

Questions?

software-architecture.shoug-tech.com