verschachtelte Bibliotheken - Architekturfrage

Hallo Zusammen,

erst einmal möchte ich mich bei allen bedanken: Ich arbeite mich erst seit kurzen in LV ein und habe schon sehr vieles aus diesem Forum lernen können.

Derzeit mache ich mir Gedanken, wie ich eine größere Anwendung handhaben würde. Konkret denke ich an das folgende Szenario:

Ich möchte ein Template entwickeln, von dem ausgehend ich eine einzelne Aufgabe löse. Die Teilmodule, die so entstehen, sollen schließlich möglichst einfach zu einer größeren Anwendung zusammengeschraubt werden können. So komme ich zu zwei Anforderungen:

1. Für die Entwicklung und Tests sollen die Module erstmal einzeln lauffähig sein.
2. Es soll gemeinsam genutzte Komponenten geben, die nur einmal gepflegt werden. Thema Wiederverwendbarkeit...

Vielleicht ein kleines Beispiel dazu: Ein Modul, welches Dateien liest wird aufgerufen von einem Modul, welches Konfigurationsdateien liest, welches aufgerufen wird von einem Modul zur Live Überwachung eines Sensors, aber auch von einem Modul welches gespeicherte Messdaten aus einem File irgendwie verarbeitet.


Wie könnten solche Abhängigkeiten im Projekt Explorer aussehen?

Nun zu meinen Fragen:

Wie organisiere ich die Dateien?
Die Verschachtelung von Projekten scheint mir nicht vorgesehen zu sein. Also ist mein Ansatz die einzelnen Module als lvlib zu handhaben. Lvlibs bieten aber weniger Funktionalität (Einsicht der Abhängigkeiten, Build Möglichkeit). Ich würde also zu jedem Modul sowohl eine Bibliothek als auch ein Projekt pflegen müssen - die Bibliothek, um das Modul in die Hauptanwendung (bzw. ein "höheres Teilmodul") einzubinden und das Projekt, um das Modul einzeln als EXE zu kompilieren. Wie würdet ihr das handhaben? Macht das Sinn, gibt es bessere Alternativen?

Ich kann natürlich einfach alle VIs in einem Ordner ablegen und für jedes Modul ein Projekt anlegen. Doch bei der Integration eines neuen Moduls müsste ich so alle VIs einzeln hinzufügen...

Wie füge ich solch eine gemeinsam genutzte Komponente sinnvoll hinzu?
Bei der Verschachtelung von lvlibs passieren für mich unklare Dinge. Hierzu ein konkretes Problem:

Zunächst habe ich meine Hauptanwendung die zwei Bibliotheken enthält. So weit so gut.


Dann komme ich auf die Idee eine dritte Bibliothek "Visa" zu erstellen und ein VI dort abzulegen.


Die neue Bibliothek möchte ich in dem Modul Task verwenden, also packe ich sie dort hinzu.


Bis hierhin sieht für mich alles normal aus. Doch wenn ich anschließend die Bibliothek Visa öffne, erscheint sie nicht mehr wie gehabt, sondern es sieht plötzlich so aus, als wenn ich die Bibliothek Task geöffnet hätte. Selbst das Fenster zeigt oben den Namen Task.lvlib an. Was ist hier los?


Ab hier wird die Übersicht nur noch schlechter. T2Lib soll die gemeinsame Bibliothek Visa auch verwenden können. Doch sie wird nicht einzeln geladen, sondern über die Bibliothek von Task:



Schließlich öffne ich meine Hauptanwendung und habe einen verschachtelten Murks:


Auf der Festplatte sieht es dabei noch so schön übersichtlich aus:


Ich habe etwas über den User.lib Ordner nachgedacht, doch der eignet sich wohl eher nur für Grundfunktionalitäten, sonst würde praktisch meine gesamte Applikationsentwicklung in diesem Ordner statt finden.

Die Module möchte ich per SVN verwalten, in der Hoffnung, so auch einzelne Module einfach durch neuere ersetzen zu können. Was passiert nun wenn ich in einer Bibliothek ein VI umbenenne? Innerhalb eines Projektes werden alle Aufrufer aktualisiert. Ich hätte nun erwartet, dass eine Bibliothek einer höheren Bibliothek auch "bescheid" gibt, dass alterName.vi jetzt neuerName.vi heißt. Aber ein erster Versuch hat dies leider nicht bestätigt.

Ich freue mich über jeden Denkanstoß oder auch Links zum Thema!

Grüße,
seuk

Hallo seuk,

Zitat:Ein Modul, welches Dateien liest wird aufgerufen von einem Modul, welches Konfigurationsdateien liest, welches …

Hier bietet sich OOP an.
Aber genau anders herum:
Die Hauptklasse liest allgemeine Daten ein, eine Kindklasse kann dann sich um Config-Daten kümmern…

Zitat:Ich habe etwas über den User.lib Ordner nachgedacht, doch der eignet sich wohl eher nur für Grundfunktionalitäten, sonst würde praktisch meine gesamte Applikationsentwicklung in diesem Ordner statt finden.

Ich habe gefühlt 80% meines Prüfstands-Codes im user.lib-Ordner!
Das ist aber Geschmackssache und musst du für dich selbst festlegen…

Hallo GerdW,

perfekt - Klassen lassen sich genau so in einer Hierarchie anordnen, wie ich es mir wünsche. Außerdem kann ich unterschiedliche Hierarchien erstellen, welche auf gemeinsame Klassen zugreifen.

Ich fürchte zur Problematik beim Umbenennen gibt es keinen Königsweg? Wenn ich in Projekt A VIs oder auch ganze Klassen oder deren Methoden umbenenne, werden innerhalb des Projektes alle Verweise darauf automatisch aktualisiert - Projekt B, welches auch diese Klasse nutzt, hat aber keine Chance davon etwas mitzubekommen, oder?

Welche weiteren Vorteilen haben VIs im user.lib Ordner, außer, dass sie über die Funktionspallette direkt hinzugefügt werden können?

Hallo seuk,

Welche weiteren Vorteilen haben VIs im user.lib Ordner, außer, dass sie über die Funktionspallette direkt hinzugefügt werden können?
- Es gibt dann nur eine Kopie dieser VIs…
- Man kann den Ordner bequem im SCC-System (SourceCodeControl) verwalten…