UNIVERSITY OF SOUTH AFRICA (UNISA)
College of Science, Engineering and Technology — Computer Science Department
⋄
Assignment 4
Rainfall Tracking Application: Design Patterns, XML, Regular Expressions and Threading
⋄
Module Code: COS3711
Module Name: Advanced Programming
Assignment No.: Assignment 4
Tutorial Letter: 104/0/2026
Semester: Year Module, 2026
Submitted in partial fulfilment of the requirements for Advanced Programming
at the University of South Africa.
, UNISA | COS3711 Advanced Programming — Assignment 4
Question 1: UML Design of the Rainfall Tracking System
The rainfall scenario asks for a container of rain records, each holding a station code, a date and a
millimetre value, together with a mechanism for turning that container into an XML representation
that can be handed to a choice of graph. A client class owns the record and decides which graph
to draw, which points directly at the Strategy pattern: the graph type is an interchangeable algo-
rithm selected at runtime by the client, and the family of graphs shares a common interface so the
client does not need to know which concrete graph it is holding (Gamma et al., 1994:315).
1.1 Partial UML Class Diagram
The design below separates four responsibilities: the RainData class that holds a single reading,
the RainRecord container that aggregates all readings and can produce an XML string, the Graph
interface with its two concrete strategies BarGraph and ColumnGraph, and the Client class that
owns the record, requests the XML, and delegates drawing to whichever graph the user selects.
Client / GUI
− record : RainRecord
− graph : Graph*
+ setGraph(g : Graph*) : void
+ requestGraph() : void
+ addRainData(d : RainData) :
void uses
1
RainRecord
Graph
− readings : QVector<RainData>
+ addReading(d : RainData) : void + draw(xml : QString) : void
+ toXml() : QString
1 ...*
RainData
− station : QString
BarGraph ColumnGraph
− date : QDate
− mm : double
+ draw(xml : QString) : void + draw(xml : QString) : void
+ getStation() : QString
+ getDate() : QDate
+ getMm() : double
Figure 1: Partial UML class diagram for the rainfall tracking application
The diagram shows how data moves through the system. RainData objects are aggregated inside
RainRecord, which is itself held by the Client. The client calls toXml() on its record and passes
the resulting string to whichever concrete Graph the user has chosen through setGraph(), so no
graph class needs to know how the XML was built.
Page 1 of 9
College of Science, Engineering and Technology — Computer Science Department
⋄
Assignment 4
Rainfall Tracking Application: Design Patterns, XML, Regular Expressions and Threading
⋄
Module Code: COS3711
Module Name: Advanced Programming
Assignment No.: Assignment 4
Tutorial Letter: 104/0/2026
Semester: Year Module, 2026
Submitted in partial fulfilment of the requirements for Advanced Programming
at the University of South Africa.
, UNISA | COS3711 Advanced Programming — Assignment 4
Question 1: UML Design of the Rainfall Tracking System
The rainfall scenario asks for a container of rain records, each holding a station code, a date and a
millimetre value, together with a mechanism for turning that container into an XML representation
that can be handed to a choice of graph. A client class owns the record and decides which graph
to draw, which points directly at the Strategy pattern: the graph type is an interchangeable algo-
rithm selected at runtime by the client, and the family of graphs shares a common interface so the
client does not need to know which concrete graph it is holding (Gamma et al., 1994:315).
1.1 Partial UML Class Diagram
The design below separates four responsibilities: the RainData class that holds a single reading,
the RainRecord container that aggregates all readings and can produce an XML string, the Graph
interface with its two concrete strategies BarGraph and ColumnGraph, and the Client class that
owns the record, requests the XML, and delegates drawing to whichever graph the user selects.
Client / GUI
− record : RainRecord
− graph : Graph*
+ setGraph(g : Graph*) : void
+ requestGraph() : void
+ addRainData(d : RainData) :
void uses
1
RainRecord
Graph
− readings : QVector<RainData>
+ addReading(d : RainData) : void + draw(xml : QString) : void
+ toXml() : QString
1 ...*
RainData
− station : QString
BarGraph ColumnGraph
− date : QDate
− mm : double
+ draw(xml : QString) : void + draw(xml : QString) : void
+ getStation() : QString
+ getDate() : QDate
+ getMm() : double
Figure 1: Partial UML class diagram for the rainfall tracking application
The diagram shows how data moves through the system. RainData objects are aggregated inside
RainRecord, which is itself held by the Client. The client calls toXml() on its record and passes
the resulting string to whichever concrete Graph the user has chosen through setGraph(), so no
graph class needs to know how the XML was built.
Page 1 of 9
