Types of Applications

• In Lab-01 your team wrote the problem statement for ITC Club Hub and listed its stakeholders. Before we write requirements (Chapter 05) we must decide what kind of software it is.
• Students use phones anywhere on campus; organisers check people in at the door of a room with weak Wi-Fi; administrators prepare reports on a desktop.
• The type of application decides three things early: where the code runs (architecture), which qualities matter most (availability, speed, security...), and how the software reaches users (browser, app store, installer).
• Changing the type late is expensive: it is close to a rewrite of the user-facing part.

• System software runs and manages the computer itself and offers services to other programs: firmware, the operating system kernel, device drivers, runtimes, compilers and utilities.
• Application software helps a person or an organisation do a task: chat, learning, banking, games, Club Hub.
• Each layer only talks to the layer below through a defined interface: an application calls the OS through system calls (open a file, send a packet); the OS talks to hardware through drivers.
• System software must be fast, small and extremely reliable, because every application above it depends on it. That is why it is mostly written in C, C++ and, more and more, Rust.

• Desktop application: installed on the user's computer; interface, logic and often the data all run locally. Works offline and uses the full hardware. Updates need an installer or an update service. Examples: VS Code, a spreadsheet, most PC games.
• Web application: runs in a browser; nothing to install. The server holds the logic and the shared data, so one deployment updates every user at once. Needs a network. Examples: Moodle, web mail.
• Mobile application: installed on a phone, usually from an app store. Uses the camera, GPS and push notifications, keeps a local cache, and talks to a back-end API over a network that comes and goes. Examples: Telegram, a banking app.
• Many products are all three at once, sharing one back end: Telegram has desktop, web and mobile clients.

• An information system is people, processes, data and software that together support an organisation, for example a university's student information system.
• ERP (enterprise resource planning) is a suite of integrated modules (finance, HR and payroll, procurement, inventory) that share one database, so a purchase immediately appears in the accounts. Examples: SAP S/4HANA, Odoo.
• CRM (customer relationship management) tracks leads, customers, sales and support tickets. Example: Salesforce.
• Typical traits: hundreds of users with roles and permissions, audit trails, a life of 10 to 20 years, and more integration and configuration work than new code.
• Dominant qualities: security, data integrity, interoperability, maintainability.

flowchart TD
  WEB[Online shop] -- orders via API --> CRM[CRM: customers, sales, support]
  CRM -- confirmed order --> INV
  CRM -- customer master data --> FIN
  subgraph ERP[ERP suite: one shared database]
    INV[Procurement and inventory] -- goods delivered, invoice --> FIN[Finance and accounting]
    HR[HR and payroll] -- salary costs --> FIN
  end
  HR -- staff accounts --> IAM[Directory and single sign-on]
  FIN -- nightly export --> BI[(Data warehouse and dashboards)]
  INV -- stock levels --> BI

• A cloud application runs on rented, elastic infrastructure: capacity grows and shrinks with demand, and you pay for what you use.
• SaaS products are multi-tenant (one installation serves many customer organisations, each isolated), paid by subscription and updated continuously.
• Short calculation (illustrative prices): a small VM at 0.02 USD per hour runs 730 hours a month: 0.02 × 730 = 14.60 USD per month, with no hardware to buy.

flowchart TD
  A[Sources: apps, sensors, logs] --> B[Ingest: batch or stream]
  B --> C[(Storage: database, data lake)]
  C --> D[Process: clean, join, aggregate]
  D --> H[Reports and dashboards]
  D --> E[Train and evaluate a model]
  E --> F[Serve the model behind an API]
  F --> G[App feature: search, recommendation, chat]
  G -. usage data .-> A
  F -. monitor accuracy and drift .-> E

• A data-intensive application is limited by the amount, speed or variety of its data rather than by CPU: a bank ledger, a video platform's view counts, a university's exam results over 20 years.
• An AI-enabled application has behaviour learned from data instead of written as rules. Its output is probabilistic, so it needs evaluation data, monitoring after release and a fallback when the model is wrong.
• Dominant qualities: scalability, data quality, privacy, explainability, cost of computing.

• Client-server: many clients send requests; one shared server answers. Clients start the conversation; the server owns the shared data. Web, mobile and most enterprise systems work this way.
• Three-tier splits the server side further:
  • presentation: shows data and collects input (browser page, mobile screen, CLI);
  • application (logic): business rules and workflows;
  • data: stores and retrieves data (database, files).
• Each tier talks only to its neighbour. You can replace the presentation (add a mobile app) or the data store (CSV to a database) without touching the rules.
• Tier usually means a separately deployed part (another machine or process); layer means a logical part of the code. A C++ program can have three layers in one process.

quadrantChart
  title Quality demands by application type
  x-axis Low timing demand --> High timing demand
  y-axis Low availability demand --> High availability demand
  quadrant-1 Critical and fast
  quadrant-2 Always on
  quadrant-3 Best effort
  quadrant-4 Fast but tolerant
  ABS controller: [0.93, 0.93]
  Online banking: [0.55, 0.88]
  ERP: [0.35, 0.75]
  Moodle: [0.3, 0.62]
  Club Hub check-in: [0.62, 0.55]
  Mobile game: [0.82, 0.3]
  Text editor: [0.2, 0.15]
  Batch analytics: [0.3, 0.35]

• Placing products on two axes makes a discussion concrete: "is our check-in really as critical as online banking?"
• Club Hub check-in sits in the middle: a queue at the door is annoying, not dangerous, but it happens at a known peak moment (the start of an event).
• Moodle needs high availability during exam weeks but little timing precision; a mobile game needs smooth frames but may be offline for maintenance.
• Positions are judgements, not measurements. The next slide turns a judgement into a testable statement.