UML & Object-Oriented Programming

A trading system is a system of objects — so model it on paper before you model it in Python, and the design mistakes cost you minutes instead of weeks.

• Name the four pillars of OOP and point at each one inside the AlgoArena codebase.
• Draw a UML class diagram with correct inheritance, composition, association and dependency arrows.
• Write a Level-1 bot by subclassing the arena.Trader ABC and implementing one method.

1What is object-oriented programming?

Start with the problem, not the vocabulary. A trading bot is a small program that changes very quickly, runs unattended, and spends real money every time it is wrong. Object-oriented programming is a set of tools for keeping that kind of program honest: each fact in one place, each piece behind a contract, and the same code running in a test, a backtest and the live arena.

1aWhat OOP solves, as a software-engineering problem

Six problems that every growing codebase hits. Each card gives the symptom, what it costs in a trading system, and the OOP tool that removes it. You will see all six fire in the bot below.

1bHow bad can it get? One morning with a procedural bot

On the left is a realistic 42-line bot of the kind that "worked yesterday": globals, orders as raw dicts, the position updated in two places, a strategy pasted for a second symbol before a fix, the fee written twice, and a bare except that "keeps the bot alive". On the right is the same strategy with the same rules, written as objects on the arena SDK. It is not shorter: the difference is that each fact lives in exactly one place. Both files run: we replayed the same eight ticks through a venue that validates orders with the arena's real PlaceOrder schema, and every number below is that run's output.

# bot.py — "it worked yesterday"TEAM, MAX_POS = 'team07', 200        # max shares per symbolpos = {}                             # global: anyone can write itcash = 100_000.0hist = {'AAPL': [], 'NVDA': []}ws = None                            # live socket, set at startup def send(sym, side, qty, px):    global cash    ws.send({'type': 'place_order', 'team_id': TEAM,             'symbol': sym, 'side': side, 'order_type': 'limit',             'price': px, 'quantity': qty})       # raw dict    sgn = 1 if side == 'buy' else -1    pos[sym] = pos.get(sym, 0) + sgn * qty    cash -= sgn * qty * px + 0.001 * qty * px def on_message(msg):                 # everything the venue says    try:        if msg['type'] == 'trade_execution':            q = msg['quantity']            if msg['seller_id'] == TEAM:                q = -q            pos[msg['symbol']] = pos.get(msg['symbol'], 0) + q        elif msg['type'] == 'error':            print('REJECTED', msg['reason'])  # it is 'message'    except:                          # "keeps the bot alive"        pass def momo_aapl(px):                   # fixed Tuesday    h = hist['AAPL']; h.append(px); p = pos.get('AAPL', 0)    if len(h) > 1 and h[-1] > h[-2] and p + 100 <= MAX_POS \            and cash > 100 * px * 1.0015:        send('AAPL', 'buy', 100, px)    elif len(h) > 1 and h[-1] < h[-2] and p > 0:        send('AAPL', 'sell', p, px)          # exit everything def momo_nvda(px):                   # pasted Monday, before the fix    h = hist['NVDA']; h.append(px); p = pos.get('NVDA', 0)    if len(h) > 1 and h[-1] > h[-2]:        send('NVDA', 'buy', 100, px)    elif len(h) > 1 and h[-1] < h[-2] and p > 0:        send('NVDA', 'SELL', p, px)

from abc import ABC, abstractmethodfrom arena import Trader, Signal class FeeModel:                      # the one place fees live    def __init__(self, taker: float = 0.0015) -> None:        self.taker = taker    def all_in(self, qty: int, px: float) -> float:        return qty * px * (1 + self.taker) class Strategy(ABC):                 # the contract for every signal    @abstractmethod    def side(self, prices: list[float]) -> str | None: ... class Momentum(Strategy):            # one class, one per symbol    def side(self, prices: list[float]) -> str | None:        if len(prices) < 2 or prices[-1] == prices[-2]:            return None        return 'buy' if prices[-1] > prices[-2] else 'sell' class Risk:                          # one rule set, every symbol    def __init__(self, max_pos: int, lot: int, fees: FeeModel):        self.max_pos, self.lot, self.fees = max_pos, lot, fees    def size(self, side, held: int, cash: float, px: float) -> int:        if side == 'sell':            return max(held, 0)      # exit what the venue holds        q = min(self.lot, self.max_pos - held) if side else 0        ok = q > 0 and cash >= self.fees.all_in(q, px)        return q if ok else 0 class MyBot(Trader):    def __init__(self, strategies: dict[str, Strategy], risk: Risk):        self.strategies, self.risk = strategies, risk    def on_tick(self, market, portfolio) -> Signal | None:        for sym, strat in self.strategies.items():            px = market.mid_price(sym)            if px is None:           # no book yet: sit out                continue            held = portfolio.positions.get(sym, 0)  # venue's number            side = strat.side(market.prices(sym))            qty = self.risk.size(side, held, portfolio.cash, px)            if qty:                  # validated here, in-process                return Signal(symbol=sym, side=side,                              quantity=qty, price=px)        return None bot = MyBot({'AAPL': Momentum(), 'NVDA': Momentum()},            Risk(max_pos=200, lot=100, fees=FeeModel()))

1cWhy this matters when you talk to a bot

"Bot" means two different things in this course, and structure matters to both of them: (a) your trading bot talks to the exchange, and (b) you may talk to an AI coding assistant about your bot.

from pydantic import ConfigDict, ValidationErrorfrom shared.messages import PlaceOrder   # venue's schema try:    PlaceOrder(team_id='team07', symbol='AAPL', side='BUY',               order_type='limit', price=185.40, quantity=5)except ValidationError as e:    print(e.errors()[0]['msg'])    # Input should be 'buy' or 'sell' o = PlaceOrder(team_id='team07', symbol='AAPL', side='buy',               order_type='stop', price=180.0, quantity=5,               stop_prise=181.0)   # typo, OPTIONAL fieldprint(o.stop_price)                # None: silently ignored class StrictOrder(PlaceOrder):     # opt in to strictness    model_config = ConfigDict(extra='forbid')try:    StrictOrder(**o.model_dump(), stop_prise=181.0)except ValidationError as e:    print(e.errors()[0]['msg'])    # Extra inputs are not permitted ws.send(o.model_dump_json())       # JSON from the model only

1dNow the vocabulary: objects

Look at a market and you see nouns. An order with a side and a price. An order book that holds orders and matches them. A portfolio that owns cash and positions. A strategy that turns prices into intentions. Object-oriented programming is simply the decision to make each of those nouns a thing in your program that keeps its own state and knows how to behave.

class Order:
    exchange_fee = 0.001          # class attribute (shared)

    def __init__(self, symbol, side, qty, price):
        self.symbol = symbol      # instance attributes
        self.side   = side        # (per-object state)
        self.qty    = qty
        self.price  = price

    def notional(self):           # a method (behaviour)
        return self.qty * self.price

o = Order('AAPL', 'buy', 5, 185.50)  # an instance
o.notional()   # -> 927.5

Interactive · the four pillars, each one live in the arena

Every OOP concept reduces to these four ideas. Pick one; the diagram and the code change with it.

class Portfolio:
    def __init__(self, cash):
        self.cash = cash          # public
        self._positions = {}      # _protected (convention)
        self.__ledger = []        # __private (name-mangled)

    @property
    def net_worth(self):          # computed, read-only
        return self.cash + self._mark_positions()

p.net_worth        # attribute access, runs the method
p.net_worth = 10   # AttributeError — no setter

# what you write — the whole surface area
from arena import Trader, Signal

class MyBot(Trader):
    def on_tick(self, market, portfolio):
        ask = market.best_ask('AAPL')
        return Signal('AAPL', 'buy', 1, ask) if ask else None

MyBot().run()      # sockets, auth, retries: not your problem

class Strategy:
    def __init__(self, name):
        self.name = name
    def signal(self, prices): ...      # base behaviour

class Momentum(Strategy):              # Momentum IS-A Strategy
    def __init__(self, name, lookback):
        super().__init__(name)         # call parent __init__
        self.lookback = lookback
    def signal(self, prices):          # specialise
        return prices[-1] - prices[-self.lookback]

def run_all(bots, market, portfolio):
    for bot in bots:                    # each bot is a different class...
        sig = bot.on_tick(market, portfolio)   # ...same call, different logic
        if sig: submit(sig)

run_all([Momentum(...), MeanReversion(...), MLBot(...)], mkt, pf)

# pinned down by a contract:
from abc import ABC, abstractmethod
class Trader(ABC):
    @abstractmethod
    def on_tick(self, market, portfolio): ...
Trader()      # TypeError: can't instantiate abstract class

2How does UML work? Build the diagram yourself

A UML class box is three compartments: name, attributes, methods. + is public, - is private, # is protected, and a dashed border marks an abstract class. The arrows are where the design actually lives — they say how objects know about, use, and own one another.

Interactive · UML class-diagram builder

Add classes from the palette, pick a link type, then click two boxes in the diagram (source first, target second) — or use the two dropdowns if you prefer the keyboard. The diagram, the generated Python skeleton and the design review all redraw as you go.

# add classes to see the code

from abc import ABC, abstractmethod

class Trader(ABC):
    @abstractmethod
    def on_tick(self, market, portfolio):
        ...            # every subclass MUST implement this

class MyBot(Trader):
    def on_tick(self, market, portfolio):
        return Signal('AAPL', 'buy', 5, market.best_ask('AAPL'))

Trader()      # TypeError: can't instantiate abstract class
MyBot()       # OK — the contract is satisfied

from dataclasses import dataclass

@dataclass
class Trade:
    symbol: str
    price: float
    quantity: int
    aggressor: str

t = Trade('AAPL', 185.5, 5, 'buy')   # __init__ free
print(t)   # Trade(symbol='AAPL', price=185.5, ...)

3Why does this matter in trading?

Because the interface is the thing you keep and the strategy is the thing you throw away. Over nine weeks you will write and delete a dozen signals. If every one of them is a Strategy behind the same signal() call, swapping them is a one-line change and you can run them side by side on the same price path. If each one is welded into your socket loop, you get one shot per week.

Interactive · four strategies, one interface, one price path

All four bots below implement the identical signal(prices) -> float contract, so the runner code is a single loop that does not know which class it is holding. Press play and watch the P&L diverge — same market, same plumbing, different edge. Each position change pays the half-spread plus the 0.0015 taker fee, so churn is not free.

# the runner — polymorphic, and it never changes
for t in range(240):
    for bot in bots:            # 4 different classes
        target = bot.signal(px[:t+1])
        trade_to(bot, target)   # pays spread + fee

Interactive · coupling versus the cost of change

This is the same argument in money. Suppose your bot reaches directly into n pieces of plumbing — the socket, the parser, the fee table, the book. Every pair of those things can now break each other, so the wiring you have to reason about grows as n(n+1)/2. Route the same access through one interface and it grows as n. Drag the slider.

4Five ways this goes wrong

Every one of these has been marked down in a real Week-1 deliverable. Open them.

5Check yourself

Three questions, instant feedback, nothing recorded.

6Do the work