UC4 bietet verschiedene Möglichkeiten der Modularisierung (und damit Wiederverwendung von Komponenten) an. Sie lassen sich nicht mit dem vergleichen, was gestandene Programmiersprachen zu diesem Zweck anbieten. Doch bei geschicktem Einsatz lassen sich bemerkenswerte Einsparungen an Programmierungaufwand erreichen. Im folgenden werden die wichtigsten dieser Techniken vorgestellt.

INCLUDEs

Die sicher einfachste Möglichkeit der Modulatisierung ist es, gleiche Programmabschnitte in INCLUDEs auszulagern. Dabei gilt, daß, je einfacher das Programmteil ist, welches ausgelagert werden kann (und soll), umso einfacher läßt es sich in einem INCLUDE durchführen. Grund hierfür ist, daß eine Übergabe der Parameter nur in Form globaler Variablen möglich ist.

Der Vorteil dieser Lösung ist, daß sich INCLUDEs sehr leicht einbinden lassen. Nachteilig ist, daß mit der Verwendung globaler Variablen Variablen durch Namensgleichheit überschrieben werdne können, oder Variablen fehlerhafte Werte von einem vorherigen Aufruf enthalten können.  Diese Nachteile können entschärft werden durch Konventionen wie bspw.

• Kennzeichnung globaler Variablen durch Großschreibung des Variablennamens. Allerdings erfordert das eigene Disziplin, da Variablennamen in UC4 nicht case sensitive sind.
• Kennzeichnung globaler Variablen durch ein eindeutiges Präfix.

Allerdings lassen sich - trotz der Nachteile - INCLUDEs für viele Standardaufgaben gut verwenden, so bspw. für das Setzen von Agent und Login in UC4 Jobs (JOBS), oder das Setzen aller Parameter in Filetransfers (JOBF).

Einfache Bausteine

Eine weitere Form der Modularisierung bietet die Verwendung einfacher Baussteine. Solche Bausteine können JOBS, JOBF oder SCRI sein, welche immer die gleichen Aufgaben durchführen. Solche Bausteine können die benötigten Parameter entweder über :put_read:buffer oder durch :pset, oder durch die Angabe eine Konfigurations-VARA, in der alle relevanten Werte enthalten sind, übergeben bekommen.

Vorteil dieser Lösung ist, daß eine stabile und verläßliche Lösung vorliegt und verwendet wird. Nachteile gibt es eigentlich keine.

Normierte Abläufe

Einen Schritt weiter noch geht ein Modularisierungsansatz, welcher ganze Abläufe als Bausteine verwendet. Dies eignet sich vor allem für Abläufe, welche immer wieder in der gleichen Form ablaufen. Als Beispiel kann ein Filetransfer innerhalb eiiner UC4 Installation genommen werden. Ein solcher Filetransfer weist immer die gleichen Schritte auf

• Anlegen von temporären Zwischenverzeichnissen auf Quelle und Ziel
• Übertragen der Datei(en) von Quelle nach Ziel, ggf. erst in ein Zwischenverzeichnis
• ev. Übertragen der Datei(en) aus dem Zwischenverzeichnis in das endgültige Verzeichnis
• je nach Anforderung Archivieren der übertragenen Datei(en)
• Bereinigen der Zwischenverzeichnisse auf Quelle und Ziel.

Eiin solcher Ablauf läßt sich einfach erstellen, mit je einem UC4 Objekt für jede vorgesehene Aufgabe. Eingebettet werden die Objekte in einen Plan, in welchen mittels :pset einer globalen UC4 Scriptvariablen der Name einer Konfigurations-VARA zugewiesen wird, welche alle benötigten Parameter einhält. In dieser VARA werden dann nicht nur die für die Dateiübertragung unmittelbar benötigten Parameter (Quellhost, -login und-verzeichnis sowie Zielhost, -login und-verzeichnis) eingetragen, sondern auch Angaben dazu, oder der Filetransfer generisch arbeitet, ob die Quelldateien gelöscht werden können, ob es sich um Text- oder binäre Dateien handelt u.ä. Alle Objekte in dem ablaufplan lesen die von ihnen benötgten Parameter aus dieser VARA - sonst nirgends!

Um nun einen neuen Transfer zu "erstellen", müssen nur der äußere Jobplan und die Konfigurations-VARA exportiert werden, umbenannt werden, und wieder importiert werden. Die Script-Variable für die Konfiguration erhält den Namen der neuen UC4 VARA. Danach kann die Konfiguration aus der neu importierten VARA gelesen werden; aber alle anderen UC4 Objekte sind jedoch die gleichen, die sie im Ausgangs-Jobplan waren.

Geht man noch einen schritt weiter, indem nämlich Jobplan und VARA gleich heißen, nur daß der Jobplan auf ".JOBP", die VARA auf ".VARA" endet, so kann die Konfigurations-VARA auch dynamisch bestimmt werden, indem im Jobplannamen die Zeichenkette ".JOBP" durch die Zeichenkette ".VARA" ersetzt wird. Danach ist außer dem Export, dem Umbenennen des gemeinsamen namens von JOBP und VARA sowie deren Import keine Aktion erforderlich, um einen neuen UC4 Transfer zu erstellen.