Eric Lee
Diese Session begann wie die letzte, mit einer Übersicht über die VS Architektur.
(siehe bild)
Eric erklärt, für wen sie die 4(!) Visual Studios gedacht haben. ( Express, Standard , Professional and Team System. )
Der Fokus dieser Session ist der Software Architect.
Zuerst erklärt Eric seinen geschichtlichen Hintergrund,er war früher memeber des Windows Server Developer Teams, heute ist er der Technical Product Manager der VS. Er erklärte, wie sie bei der Entwicklung von Windows 2003 Server zum teil Testeten
So hätten sie zwar einige Hardware rumstehen, dennoch seien gerade die Data Centers ja zum Teil Customized. So seien sie alle Major Build (so alle 5-6 Wochen) ein wenig Weg von Redmond gereist und hättem bei Kunden an "Live" Systemen ihren neuen Build getestet...
Die Frage für den Architekten stellt sich immer wieder:
Wie kommuniziere ich das Design den Entwicklern ? Wie erriche ich, das die Operational Policy verstanden wird...
Alle im VS erstellten Visual Documents sind synchronisiert. Jedes dieser Dokumente hat schlussendlich einen irgendwann Einfluss auf den Code.
Key der Architekten-Sicht ist: Executable design, Deployable design. Das Design mit dem Code synchronisieren. Das ganze VSTS hilft zu verringern, das Kommunikationsschwierigkeiten zwischen den Architekten, Development Tester und den Operational-IT Guys entsehen...so zumindest die Ansicht von M$.
Danach folgte eine Demo :
Er zeigt im Designer, wie er an einer bestehenden Web Applikation mit einer DB Connection(Yukon) 3 Webservices hinzufügt. 2 davon existieren bereits "real" 1'er nicht. Er beschreibt den noch nicht existierenden Web service und lässt sich den Code automatisch generieren.
Er fügt die Web Services in die Toolbox, so das er via Drag and Drop jederzeit auf seine "generischen" eigens erstellten Web Services zugreifen kann.
Dies geschieht alles auf der Design Basis.Der Code wird immer automatisch aktualsiert. Ändert ein Developer Sachen im Code, das Design ändert immer mit, so das der Architekt immer ein aktuelles Design hat. Die Dokumentantion enstricht so immer der Realität.Ich denke das wär noch was für uns...siehe SoftinstLib...
Das Problem bei den IT-Operational People sei, wie beschreibe ich meine Policys? Wie komme ich auf Policys, welche der Business Logik und den Developer Bedürnissen entsprechen...
Darauf wird das SDM als "die" Lösung präsentiert.(SDM = System Definition model (XML File, das generiert werden kann. Diese System Definition dient danach allen als Grundlage, egal ob wir auf Hardware Level, Host Level etc. arbeiten. Grundlage ist immer das SDM.
Keine Kommentare:
Kommentar veröffentlichen