Re: [Tasktlogger-devel] =?iso-8859-1?q?Input_Realisierungsans=E4tze?= =?iso-8859-1?q?=2C_Architektur?=

[Michael S. \(FH\) <Mic...@fh...>]

Hallo,
=20
Ich denke auch dass wir hier einheitliche Vorgaben brauchen.
=20
1. Wir sollten auf jeden Fall ein 3-Schicht Modell verwenden
    Pr=E4sentationsLayer - BusinessLayer - PersistenzLayer
    weil wir=20
    a) Datenbankunabh=E4ngig bleiben m=FCssen
    b) F=FCr alle Dialoge unterschiedliche Exportfunktionen brauchen.
2. Wir sollten uns wie meine VorPoster schon angemerkt haben auf eine
Notation einigen.
   Mein Vorschlag w=E4re, das wir die Ungarische Notation verwenden da =
sie am
bekanntesten ist
3. Einigen sollten wir uns auch wie wir Methoden, Attibute ect benennen.
(Deutsch oder Englisch)
   Mein Vorschlag zu dem Thema w=E4re wir verwenden Englisch.
4. Datenbankdesign: Ich schlage ein ER-Diagramm vor. (Wie schauts da mit
Visio aus - hat das jeder oder sollten wir ein OpenSource Tool =
verwenden?)
5. Einheitliches Layout - Wir sollten eine Vorlage produzieren und diese =
ins
Repository stellen.
6. Die Integrationsgruppe sollte eine Gruppe mit der Aufgabe des Layouts
(k=F6nnte sie theoretisch auch selber machen) beauftragen.
=20
- je genauer wir uns auf eine gemeinsame Vorgehensweise machen, desto =
besser
wird diese Art der Gruppenteilung funktionieren.
lg an alle                =20

  _____ =20

Von: tas...@li...
[mailto:tas...@li...] Im Auftrag von
Martin Kuhn
Gesendet: Sonntag, 08. Oktober 2006 21:43
An: tas...@li...
Betreff: Re: [Tasktlogger-devel]Input Realisierungsans=E4tze, =
Architektur



Hi,

=20

die Gruppen w=FCrde ich auch ganz anders aufteilen aber irgendwie war =
der Hr.
Teiniker von meinem Vorschlag nicht wirklich begeistert.=20

Ich bin aber pers=F6nlich auch auf jeden Fall der Meinung dass eine =
Aufteilung
wie sie Roland beschrieben hat viel zielf=FChrender w=E4re.

=20

LG

=20

Martin

=20

  _____ =20

Von: tas...@li...
[mailto:tas...@li...] Im Auftrag von
Roland Walter
Gesendet: Sonntag, 08. Oktober 2006 21:37
An: tas...@li...
Betreff: [Tasktlogger-devel] Input Realisierungsans=E4tze, Architektur

=20

Hallo,

=20

bin ganz beim Martin. Auch wenn der Umfang des Projektes =84klein=93 ist =
m=FCssen
einige Definitionen getroffen werden, welche bei einem gr=F6=DFeren =
Projekt
nicht viel

anders aussehen.

=20

Nur ein paar Anregungen:

*	In welche Schichten wird die Anwendung aufgeteilt=20


*	(Vorschlag f=FCr Projektgr=F6=DFe BusinessLogic mit Persistenzmethoden =
und
Oberfl=E4che)=20

*	Namenskonventionen (Anwendung, Datenbank, Programmfiles,
Ordnerstruktur)=20

*	Oberfl=E4chentemplate=20


*	Wo werden Aktionsbuttos positioniert=20

*	Wie sieht die Optik der Detail und =DCbersichtsseite aus=20


*	Wo werden welche CSS Klassen eingesetzt=20

*	Benennung =DCbersichtsseite, Detailseite und Auswertungsseiten,
Ordnerstruktur=20

usw.

=20

=20

Da es unser Ziel als Gruppe ist, die Aufgabenstellung zu l=F6sen, wei=DF =
ich
nicht in wie weit wir dabei selbst Entscheidungen treffen k=F6nnen.

Mein Vorschlag w=E4re eine ganz andere Projektstruktur, welche aus =
meiner
Erfahrung sehr gut funktioniert.

Somit w=FCrde ich die Gruppen wie folgt ausrichten:

*	Gruppe A: Integration=20

*	Gruppe B: Projektvorgaben (Namenskonventionen=85),
Oberfl=E4chentemplates, DB Modell (Aufbau und Betreuung bei =
=C4nderungen)=20

*	Gruppe C: Businesslogic + Persistenz f=FCr Objekte sicherstellen.=20

*	Gruppe D: Oberfl=E4chenentwicklung und Visualisierung der Auswertungen
(Auswertungslogik klarerweise in Businesslogic)=20

=20

=20

Dadurch h=E4tten alle Teams klare Aufgaben und jedes Team hat seinen =
Bereich
wo es sich bewegt, anstatt dass jedes Team alle Schichten abbilden

muss. Weiters w=FCrden die Schnittstellen unter den Teams wesentlich =
kleiner
werden und die Koordination vereinfacht. Jedes Team sollte in jedem Fall

einen Verantwortlichen f=FCr die Abkl=E4rung der Schnittstellen zwischen =
den
Teams ernennen.

=20

So, ich hoff jetzt gibt=92s mal ne Diskussion =FCber das Thema ;o)

=20

LG

Roland