Prüfsoftware möglichst objektorientiert programmieren...

[DelphiManiac]

Hallo ich bin dabei wie in Thread

http://www.delphipraxis.net/internal...t.php?t=112368

(Habe einen neuen Thread aufgemacht weil ich im alten zu unstrukturiert gefragt habe... sorry)

beschrieben eine Prüfsoftware für eine Hardwarekomponente zu entwickeln,

ich habe mir jetzt einige Anregungen zur Brust genommen und versucht umzusetzen, d.h. ich

habe z.Zt. folgendes Gebilde

Ich muss ja n-Test durchführen.

deswegenen habe ich eine Klasse TTest gebildet,
die schon Objekte der Klassen:
- TPrueflig (API zur Kommunikation mit dem Gerät)
- TMultimeter(API zur Kommunikation mit dem Messgerät)
- TKalibrator(API zur Kommunikation mit dem Kalibrator)

Jede Testklasse hat wie "hsg" vorgeschlagen hat eine Execute Methode um den Prüfvorgang zu tätigen.

Von diesen Klassen leite ich jeweils meine Prüfungen ab (wie im Beitrag von "Der_Unwissende")

Also zum Beispiel

TTestCom2Geraet = class (TTest)
..
Testet die Kommunikation über die Schnittstelle (ob das Gerät antwortet)



usw.usw

Nun habe ich noch eine Klasse
TControlTest gebildet, die die einzelnen Tests nacheinander ausführen soll,
also eine Klasse zur Steuerung des Testablaufs, dies mache ich über eine Objektliste und führe sie nacheinander aus.


meine Frage ist dieser Ansatz sinvoll, oder ggf. noch zu verbessern?

Gerne stelle ich hier auch ein paar aussagekräftigere Quellcodes oder ein Klassendiagramm rein.

Hoffe ich habt Lust und Muße mit mir zu diskutieren :)

Gruß
DelphiManiac

[Relicted]

huhu!

also für mich hört sich das sehr sinnvoll an..
in die TTest einfach ne execute methode rein und diese abstrakt deklarieren.
das erspart lästiges typecasten...

ich selber wende das bei parserstrukturen an. eigentlich genau das selbe.

eine idee wäre noch deine TestControl klasse als singleton objekt zu implementieren und in jede von TTest abgeleitete klasse einen initialization block zu machen, welcher die klasse direkt am TTestControl objekt anmeldet..
dazu bräuchtest du noch eine kleine funktion die das objekt bereitstellt...
dazu würde ich die struktur folgendermaßen wählen:

Delphi-Quellcode:

ITest = interface
  procedure Execute( .. );
end;

TTest = class( TInterfacedObject, ITest )
end;

TTest1 = class(TTest)
//...
public
  //...
  procedure Execute(...);
end;


function GetTest : ITest;

implementation

function GetTest : ITest;
begin
  result := TTest1.Create;
end;



initialization
  TestControl.RegisterTest(GetTest);

das ist bissl aus der struktur von dunit geklaut... :-)

gruß
reli

[DelphiManiac]

Hallo,

ja das dem Singleton Muster könnte ich anwenden, so, dass sich dann alle Objekte(Tests) am Testcontrol
anmelden gar keine schlechte Idee, ich glaube ich muss mir DUnit doch mal genauer angucken, habs
nur überflogen, da es schon sehr komplex war in meinen Augen.

Mein Problem bei der Durchführung der Test ist wahrscheinlich nicht die Kommunikation mit den Geräten, wohl
eher die visuell Darstellung des Prüfablaufes.
Ich will z.B.: ein Prüfobjekt deklarieren, dass Messwerte liesst und Werte an das Gerät schreibt.

Wie kann ich denn dies am geschicktesten machen, ohne konkrete Implementierungen in meiner Unit vorzunehmen,

ich will natürlich nicht sowas machen:

Delphi-Quellcode:

frmMainGUI.LabelMesswert.Caption:=IntToStr(Geraet.GetMesswert);

Am liebsten wäre mir an der Stelle eine lose Kopplung, das heißt ich will nicht die Logik der Darstellung mit in meine Tests bauen sondern dieses der GUI-Klasse überlassen, wie sie es darstellt.

Danke euch!

[Relicted]

du könntest informationen in die testklasse ansich anschreiben. meinetwegen noch eine abstrakte methode die ein record oder ein objekt zurückgeben soll, welches dann mit den infos gefüllt ist die du visualisieren willst.
das objekt kann dann von deiner form aus über das singleton abgerufen und visualisiert werden..

ich weiß leider nicht inwieweit sich die informationen gleichen...
du könntest natürlich auch einfach ein event definieren und beim ersten zugriff auf das singleton übergeben, sodass die infos die du haben willst ( ich denke da an eine log ) über das event ans formular weitergereicht werden und das formular dann meinetwegen den krempel in ein memo kloppt... :-)

gruß
reli

[DelphiManiac]

Hi Relicted

also habe u.a. folgende Tests / Vorgänge

Flashen des uC
Info: - Fortschritt (am besten Progressbar)

Kalibrieren der Analogausgänge
- aktueller AnalogAusgangswert
- vorgegebener Wert

usw. usw.

Meinst du ich soll ein Event basteln?

also eine Art Callback Funktion, die der GUI Daten übergibt?

Danke dir!

[Relicted]

Jau würd ich machen...

Delphi-Quellcode:

TProgressEvent = procedure( min,max,act : integer; sInfo : string ) of object;

von dem event braucht dann jedes TTest Objekt ne property und natürlich ne member... machst sie am besten protected die member dann kann auch jeder abgeleitete test weiterhin drauf zugreifen.

dann brauch deine handlerklasse auch noch so eine procedure wie:

Delphi-Quellcode:

procedure SetProgressEvent( Event : TProgressEvent );

in der wird dann jedem angemeldeten Test das event übergeben..
ich würde z.B. 2 events an die handlerklasse weitergeben.. eins für overall (gesteuert vom handler selbst) und eine für die einzelnen tests wo die ihren progress anzeigen können... auf die form dann dementsprechend auch 2 progressbars.. gesamt und einzelner test.

und wenn du nun ansich immer die selben daten pro test angezeigt haben willst dann mach dir nen record:

Delphi-Quellcode:

type
  TInfoRec = record
    aktuellerAnalogAusgangswert : integer;
    vorgegebenerWert : integer; 
    //....
  end;

[DelphiManiac]

Hallo,

ja mit dem ProgressEvent könnte ich das ganz Gut steuern...

Habe nur das Problem, dass ich zum Beispiel eine Funktion habe, die Paramterschreibt,
aber erst zurückkommt, wenn sie alle Parameter geschrieben hat, evtl. muss ich diese
so um bauen, dass sie immer nur einen Parameter schreibt, und ich diese dann n-mal aufrufe,
so, dass ich danach meinen ProgressEvent aufrufen kann.

Wie meinst du dass?

Zitat:

in der wird dann jedem angemeldeten Test das event übergeben..
ich würde z.B. 2 events an die handlerklasse weitergeben.. eins für overall (gesteuert vom handler selbst) und eine für die einzelnen tests wo die ihren progress anzeigen können... auf die form dann dementsprechend auch 2 progressbars.. gesamt und einzelner test.

Also ich habe jetzt in meiner abstrakten Testklasse eine Event, dass die GUI über den Fortschritt eines Tests informiert.
Den Gesamtfortschritt kann ja nur meine ControlTest-Klasse wissen, das bedeutet doch, dass ich ihr auch noch ein Eventproperty
verpassen muss, oder???

Danke dir!

[Relicted]

richtig... macht halt nen schönen eindruck wenn man weiß wie viel man insgesammt scho geschafft hat :-)

[DelphiManiac]

Ja da hast du Recht,...

meine Anwendung wird langsam.

Mal ne andere Frage ich rufe ja das
Event folgendermaßen auf:

Delphi-Quellcode:

if Assigned(FProgressEvent) then
begin
  FProgressEvent(0,100,0,'');
end;

Muss ja prüfen, ob der Methodenzeiger auch wirklich auf eine Methode zeigt und nicht auf

Delphi-Quellcode:

NIL

Kann man das auch schöner formulieren, oder ist das so der einzige Weg?

Gracias

[Relicted]

ich mache es immer so dass ich mir ne hilfsmethode mache (private) die ich aufrufe und in der dann steht

Delphi-Quellcode:

procedure PrintPrivate( ... );
begin
  if Assigned( FProgressEvent ) then
    FProgressEvent(  ... );
end;