Composite User Interface Application Block und Smart Client Software Factory als Integrationsplattform für Module klinischer Arbeitsplatzsysteme

Transkript

1 Composite User Interface Application Block und Smart Client Software Factory als Integrationsplattform für Module klinischer Arbeitsplatzsysteme Composite User Interface Application Block und Smart Client Software Factory as an Integration Platform for Clinical Workplaces Kristof Kersting Diplomarbeit Betreuer: Prof. Dr. Andreas Künkler Freiburg,

2 II Danksagungen Ich möchte mich beim Klinikrechenzentrum der Universitätklinik bedanken, dass mir das Fernstudium innerhalb der Fortbildungsmaßnahmen ermöglich hat. Außerdem gilt ein besonderer Dank meinen Kollegen aus der Abteilung, durch deren Unterstützung und durch deren Gespräch ich täglich dazulerne.

3 III Kurzfassung Am Beispiel der Module Terminplanung, Patientensuche und Stationsbelegung innerhalb eines Klinischen-Arbeitsplatz-Systems (KAS) wird die Eignung eines Frameworks von Microsoft für die Integration der Module in einem Desktop untersucht. Dabei ist zugleich vor allem eine lose Kopplung der Module gefordert. Die Implementation des integrierten Desktop ist unter.net mit C# realisiert. Bei dem verwendeten OpenSource-Framework handelt es sich primär um den Composite U- ser Interface Application Block (CAB), sowie darauf aufbauend um die Smart Client Software Factory (SCSF). Für die Fehlerbehandlung und das Logging werde auch Module der Enterprise Library von Microsoft.NET herangezogen. Unter definierten Zielvorgaben (s. Kapitel 4) wird geprüft, inwieweit diese Systeme für die Erreichung dieser Ziele geeignet sind. Dabei wird zuerst in das Framework und seine Pattern eingeführt, dann die Anforderungen für die Realisierung eines Teils des KAS (Terminplanungsmodul für die Vergabe von Patiententerminen) im Umfeld eines großen Klinikums herausgearbeitet, und schließlich anhand einer beispielhaften Umsetzung mit diesem Framework die Hypothese, dass das Framework grundsätzlich geeignet ist, überprüft. Durch den sinnvollen Einsatz von Design-Pattern und einer modernen Service orientierten Architektur kann die Implementierung vielen Anforderungen (besonders der der losen Kopplung der Module) gerecht werden. Als Plattform dient das.net Framework 2.0 mit Erweiterungen für die Windows- Communication-Foundation (WCF) und C# mit Visual Studio 2005 als Entwicklungsumgebung. Dabei wird für einige WebServices die WCF eingesetzt, die aktuelle, vertragsorientierte Kommunikationsplattform von Microsoft.

4 IV

5 V Inhaltsverzeichnis 1 EINLEITUNG PROBLEMSTELLUNG AUFGABENSTELLUNG UND ZIELSETZUNG RAHMENBEDINGUNGEN Was die Arbeit nicht leistet ANFORDERUNG AN DIE INTEGRATIONSPLATTFORM KONKRETE ANFORDERUNGEN AN DAS PROJEKT ALLGEMEINE SOFTWAREANFORDERUNGEN ANFORDERUNGEN AN DIE GRAPHISCHE BENUTZEROBERFLÄCHE OBJECT-BUILDER DEPENDENCY INJECTION COMPOSITE USER INTERFACE APPLICATION BLOCK (CAB) WAS IST CAB? TECHNISCHE ASPEKTE VON CAB: Architektur Architektur des UserInterface (Shell ) INHALTLICHE ASPEKTE VON CAB: Zweck/Ziele Wie werden diese Ziele erreicht? (Funktionsweise, Philosophie, Design) Shell WorkItems ( Use Case driven Strategie) Services Event Broker/Commands UI Extension Objekterzeugung Fehlerbehandlung ZUSAMMENFASSUNG CAB SMART CLIENT SOFTWARE FACTORY (SCSF) ARCHITEKTUR PROJEKTSTRUKTUR FEATURES Rezepthilfen Services Pattern ENTERPRISE LIBRARY ARCHITEKTUR Layers Plug-In (SOFA) Architektur Modul und Assembly Einbindung der Module und Services CAB-Module ohne GUI-Elemente... 44

6 VI Abhängigkeiten zwischen Modulen Kommunikation zwischen Modulen LÖSUNGSKONZEPT Shelldesign Infrastruktur-Services WorkItems/Module/Services identifizieren (Use cases) MODULE UND SERVICES VERWALTUNG Login (Authentifikation und Autorisation) Authentifikation Autorisation Konfiguration Laden von Modulen und Services Kontext-Service Logging-Service MessageBox-Service Visualizer-Service Splash-Screen SICHERHEIT INFRASTRUKTUR Patientenverwaltung USER INTERFACE (UI) Patientensuche Funktion Problematik Lösung (ActionCatalog Service ) Stationsbelegung Terminplan Nachrichten und Alarmhinweisanzeige TESTEN ERGEBNISSE KRITIK AUSBLICK LITERATUR LINKS CAB Extensions Enterprise Library Object Builder Smart Client Software Factory Diverse Projekte/Beispiele/Case Studies RD PARTY COMPONENTS UND CAB INDEX GLOSSAR ANHANG CAB-, SCSF-GLOSSAR WHAT IS A SMARTCLIENT? USING OTHER USER INTERFACE ELEMENTS AS UIEXTENSIONSITES EVENTSUBSCRIPTION IN DER SCSF MODUL ABHÄNGIGKEITSDIAGRAMME SMART CLIENT SOFTWARE FACTORY CAPABILITIES APPLICATION FRAMEWORKS IM VERGLEICH CAB-APPLICATION KLASSENHIERARCHIE-VISUALIZER

7 VII Abbildungsverzeichnis ABBILDUNG 1: COMPOSITE CLIENT... 1 ABBILDUNG 2: CREATE A SINGELTON (AUS [HAS]) ABBILDUNG 3: CHAIN OF RESPONSIBILITY OBJECT BUILDER (VGL. [CAZ07]) ABBILDUNG 4: PROPERTY INJECTION (OBJECT BUILDER AUS [HAS]) ABBILDUNG 5: INJEKTION DURCH ATTRIBUTE ABBILDUNG 7: FUNKTIONSBLÖCKE IN CAB ( AUS [ASCH06] S. 95.) ABBILDUNG 8: ARCHITEKTUR UI ANWENDUNGEN MIT CAB UND SCSF (SCHICHTEN [SZP06] S. 13) ABBILDUNG 9: CAB APPLICATION UND SHELL ([KRU06]) ABBILDUNG 10: WORKITEM CONTAINER (AUS [JEN07] S.11) ABBILDUNG 11: DEEPER WORKITEM OVERVIEW (AUS [BELLCABA]) ABBILDUNG 12: BAUMSTRUKTUR DER WORKITEMS ([KRU06] S. 45) ABBILDUNG 13: WORKITEM HIERARCHIE UND SMARTPARTS (AUS [KRU06]) ABBILDUNG 14: CAB SERVICEINTERFACES ABBILDUNG 15: UIEXTENSIONSITES (VGL. [PLA07] S. 99) ABBILDUNG 16: METAATTRIBUT [SERVICEDEPENDENCY] ABBILDUNG 17: SCSF ÜBERBLICK ABBILDUNG 18: SCSF ARCHITEKTUR ABBILDUNG 19: SCSF AUTOMATISCHE PROJEKTERSTELLUNG ABBILDUNG 20: SCSF PROJEKTGERÜST ABBILDUNG 21: SCSF REZEPT (S. HILFE-DATEI DER SCSF - STICHWORT RECIPES ) ABBILDUNG 22: SERVICE AGENTS (AUS SCSF-HILFEDATEI) ABBILDUNG 23:PATTERNS IMPLEMENTIERT UND UNTERSTÜTZT VON CAB UND DER SCSF [MSSCSF]..FEHLER! TEXTMARKE NICHT DEFINIERT. ABBILDUNG 24: APPLICATION BLOCK COVERAGE ABBILDUNG 25: ARCHITEKTUR.NET ([MSSCARCH]) ABBILDUNG 26: SEPARATION OF CONCERN ([GRE08]) ABBILDUNG 27: ARCHITEKTUR EINE ANWENDUNG MIT PLUGIN-MODULEN ([NEWSOA]) ABBILDUNG 28: SHELLDESIGN DER IMPLEMENTIERUNG ABBILDUNG 29: UIEXTENSION SITES ÜBER EINEN SHELL EXTENSION SERVICE ANGESPROCHEN (S. [SZP06]).. 49 ABBILDUNG 30: USECASES SCSF-PROTOTYP ABBILDUNG 32: ÜBERSICHT DER MODULE IM PROJEKTMAPPENEXPLORER VON VISUAL STUDIO ABBILDUNG 33: FROM OBJECTS TO SERVICES (.NET FRAMEWORK) ABBILDUNG 34: LOGIN SERVICE (SCHEMATISCHE DARSTELLUNG) ABBILDUNG 35: SEQUENZDIAGRAMM AUTHENTIFIZIERUNG ABBILDUNG 36: SEQUENZDIAGRAMM MODULE LOADER ([WILS06]) ABBILDUNG 37: LOGVIEWER ABBILDUNG 38: CAB VISUALIZER VIEW ABBILDUNG 39: PATIENTENSUCHE VIEW ABBILDUNG 40: FIELDS AND METHODS OF THE ACTIONCATALOG CLASS (AUS SCSF CONTRIB) ABBILDUNG 41: ACTION CATALOG VERHALTENSSCHEMA ([PLA07] S. 141) ABBILDUNG 42: STATIONSBELEGUNG VIEW ABBILDUNG 43: TERMINPLANUNG VIEW ABBILDUNG 44: PROJEKTMAPPENANSICHT DES TERMINPLAN-MODULES ABBILDUNG 45: NACHRICHTEN-MODUL ABBILDUNG 46: INFRASTRUCTURE TESTPROJEKTE ABBILDUNG 47: ANHANG: MODULABHÄNGIGKEITEN PATIENTENSUCHE ABBILDUNG 48: CABAPPLICATION KLASSENHIERARCHIE-VISUALIZER

8 Tabellenverzeichnis TABELLE 1: CODE SMELLS [BELLCOMP]... 9 TABELLE 2: ANHANG: IMPORTANT TERMS AND DEFINITIONS FOR CAB TABELLE 3: ANHANG: IMPORTANT CLASSES/TERMS REQUIRED TO UNDERSTAND FOR SCSF TABELLE 4: ANHANG: PROJECTS CREATED BY THE SMART CLIENT SOFTWARE FACTORY TABELLE 5: ANHANG: SCSF INFRASTRUCTURE TABELLE 6: ANHANG: SMART CLIENT SOFTWARE FACTORY CAPABILITIES TABELLE 7: ANHANG: VERGLEICH VON APPLICATION-FRAMEWORKS

9 Einleitung 1 1 Einleitung Hintergrund für die Evaluation eines Integrierten Desktops ist die Anforderung an die EDV- Abteilung zwei bestehende, sich zum Teil überschneidende Programme zusammenzuführen. Dies soll in Zukunft Doppelentwicklungen vermeiden und außerdem dem Anwender die Handhabung der Kis- (Klinische Informationssysteme) Funktionalität erleichtern, so dass er sich nur noch in ein Programm mit einheitlichem Look & Feel einarbeiteten muss. Dies bedeutet unter anderem im Umgang mit dem Computer eine Arbeitserleichterung und in der Einführung der Software eine Zeitersparnis. In dieser Arbeit wird beispielhaft anhand einiger weniger Module untersucht, ob eine Integration dieser Module unter der in Kaptiel 4 Anforderung an die Integrationsplattform vorgegebener Zielrichtung grundsätzlich erreicht werden kann. In der folgenden Abbildung sind eine Reihe zu integrierender Systeme zu sehen: Abbildung 1: Composite Client Neben den allgemeinen Anforderungen an Software ergeben sich aus dem Umfeld des Arbeitsplatzes in einem Klinikum spezielle Anforderungen, deren mögliche Umsetzung durch die Unterstützung dieses Frameworks überprüft wird.

10 2

11 Problemstellung 3 2 Problemstellung Es gilt eine Lösung zu finden, um Module unterschiedlicher Programme, die in C#, VB.Net und Delphi erstellt wurden, zusammenzuführen und noch zu entwickelnde Module zu integrieren. Dabei handelt es sich bei VB.NET unter anderm um Module für die OP-Dokumentation, eine Betten- und Terminplanung und eine Dokumentverwaltung. In Delphi existiert auch eine Terminplanung und Dokumentverwaltung, dazu noch ein Befundmodul und andere Module. In C# sind eine Patientensuche, die Anzeige von Patientenstammdaten und eine Order&Entry Webanwendung umgesetzt. Die Doppelentwicklungen, wie die Terminplanung oder Dokumentenverwaltung müssen hier zusammengeführt werden und andere Module wie OP- Planung und Befundmodul müssen für den Arbeitsplatz der Ärzte und der Pflege integriert werden. Desweitern gibt es Module von anderen Herstellern (Röntgenbildviewer, Befundviewer u.a.), deren Daten bzw. Ansichten in einem Desktop für den Anwender transparent dargestellt werden müssen. Diese Arbeit überprüft dabei anhand definierter Zielvorgaben (s. Kapitel 4), inwieweit die Systeme von Microsoft (CAB, SCSF 1, Enterprise Library) für die Erreichung der Ziele geeignet sind. Dabei wird zuerst Funktionsweise von CAB und der SCSF dargestellt, dann die Anforderungen an die Realisierung eines Teils des KAS (rudimentäres Terminplanungsmodul für die Vergabe von Patiententerminen) im Umfeld eines großen Klinikums untersucht. Dies wird im ersten, eher theoretischen Teil der Arbeit getan. Im praxisorientierten Teil (ab Kapitel 9)der Arbeit wird anhand einer exemplarischen Umsetzung mit diesem Framework die Hypothese, dass das Framework grundsätzlich den Anforderungen entsprechen kann, überprüft. Dabei kommt es vor allen Dingen auf eine modulare und lose gekoppelte Implementation der Module an. Da in den nicht wissenschaftlichen Bereichen hauptsächlich Windows von Microsoft läuft, ist ein Implementierung unter C#, wie es das Framework anbietet, und dem.net Framework 2.0 (und höher) eine sinnvolle Wahl. 1 Smart Client Software Factory: Ein Framework, das auf CAB (Composite Application Block) aufbaut und es erweitert

12 Problemstellung 4

13 Aufgabenstellung und Zielsetzung 5 3 Aufgabenstellung und Zielsetzung Es geht um die Klärung der Frage, ob das Framework für die Realisierung folgender Ziele geeignet ist, wobei anhand der Nummerierung auch eine Priorisierung der Ziele verdeutlicht wird (die nicht explizit vom/durch das Framework zu erreichenden Ziele, deren Lösung hier auch nicht überprüft wird, sind kursiv markiert): 1) Modularität (plug in, add-ins, add-ons ) 2 a) Lose Kopplung zwischen den Modulen (dabei notwendige Auflösung von Abhängigkeiten) und damit gute Wiederverwendbarkeit b) Lazy Loading (erst wenn Modul/Service benötigt wird, wird Modul/Service geladen) 2) Module sind in einem GUI integrierbar(gemeinsames Look and Feel ) 3) Einbindung von Legacy Modulen (Win32-Module,.NET Module) und Modulen von anderen Herstellern 4) Dezentrale Konfigurierbarkeit 5) Benutzerverwaltung (Rechtevergabe, Sicherheitskonzept) a) Rollenkonzept b) Authentifizierung und Autorisierung 6) Aufrufbarkeit von Fremdanwendungen aus (aus Java, Delphi etc. heraus) Eine genauere Erläuterung der Ziele und einige weitere Ziele finden Sie im Kapitel 4: Konkrete Anforderungen an das Projekt. Die Plattform, auf der dies alles realisiert werden soll ist dabei vorgegeben und zwar.net 2.0 und höher mit C#. Dieses schränkt zwar die Clients auf das Windows-Betriebssystem ein, was aber in der Praxis kaum von Nachteil ist, weil Windows vom größten Teil der benutzt wird. Dabei wurden hier auch Ziele aufgenommen, die nicht zu vorderst über das Framework erreicht werden können. Dies geschah aus dem Grund, dass dennoch geprüft werden muss, ob das Framework der Realisierung der Ziele nicht im Wege steht bzw. sie unmöglich macht Rahmenbedingungen Um noch einen kleinen Eindruck von der Umgebung zu geben, in der dieses Programm benutzt werden soll, ein paar Daten: die Universitätsklinik Freiburg besteht aus 17 einzelnen Kliniken mit Mitarbeitern und einem Aufkommen von ca. 1 Million Patienten im Jahr. Es gibt ca Computerarbeitsplätze, die von 900 Ärzten, ca Mitarbeitern des Pfle- 2 Der Begriff plug-in wird auch bezeichnet als add-in, add-on, snap-in oder Erweiterung [GK07]

14 Aufgabenstellung und Zielsetzung 6 gepersonal, Verwaltungsmitarbeitern und anderen Personen bedient werden. D.h., es entsteht eine große Menge von Daten, die an den Arbeitsplätzen sofort zur Verfügung stehen müssen. Deshalb kommt der Performance, der Plattformunabhängigkeit und der Erweiterbarkeit eine große Bedeutung zu. Als zentrales Protokoll zwischen den zentralen Systemen dient die Health Level 7 (Hl7)-Schnittstelle. Die Termindaten werden zurzeit noch in einer Interbase Datenbank (Firebird 2.1) gespeichert. Weitere zentrale Daten wie z.b. die Patientenstammdaten oder Informationen über Kostenstellen (Nehmer bzw. Geber von Terminen/Leistungsanforderungen) kommen über die Hl7- Schnittstelle aus anderen zentralen Quellen. Zur Authentifizierung und Berechtigungsprüfung auf bestimmte Terminkalender wird die Gruppenverwaltung eines LDAP (Lightweight Directory Access Protocol) Servers und für feinere Granulierung noch eine Datenbank benutzt. Es existiert eine zentrale Berechtigungsprüfung für den Zugriff auf Patientendaten, die auch hier zum Einsatz kommen soll. Die Anforderungen an das System sind ständig gestiegen und der wachsenden Komplexität und Funktionalität muss Rechnung getragen werden. Damit das Programm leichter erweiterbar wird und die Lesbarkeit des Programmcodes, ebenso wie seine Wartbarkeit gesteigert wird, sind einige grundlegende Änderungen notwendig. Da das System anfangs nur für einen kleinen Bereich gedacht war, nun aber viele Kliniken damit arbeiten wollen, wird z.b. die Installationsfreiheit zu einem wichtigen Kriterium für die Akzeptanz und die Möglichkeit des praktischen Einsatzes der Software. Diese Terminplanung wird nun aber auch im Zusammenhang mit einem Order&Entry System (Leistungsanforderungen zwischen allen Kliniken intern und auch externen Kliniken) benutzt und muss in den Katalog anderer KIS-Funktionalität (Stationsübersicht, Befundeinsicht, OP-Planung, Verschlüsselung u.a.m.) integriert werden. In diesem Kontext ist das Thema der Arbeit zu sehen Was die Arbeit nicht leistet Im Rahmen dieser Arbeit in dem begrenzten Zeitraum kann nur ein Prototyp der Anwendung erstellt werden. Die Punkte der viel komplexeren Konfiguration, Benutzer-, Rechte- und Sicherheitsverwaltung, sowie die Umsetzung weiterer Services werden hier nicht geleistet. Weitere notwendige Schritte, die über die Möglichkeiten dieser Arbeit hinaus gehen, sind Performancetests bei steigender Zahl von Modulen und bei mehreren Hundert Benutzern, eine genauere Prüfung des serverseitigen Einsatz von Modulen (eben für WebServices), die Architektur/Design für komplexe Lösung eines Kis und eine Implementierung von ClickOnce 3 zur Softwareverteilung und Softwareaktualisierung. 3 Ist eine Bereitstellungstechnologie von Microsoft, die sich selbst aktualisierende Windows-Anwendungen ermöglicht, die mit minimaler Benutzerinteraktion installiert und ausgeführt werden kann (ab.net 2.0)

15 Anforderung an die Integrationsplattform 7 4 Anforderung an die Integrationsplattform 4.1 Konkrete Anforderungen an das Projekt Hier sind nun die konkreten Anforderungen aufgezählt, die für die Realisierung des gewünschten Integrated Desktops zu erfüllen sind. Die unterschiedliche Priorität bzgl. der Wichtigkeit der Ziele wird versucht durch die Nummerierung zum Ausdruck zu bringen (die kursiv gedruckten Punkte werden hier nicht geprüft): 1) Modularität (plug in, add-ins, add-ons ) a) Lose Kopplung zwischen den Modulen (dabei notwendige Auflösung von Abhängigkeiten) und damit gute Wiederverwendbarkeit b) Lazy Loading (erst wenn Modul/Service benötigt wird, wird Modul/Service geladen) 2) Module sind in einem GUI integrierbar (gemeinsames Look and Feel ) 3) Einbindung von Legacy - Modulen (Win32-Module,.NET Module) und Modulen von anderen Herstellern 4) Dezentrale Konfigurierbarkeit 5) Benutzerverwaltung (Rechtevergabe, Sicherheitskonzept) a) Rollenkonzept b) Authentifizierung und Autorisierung 6) Aufrufbarkeit von Fremdanwendungen aus (aus Java, Delphi etc. heraus) 7) Anbindung verschiedener DB - und BackEnd Systeme ohne die Notwendigkeit der Installation von DB-Treibern 8) Module müssen auf Client- und auf Serverseite (WebServices) einsetzbar sein 9) Offenheit für den Einsatz von WebServices (Unternehmensstrategie aus Wiederverwendbarkeitgründen und wegen der Installationsfreiheit; ebenfalls zur Vorbereitung von SOA) 10) automatische, zentrale Softwareverteilung (Deployment Click once) a) Versionierung b) Updates/Erweiterungen 11) Caching (zur Performancesteigerung) ist realisierbar Nun noch eine nähere Erläuterung zu den oben genannten Punkten: zu 1), 3), 6): Vorrangiges Ziel ist die Zusammenführung der Programme. Da es schon viele in Delphi realisierte Module gibt, die nicht auf einen Schlag neu programmiert werden können, ist eine Einbindung der alten Module zwingend notwendig. Die Modularitätsforderung ergibt sich weiterhin aus der Forderung nach Lesbarkeit, Wartbarkeit und Erweiterbarkeit, also der Umgang mit der steigenden Komplexität der Software. Anders sind die steigenden Anforderungen nicht mehr realisierbar. Durch die Modularität

16 Anforderung an die Integrationsplattform 8 werden die Entwicklung in unterschiedlichen Teams mit definierter Aufgabenstellung ( Separation of Concern ) und die Einbindung von Fremdprodukten ermöglicht. Aufgrund der Vielfalt der Aufgaben sind ohne den Einsatz von Fremdanwendungen mit dem existierenden Team die anfallenden Anforderungen nicht mehr umsetzbar. Auch umgekehrt können natürlich so eigene Module von Fremdprodukten aufgerufen bzw. integriert werden. Durch unterschiedliche Zusammenstellung von Modulen sind Lösungen für unterschiedliche Anforderungen realisierbar. zu 4), 5): Durch die große Anzahl von Nutzern und die unterschiedlichen Sicherheitsanforderungen ist nur eine größtenteils dezentrale Konfigurierbarkeit durch die EDV-Betreuer der einzelnen Kliniken vor Ort praktikabel. Die Betreuer vor Ort kennen die Benutzer und können so auch auf Rotationen der Ärzte direkt reagieren und den Zugriff auf die notwendige Software ermöglichen. zu 7): Im Augenblick sind noch als Datenbanken Oracle und Firebird für die Clients direkt im Einsatz. Andere Datenbanken werden durch eine Hl7-Schnittstelle. Bei der großen Anzahl der Installationen ist nur eine Installation ohne DB-Treiber bzw. eine automatische Installation derselben praktikabel. Dasselbe gilt für das ganze Softwarepaket und dessen Updates. Die Eigenentwicklung im Klinikum für das Klinikum bietet die Möglichkeit auf Änderungen in den Anforderungen schnell reagieren zu können. Dieser Vorteil soll nicht durch umständliche Installationsverfahren verspielt werden. zu 8), 10): Da man sich aufgrund der begrenzten Ressourcen keine Entwicklung von unterschiedlichen Softwarelösungen zum selben Problem mehr leisten kann, müssen möglichst Servicemodule für dieselbe Aufgabe auf Client- und Serverseite einsetzbar sein. Dies ist dann auch bei der geplanten stärkeren Verwendung von WebServices von Vorteil (vgl. Punkt 9). zu 11): Die gute Performance ist ein wichtiger Faktor für die Akzeptanz der Systeme. Ärzte wollen und können nicht lange auf die Bereitstellung der Daten bzw. auf die Erledigung der EDV unterstützten Abläufe warten. Für diese Performance ist besonders auch bei WebServices ein Caching von großer Bedeutung und eine Unterstützung für das Caching durch das Framework sehr hilfreich. 4.2 Allgemeine Softwareanforderungen Zu den oben genannten Anforderungen gesellen sich Anforderungen, die für jedes Programm gelten und auch hier erfüllt werden müssen, wie z.b. Logging, Tracing, möglichst einfache Testbarkeit, Exception Handling, Caching. Was sind die Anforderungen an die Qualität von Programmiererzeugnissen?

17 Anforderung an die Integrationsplattform 9 Es gibt neben den spezifischen Kundenanforderungen allgemeine Qualitätskriterien und Anforderungen, die an die Erstellung von Software gestellt werden. Nach Greenfield und Short sind dies ( Non Functional Requirements ): usability, reliability, performance, supportability ([GS04] S. 47/48). In Microsoft Patterns & Practices wird von folgenden Erfordernissen gesprochen: operational requirements as maintainability, reusability, extensibility, scalability, robustness, and security ([MSESP] S. 7). Damit diese Kriterien erfüllt werden können muss Software mit den Problemen der steigenden Komplexität und den sich verändernden Anforderungen umgehen können. Die Software soll so entworfen werden, dass Design Smells vermieden werden. Dazu gehören 4 : Bezeichnung Folgen für die Software nähere Erläuterung Rigidity hard to change The application is hard to change even in small ways.can t find the right place to make the change.any change causes a cascade of changes. Fragility easy to break The application breaks easily with the slightest change, often in distant and unrelated places. Immobility difficult to reuse Can t reuse parts because their inseparable from their contexts Perversity (Viscosity) easier to do the wrong thing The code resists efforts to do the right thing.it is easier to hack than pursue good design Complexity over design Infrastructure or abstraction without immediate, direct benefit. Redundancy needles repetition Duplicated code masked by small changes;typically the result of cut and paste Opacity hard to read or understand Code that is long, convoluted, and incomprehensible Tabelle 1: Code Smells [BellComp] Zu berücksichtigen ist weiterhin eine angemessene Performance. Der Architektur-Leitfaden von Microsoft spricht in diesem Zusammenhang von Designing for Performance. Dies ist bei Verwendung von Services als WebServices im Intranet ein wichtiger Punkt: Smart clients are usually part of a larger distributed application. It is important to consider the performance of the smart client application in the context of the complete application, including all of the network located resources that the client application uses. To design smart clients to perform efficiently, consider the following: Caching data where appropriate Optimizing network communications 4 The Seven Deadly Design Smells listed in Bob Martin's book: Agile Software Development: Principles, Patterns, and Practices

18 Anforderung an die Integrationsplattform 10 Using threads efficiently Using transactions efficiently Optimizing application startup time... Managing available resources efficiently Optimizing Windows Forms performance Caching data where appropriate Optimizing network communications Using threads efficiently Using transactions efficiently Optimizing application startup time... Managing available resources efficiently Optimizing Windows Forms performance (aus [MSScArch] Chapter 8, S.157 ff.) 4.3 Anforderungen an die graphische Benutzeroberfläche Das graphische Benutzerinterface muss sehr flexibel sein. Je nach angemeldetem Benutzer/Rolle sind andere Elemente anzuzeigen, die auch innerhalb einer Rolle noch auswählbar sein müssen, z.b. die Auswahl, ob eine Stationsbelegung, eine Bettenplanung oder eine Terminplanung gewünscht ist. Je nach Berechtigung sind Module zu laden, die sich in die Hauptshell (-konsole) einhängen können sollen und die dort z.b. eigene Menüpunkte bzw. in der Statuszeile eigene Informationen anzeigen müssen. Andererseits soll die Entwicklung der Module möglichst unabhängig von den GUI-Elementen sein, damit diese eventuell ausgetauscht werden können. Eine Lösung für diese Problem sieht Boogaart darin, dass die Module über Services mit den UI-Elementen kommunizieren und somit keine direkte Verbindung zu den Controls existiert: The shell should be providing services that module developers can leverage to void this pain and free your modules from any dependencies on a particular UI toolkit. (Kommentar von Kent Boogaart in [BellReq]). Diese Lösung wird von Berchtel für CAB/SCSF umgesetzt ([Ber07]). Im Allgemeinen sind natürlich die Guidelines für Dektop-UI-Entwicklungen zu berücksichtigen. 5 5 Siehe z.b. Linksammlung unter (s. beigefügte CD Verzeichnis Allgemein, User Interface Design.mht ) oder

19 Object-Builder 11 5 Object-Builder Der Object Builder (OB) ist das zentrale Element in CAB und ein wichtiges Element in der Enterprise Library. Über ihn wird das Ziel erreicht, dass die Kooperation von Objekten möglich ist und eine Unabhängigkeit von der direkten Implementierungen der Objekte erreicht wird. Das Mittel dazu ist die späte Bindung, d.h. die Verbindung zwischen Objekten geschieht nicht zur Entwurfszeit (direkt über eine Implementierung), sondern erst zur Laufzeit. Dabei wird die Erzeugung der Objekte vom OB kontrolliert: ObjectBuilder is actually a configurable object factory. (aus [TavOB] - What is ObjectBuilder). Dazu braucht der OB allerdings einen Container, der bei CAB durch die WorkItem repräsentiert ist. Damit die einzelnen Elemente wirklich lose gekoppelt sind, müssen die Implementationen der Objekte von dem Code, in dem sie benutzt werden, losgelöst sein. Fowler ([FowIOC]) beschreibt zwei mögliche Vorgehensweisen, um dies zu erreichen: Dependency Injection (DI) und Service Locator. Im Object Builder sind beide Funktionen realisiert. Dabei gibt es drei Arten von Injection: Setter-Injection, Constructor-Injection, Interface- Injection (diese bietet der OB nicht, dafür eine Method Injection). 6 CAB gebraucht sehr häufig DI, um Objektinstanzen zu erzeugen. Diese Injektion der Instanzen wird in dem Application Block ObjectBuilder zur Laufzeit erledigt. Die Klärung der Begriffe Dependcy Injection, Inversion of Control und Dependency Inversion bzw. deren Abgrenzung untereinander wird von Newman geleistet (s. [New07] 7 ). Den Weg von direkter Erzeugung über Factory zur DI findet man bei Volmer (s. [VolOB]). 5.1 Dependency Injection Die Vorteile der DI gegenüber anderen Methoden sind: lose Kopplung. bessere Testbarkeit (Mock-Objekte) Suchmethoden in Container zentralisiert, nicht in den Komponenten notwendig 6 Genauer nachlesen kann man über diese Pattern zum Bsp. bei Fowler (FowIOC). Dort anhand des Beispiels MovieLister MovieFinder.. 7 Inversion of Control = Dependency Injection? As I ve discussed, dependency injection is just one very specific example of how inversion of control can be used. As a result it is probably wrong to treat IoC and dependency injection as terms that mean the same thing. IoC is a wider concept.

20 Object-Builder 12 zusammen mit Einsatz von Interfaces für die Objekte sehr flexibel (Änderung in Konfiguration statt im Code möglich) Abhängigkeiten werden explizit gemacht (Attribute). DI ist gerade die Umkehrung der sonst üblichen Prinzipien, bei denen jedes Objekt die Beziehungen zu anderen Objekten selbst aufbaut. Eine Metapher dafür ist das Hollywood- Prinzip: Am Ende des Vorstellungsgesprächs eines Schauspielers für einen Film steht meistens die Aussage:»Rufen Sie uns nicht an, wir rufen Sie an.«genauso ist es hier mit den Objekten: Sie rufen nicht aktiv die Umgebung auf, sondern werden von ihr mit den notwendigen Referenzen versehen. Wobei hier im Gegensatz zu den Hollywood- Gesprächen der Anruf tatsächlich erfolgt. Dies ergibt den Vorteil, dass die Objekte von zwei Aufgaben befreit sind, nämlich der Konfiguration und dem Aufbau der Umgebung. Dadurch wird der Code völlig unabhängig von der Umgebung. (aus [Wol06] S. 28f; völlig unabhängig ist hier natürlich übertrieben bestimmte Abhängigkeiten muss es geben, Anm. des Autors). Als Nachteile sind zu nennen: Alle Klassen, die über Reflektion erreichbar sein sollen, müssen als»public«deklariert sein. Die Performance sinkt, da Strategien immer wieder durchlaufen werden. 8 Dabei erledigt der OB noch einige andere Aufgaben, wie aus der Abbildung oben abzulesen ist. Den OB kann man auch losgelöst vom CAB zur Objekterzeugung benutzen (s. auch [TavOB]). In dem Artikel Demystifying the object builder [Has] beschreibt der Autor, wie man den OB für die Objekterzeugung benutzen kann. Als einfachstes Beispiel sei hier die Erzeugung eines Singletons angeführt: 8 Unity ist die neueste Implementation eines Lightweight Containers s. (Unity Application Block)!!! was ist der Zusammenhang

21 Object-Builder 13 Abbildung 2: Create a Singelton (aus [Has]) Wie man sieht, kann man dem Object Builder mitteilen, wie ein Objekt erzeugt werden soll. Dabei wird die DI beim Erzeugen des Objektes durchgeführt und zwar anhand einer Strategie, die genau weiß, wie der Typ der Strategie auszuführen ist. Zu einer Strategie gehört auch eine Policy (Verfahren) und zwar benutzt die Strategie die Policy, um die Erzeugung zu steuern. Dabei ist der folgende wichtige Punkt zu beachten: Policy sind für Objekttypen definiert (im Beispiel für den Objekttyp MyObject ), Strategien dagegen sind für einen bestimmten Stand innerhalb des Erzeugungsprozesses festgelegt und stehen in einer Kette, d.h. werden in einer festgelegten Abfolge durchschritten bzw. abgearbeitet (im Beispiel bei der Erzeugung und als Singleton). In der folgenden Abbildung sind die verschiedenen Stufen dargestellt:

22 Object-Builder 14 Abbildung 3: Chain of Responsibility Object Builder (vgl. [Caz07]) Die Abfolge der Strategien lässt sich gut im Trace-Modus in der Console (Ausgabefenster) verfolgen, wenn man in der App.config (z.b. im Cab-Lab 02: WorkItem ) folgende Einträge hinzufügt: <?xml version="1.0" encoding="utf-8"?> <configuration> <system.diagnostics> <sources> <source name="microsoft.practices.objectbuilder" switchname="moduleloader"> <listeners> <add name="console" type="system.diagnostics.consoletracelistener"/> </listeners> </source> </sources> <switches> <add name="moduleloader" value="information"/> </switches> </system.diagnostics> </configuration> (s. auch Es gibt im OB 3 Arten der Injektion: die Constructor-Injection, die Property-Injection und die Injektion in Methoden. Im folgenden Diagramm sind die Abhängigkeiten bei der Property Injection aufgezeigt:

23 Object-Builder 15 Abbildung 4: Property Injection (Object Builder aus [Has]) Der Ablauf ist der Folgende: die Strategie Klasse guckt nach einer verfügbaren IPropertySetterPolicy für einen bestimmten Objekttyp ( MyObject ). Wenn die Policy für den Typen auch registriert ist, läuft die Strategie über alle Properties, die eine Injektion benötigen. Jedes Property, das eine Injektion angemeldet hat, wird durch das IPropertySetterInfo näher beschrieben, einmal durch seinen Namen und zum zweiten dadurch, wie der Wert für das Property geholt werden kann. Nun aber noch kurz zur MethodExecutionStrategy. Diese Strategie bekommt ihren Sinn daher, dass die BuildUp-Methode auch für schon existierende Objekte durchlaufen wird. Damit können auch Methoden erzeugt werden, was in CAB für das Publish-Subcribe-Pattern und für das Command-Pattern benutzt wird. In der Praxis benutzt der OB in großem Masse Reflektion, um über die Dekoration von Properties durch Attribute die Injektion zu ermöglichen. Wenn man ein Objekt vom OB benötigt, schaut der OB über die Metaattribute bei der Objekterzeugung und kümmert sich um den BuilderContext, d.h. erzeugt die notwendigen Policies und Parameter und gibt die geforderte Instanz zurück. Einige Metaattribute werden vom OB bereitgestellt, z.b. [Dependency], [CreateNew] [InjectionConstructor], [InjectionMethod] und [Parameter]. Weitere können selber erstellt werden, wie es z.b. CAB mit der [ServiceDependency] tut.

24 Object-Builder 16 Als Beispiel zum Schluss sehen wir in diesem komplexeren Fall 2 Injektionen auf einmal in den Constructor wird ein Parameter per Injektion mitgegeben. Die erste Injektion geschieht über das Attribut [ServiceDependency]. Dadurch wird ein Service per Reflektion gesucht, der ein WorkItem zurückgibt. Über die 2. Injektion [InjectionConstructor] wird der Konstruktor Module() aufgerufen und das WorkItem aus der inneren Injektion als Parameter eingefügt: Abbildung 5: Injektion durch Attribute Beim Laden des Modules wir per Reflektion über die Attribute gegangen und per ObjektBuilder die Abhängigkeiten aufgelöst. Dazu müssen dem ObjektBuilder die abhängigen Objekte natürlich bekannt sein.

25 Composite User Interface Application Block (CAB) 17 6 Composite User Interface Application Block (CAB) 6.1 Was ist CAB? Zuerst ein Hinweis: Für das Verständnis von CAB und der SCSF ist die Kenntnis der grundlegenden Terminologie unumgänglich. Im Text sind diese Begriffe fett gedruckt und verweisen auf die Erläuterungen im Anhang. Allgemein gesehen kann man CAB einmal als Framework betrachten, das man sofort - so wie es ist - benutzen kann, und zum anderen als Metaframework, um noch ein eigenes Framework auf CAB aufzusetzen. Zur Beschreibung von CAB wird auf die technischen und funktionalen Elemente des Frameworks eingegangen. 6.2 Technische Aspekte von CAB: Physikalisch gesehen ist CAB eine Anzahl von.net Klassen in C# geschrieben für das.net Framework 2.0. Es wurde im Dezember 2005 von Microsofts Patterns&Practices Group bereitgestellt und liegt im Source-Code komplett offen. Es ist einer (von vielen) Application- Blocks, die Microsoft zur kostenlosen Verwendung für die Lösung üblicher Softwareanforderungen zur Verfügung stellt. Die Enterprise Library enthält weitere Blocks, die z.b. für das Logging oder das Caching von Daten benutzt werden können. Cab besteht aus 3 Assemblies, die den Namen Microsoft.Practices.CompositeUI etc. tragen. Abbildung 6: CAB Komponenten Der Object Builder wurde bereits weiter oben behandelt.

26 Composite User Interface Application Block (CAB) 18 Im folgenden Bild sind die Inhalte der einzelnen Blöcke strukturiert dargestellt. Abbildung 7: Funktionsblöcke in CAB ( aus [Asch06] S. 95.) Für die graphischen UI-Elemente ist die Assembly CompositeUI.Windows-Forms zuständig. Wie man sieht, ist CAB primär für den Einsatz von Windows-Forms (WinForms) gedacht. Es gibt allerdings inzwischen Erweiterungen, die auch den Einsatz von WindowsPresentation- Foundation-Forms (WPF) ermöglichen. Speziell für die WPF (Zukunft der Microsoft UI, die die Erstellung von Windows über eine Beschreibungssprache XAML ermöglicht und so Web- UI und Desktop-UI näher zusammenbringt) wurde von der Patterns&Practices Group ein eigenes Projekt aufgesetzt Prism 9. Als Grundlage für diesen graphischen Block und dafür notwendige, allgemeine Services sind in der CompositeUI Assembly zusammengefasst. Auf die einzelnen Blöcke wird im Verlauf der Arbeit noch näher eingegangen. 9 "Prism" is a set of assets for developing Composite WPF applications.

27 Composite User Interface Application Block (CAB) Architektur Die Schichten, denen man bei der Entwicklung einer komponentenbasierten CAB Anwendung gegenübersteht, sind im folgenden Bild verdeutlicht. Als Grundlage dient eben das CAB bzw. die SCSF als Framework, das den Rahmen (die Patterns) für die eigene Entwicklung bietet. Dazu gehören zu allererst die Shell, von der alle Module aufgerufen werden können, und die übergreifenden Services (vgl. Infrastructure.Interface). Die Module beinhalten die zu entwickelnden Komponenten, die beim Start über eine Konfiguration gesteuert geladen werden. Dabei werden logisch zusammenhängende WorkItems in einem Modul integriert. Abbildung 8: Architektur UI Anwendungen mit CAB und SCSF (Schichten [Szp06] S. 13) Diese Architektur ist auch interessant im Zusammenhang mit den anderen Teilen, der SCSF und der Enterprise Library, als erweiterten Aufbau einer Dienstarchitektur (weitere Überlegungen zur Architektur finden Sie weiter unten, s. Kapitel über die

28 Composite User Interface Application Block (CAB) 20 Smart Client Software Factory (SCSF)). Der Schichtenaufbau ( Layer Pattern ) dient der Trennung der Zuständigkeiten und damit der Reduzierung der Komplexität und ermöglicht wiederum getrennte Entwicklung der Schichten in unterschiedlichen Teams Architektur des UserInterface (Shell ) Wie man in der Abb. oben sieht, bietet die Assembly CompositeUI.WinForms 5 unterschiedliche Typen von Workspace an, die in der Shell benutzt werden können. Die Shell ist der zentrale Einstiegspunkt für alle Module, die sich in ihr darstellen wollen ( hosting ). Auch wenn nur 5 Typen existieren, kann man damit den Großteil der Forderungen an ein UI abbilden, indem man diese Typen unterschiedlich schachtelt. Selbst die Shell kann rollenbasiert unterschiedlich aufgebaut werden. Es gibt inzwischen eine Erweiterung von CAB, die auch ein DockPanelWorkspace 10 anbietet und somit einen ähnlichen Aufbau ermöglicht wie die Entwicklungsumgebung von Visual Studio mit an- und abdockbaren Windows. Workspaces are components that encapsulate a particular visual way of displaying controls and SmartParts. The Composite UI Application Block includes the following types of workspaces: WindowWorkspace. This workspace enables you to show and hide controls framed in a window. MdiWorkspace. This workspace enables you to show and hide controls and Smart- Parts in MDI child forms. TabWorkspace. This workspace enables you to show and hide controls and Smart- Parts inside a tabbed page. DeckWorkspace. This workspace enables you to show and hide controls and Smart- Parts in an overlapped manner with no visible frame. ZoneWorkspace. This workspace enables you to create a tiled workspace layout. Showing controls through workspaces allows you to consistently display, hide, activate, and monitor the parts shown, independently of the visual style in which they display. This allows the appearance and behavior and the layout of your shell to evolve independently of the SmartParts hosted within it. (aus der SCSF-Hilfe Datei). 10 Enthalten im ScsfContrib-Paket oder separat über die Assembly DockManager von Weifen Luo einbindbar.

29 Composite User Interface Application Block (CAB) Inhaltliche Aspekte von CAB: Zweck/Ziele Der neue Composite UI Application Block (CAB) und die Smart Client Software Factory bilden das Fundament der Integrated Desktop-Implementierung von Microsoft. ([TK06] ). CAB dient als Framework und zwar als Framework in den 3 Weisen, wie es Marc Clifton in [Cli05] beschreibt, die ich hier noch einmal aufzähle: 1. als Wrapper für Funktionen, die u. a. das Ziel der Vereinfachung beinhalten (hier z.b. das Publish-Subscriber Model), 2. als bestimmte Architektur (s. oben Schichtenmodell) und 3. als Methodik, d.h. das Framework gibt ein bestimmtes Vorgehen vor, z.b. WorkItems als Container für Objekte und Services zu benutzen. Der Zweck dieses Frameworks ist es den Entwicklern von größeren Desktop-Anwendungen Hilfe anzubieten, um modulare, lose gekoppelte Einheiten zu entwickeln. Dabei werden insbesondere folgende Ziele verfolgt: 1. Entwicklung von unabhängigen, aber kooperierenden Modulen (Loose Coupling) Primäres Ziel von CAB ist die lose Koppelung ( loose coupling ) von zusammenarbeitenden Modulen und der Shell. D.h. es sollten keine Abhängigkeiten zur Kompilierungszeit vorhanden sein. Erst zur Laufzeit werden die Modulverbindungen hergestellt ( late binding ). Der Grund dafür ist die einfachere Möglichkeit, Module einzubinden bzw. auszutauschen allein durch eine Veränderung in der Konfiguration, ohne die Veränderung von Code. Die notwendigen Beziehungen zwischen den Modulen werden nie direkt realisiert, sondern über Schnittstellen und/oder Vermittler hergestellt. 2. Trennung/Aufteilung von Zuständigkeiten (Separation of Concern) Durch diese Separation ist eine Aufgabenteilung und damit eine Lösung einzelner Aufgaben durch unabhängige Entwicklerteams möglich. Die Geschäftslogik ( business layer ) kann so getrennt von der Entwicklung der Darstellung der Informationen ( presentation layer ) geschehen. Spezialisierte Teams können folglich optimal eingesetzt werden. (vgl. [Gre08]) 3. Bereitstellung einer Architektur, die die Integration von Modulen an einem Arbeitsplatz ermöglicht (Integrated desktop) Diese Modularität soll für den Benutzer nicht sichtbar sein, sondern für ihn erscheint die Anwendung wie aus einem Guss, d.h. vom Look and Feel verhalten sich die Module so, als wären sie nicht getrennt entwickelt worden. In einer Benutzeroberfläche können so einzelne Module, obwohl sie möglicherweise auf ganz unterschiedliche Datenbestände zugreifen, aufgerufen werden. 4. Erweiterbarkeit / Wiederverwendbarkeit (Plug-in) Die Anwendung soll durch weitere Module einfach erweiterbar sein. Das heißt auch in anderen Programmierteams entwickelte Module lassen sich in den Desktop integrieren und damit wieder verwenden. Auch die Veränderung von existierenden Verhaltensweisen und Strategien muss einfach möglich sein. Dadurch dass der Code zugänglich ist, kann das Framework selbst nach eigenen Bedürfnissen erweitert werden.

30 Composite User Interface Application Block (CAB) Wie werden diese Ziele erreicht? (Funktionsweise, Philosophie, Design) Diese Ziele werden größtenteils durch den Einsatz von Pattern (Dependency Injection, Factory, UI-Adapter u. a.) erreicht. Zunächst aber zur grundsätzlichen Design-Idee von CAB im Folgenden einige Erläuterungen Shell Zentral steht in der Anwendung die Shell als der Rahmen für die Darstellung von UI- Elementen. Shells sind selbst lose an die Anwendungskomponenten gekoppelt und bieten dadurch einen flexiblen Ansatz für die Entwicklung von Benutzeroberflächen. Die Shell und die CAB-Dienste fahren den Wagen, doch Sie müssen den Motor in Form einer oder mehrerer Anwendungen bereitstellen, die von der Shell verwaltet werden. ([TK06] S. 2). Abbildung 9: CAB Application und Shell ([Kru06]) In diesen Rahmen können Module, die UI-Elemente besitzen, sich darstellen. Die zu ladenden Module werden in einer Konfiguration festgelegt (ProfileCatalog ) und beim Start der Anwendung in ein Containersystem eingebunden. Über den Container werden alle Elemente, die von anderen Modulen genutzt werden sollen, miteinander verbunden, d.h. er ist der Vermittler und zentrale Verknüpfungspunkt. Dies ermöglicht auch die Realisierung des Dependency Injection Patterns (s.u.). Dieser Container bzw. eine Hierarchie von Containern stellen die sogenannten WorkItem dar. Das oberste Element ist das RootWorkItem. Diese Container sorgen anhand folgender Listen: Services (Zugriff auf Objekte mit einer Menge von Funktionalitäten) Commands (z.b. Ereignisse von UI-Elementen) weitere untergeordnete WorkItems Workspace (Platzhalter für Flächen zum Anzeigen von SmartPart ) Items (unspezifische Objektliste, z.b. für Windows-Forms oder Zustände) SmartPart (Anzeige von UI-Elementen) Events UIExtensionSite State (Liste der Zustände), für die Verwaltung und den Zugriff auf die Elemente/Objekte (s. a. [Pla07] S. 58).

31 Composite User Interface Application Block (CAB) 23 Hier eine schematische Darstellung der zum WorkItem-Container gehörigen Objekte: Abbildung 10: WorkItem Container (aus [Jen07] S.11) Das weitere Umfeld eines Workitem wird in diesem Schema dargestellt: Abbildung 11: Deeper WorkItem Overview (aus [BellCaba]) Die Shell besitzt sogenannte UIExtensionSite. CAB bietet Implementierungen dazu in den visuellen Komponenten für das Menü, die Werkzeugleiste und die Statuszeile bereit. Dort

32 Composite User Interface Application Block (CAB) 24 können die Module die Shell dynamisch erweitern, ohne die Shell selber direkt zu kennen. Eigene Anwendungen können diese Sites ergänzen und erweitern. Ergebnis: Module sind lose gekoppelt und werden erst zur Laufzeit miteinander verbunden, und eine Erweiterbarkeit ist einfach über Konfiguration möglich WorkItems ( Use Case driven Strategie) Die WorkItems sind also die Container, die CAB benutzt, um alle Element miteinander so lose wie möglich zu koppeln. Ein WorkItem repräsentiert normalerweise einen Use Case. Die Zuständigkeit kann verteilt werden auf unterschiedliche WorkItems, die ihre eigenen Objekte verwalten. Abbildung 12: Baumstruktur der WorkItems ([Kru06] S. 45) Mehrere oder nur ein WorkItem können zu einem (engl.) Module zusammengefasst werden und bilden so die Grundlage für die Modularisierung. Die Sichtbarkeit (und Lebensdauer) der Objekte wird auch von dem Container bestimmt. Für alle darunterliegenden Kinder- Container sind diese Objekte auch sichtbar ( Flow of Components ). Module mit einem UserInterface (UI)-Element besitzten einen SmartPart. Das sind die visuellen Objekte innerhalb eines WorkItems und eigentlich sind sie ein normales Control einer WinForm (Das bestehende CAB ist für WinForms UI-Elemente entwickelt kann allerdings auch für andere Elemente erweitert werden). Der Unterschied zu einem Control besteht darin, dass ein SmartPart einem WorkItem-Container zugeordnet ist und somit unter dessen Verwaltung steht. Nun sollen für die lose Kopplung die UI-Elemente und die Logik sich nicht direkt kennen müssen, damit man ein UI-Element bzw. den Workspace später einfacher austauschen kann. Die Vermittlung geht hier über einen Workspace. Dies ist ein Bereich, in dem sich das UI- Element darstellen kann. Abbildung 13: WorkItem Hierarchie und SmartParts (aus [Kru06]) Hier ist wieder eine WorkItem- Hierarchie gezeigt, diesmal aber

33 Composite User Interface Application Block (CAB) 25 mit den UI-Elementen (Smart Part), in denen sie sich das WorkItem darstellen will. Die Entkopplung der visuellen Komponenten und der Shell wird dadurch erreicht, dass der SmartPart nicht direkt der Shell, sondern einem WorkSpace hinzugefügt wird. Die Trennung von UI-Element und Logik wird durch das MVC-bzw. MVP-Pattern erreicht (näheres s. unten). CAB benutzt die Dependency Injection um die einzelnen Elemente zu verknüpfen und dennoch keine Änderung im Code des genutzten Modules zu benötigen. Dies wird durch den Object Builder erreicht, so dass z.b. nie direkt ein Modulobjekt (per New()) erzeugt werden muss, sondern die Erzeugung eben durch die Verwendung des Factory Patterns im Object Builder erreicht wird. Das Ergebnis ist also eine Entkopplung von visuellen Komponenten und Shell, eine Modularisierung in WorkItems und eine Separierung der Zuständigkeiten Services Neben den UI-Modulen gibt es außerdem die Infrastructure Module (Infrastructure.Interface), die Service (ohne UI-Elemente) anbieten wie z.b. für das Logging, die Sicherheit oder die Authentifzierung. Diese sind normalerweise von globalem Interesse und es gibt einen Weg, diese allen Modulen zur Verfügung zu stellen. CAB bietet von sich aus unter anderen Dienste für das Laden von Modulen, einen Authentifikationsdienst, einen Aufzählungsdienst für Module, einen Zustandsspeicherungsdienst. Abbildung 14: CAB Serviceinterfaces Wie auch sonst in CAB werden Schnittstellen zur Verbindung benutzt, gemäß dem Pattern-Prinzip Programm to an interface, not an implementation ([FFSB06] S.11). Die bestehenden Dienste kann man auch seinen Anforderungen gemäß anpassen. Hier besteht die Möglichkeit eigene Services zu ergänzen, wie z.b. einen Authentisierungsdienst, Webdienste oder einen Verteilungsdienst. Die Dienste können in der Konfiguration festgelegt werden. Die SCSF erweitert diesen Katalog durch weitere Services. Das Ergebnis ist hier die Kapselung von Anforderungen in Diensten und Infrastruktur- Modulen, sowie die leichte Erweiterbarkeit. Hier noch eine wichtige Erläuterung vom Unterschied zwischen Services und Items, die beide in Listen eines WorkItems gehalten werden: The Services Collection versus the Items Collection

34 Composite User Interface Application Block (CAB) 26 the Services collection on a WorkItem has some important differences with the Items collection. This is separate from the fact that the intent of the two collections is different: services are meant to be objects that expose chunks of related functionality, whereas items are just any objects that we want to be able to access through the WorkItem. The differences between the collections can be confusing so I ll start this discussion by comparing the two collections. Services vs Items (1): Unique Types The most obvious of these conceptual differences is the fact that the Services collection can only ever contain one object of a given type. If we attempt to add a second service of the same type to a Services collection we get an ArgumentException with message A service of this type already exists. In contrast, the Items collection of a WorkItem can contain multiple objects of the same type. To accommodate this all objects added to the Items collection are assigned a unique string ID, either by the user explicitly, or by the CAB implicitly (a random GUID is assigned). However, this means that if we want to access a specific object in the Items collection we have to know its ID. Hence the ComponentDependency attribute, which injects an object from the Items collection, needs an ID passed as an argument. We don t need an ID to access an object in the Services collection. Because we can identify a service uniquely by its type the ServiceDependency attribute can be used to inject a service without the need for any ID. Services vs Items (2): Searching the Hierarchy Another difference between the Services collection and the Items collection is what happens if we request a specific object from the collection and the CAB can t find it in the WorkItem s collection. When trying to retrieve a service the CAB will then search in any parent WorkItem s Services collections for the object, and return it if found. With the Items collection the CAB will just return null if the object cannot be found in the specific Items collection for the WorkItem. (aus [New07] Teil 7). Es gibt noch einen weiteren bisher nicht erwähnten Service den ActionCatalog Service. Dieser bekommt Bedeutung, falls mehrere WorkItems über das Eintreffen eines Ereignisses informiert werden wollen. Hier gibt es die Möglichkeit (im Gegensatz zur EventPublishing Implementierung) einer Rückgabe- bzw. eine Einspruchmöglichkeit. Dieser Vorgang wird nicht von evtl. Threading beeinflusst(vgl. [Pla07] S.139ff.). Als Beispiel nennt Platt den Wechsel des ausgewählten Patienten (s. Kapitel Patientenverwaltung). Bevor nun alle WorkItems diesen Wechsel mitbekommen und dementsprechend reagieren, ist es möglich, dass man noch bei der Bearbeitung des alten Patienten ist und diese Bearbeitung noch nicht abgeschlossen hat hier möchte man gerne einen Hinweis an den Benutzer geben (bevor der Wechsel stattfindet), ob er z.b. die Änderungen speichern, verwerfen oder den Wechsel des Patienten gar nicht erst zulassen. Dafür ist dieser Service geeignet. Beim einem Wechsel des Benutzers ist ein ähnliches Vorgehen denkbar (s. Impersonation Service in der Anwendung).

35 Composite User Interface Application Block (CAB) Event Broker/Commands Um die Kommunikation zwischen Modulen ohne direkte Aufrufe zu ermöglichen, bietet CAB über das Oberserver-Muster (s. [GoF95]) die Möglichkeit, Veränderungen untereinander mitzuteilen. Ein Module kann ein Ereignis, das für andere Module von Interesse sein könnte (hier z.b. die Auswahl eines anderen Patienten in einer Stationsliste) publizieren (EventPublication ). Andere Module können ihr Interesse an diesem Ereignis kundtun, indem sie sich als Abonnenten eintragen (EventSubscription ). Es können dabei mehrere WorkItems Ereignisse anbieten und mehrere WorkItems sich für ein Ereignis als Interessent anmelden (many-to-many event system mechanism). Auch auf der UI-Ebene besteht ein Benachrichtigungssystem über Command. Commands können an Ereignisse von WinForm-Controls gebunden werden und so z.b. ein Click- Ereignis an andere Module kommunizieren. Ergebnis: Module sind auch in der Kommunikation lose gekoppelt UI Extension Dem User müssen oft Informationen von den unterschiedlichen Modulen in der Hauptshell angezeigt werden. CAB bietet die Möglichkeit in der Shell über Menüitems, Statuszeile und Toolbars, Elemente der einzelnen Module in der Ansicht sozusagen zu sammeln ohne dass die Shell wissen muss, was die einzelnen Module anzeigen wollen. Die Module selber wissen über die Möglichkeit, die Shell an bestimmten Stellen zu erweitern bzw. sie zu informieren. Dabei kommt das Adapter Pattern (s. im Anhang Using Other User Interface Elements as UIExtensionSites) zum Einsatz. Für die oben genannten Elemente stellt CAB schon ein Adapter zur Verfügung. Weiterhin kann man für eigene UI-Extensions eigene Adapter schreiben (vgl. [Pla07] 5 G.). Abbildung 15: UIExtensionSites (vgl. [Pla07] S. 99) Berchtel (s. [Ber07] UIElementCreationService ) führt noch eine weitere Entkopplung ein, indem er die UI-Extensions noch unabhängig von der konkreten Realisierung z.b. eines Menüitems macht. Damit können die UI-Elemente, falls z.b. Komponenten von 3.Anbietern be-

36 Composite User Interface Application Block (CAB) 28 nutzt werden sollen, leichter ausgetauscht werden, ohne das in allen Modulen eine Anpassung vorgenommen werden muss. Das RootWorkItem besitzt eine bestimmte Collection (Sammlung), die ein UIElementAdapter implementieren und die UIExtensionSite genannt werden. Dies ist der Ort an dem Erweiterungen vorgenommen werden müssen durch eine Registrierung einer Site. Über das Root- WorkItem hat jedes Modul Zugriff auf diese Collection und kann somit ihre eigenen Toolbars, Menüitems etc. hinzufügen. Allerdings sind die vorgegebenen Möglichkeiten begrenzt: wenn man ein ankreuzbares oder ein versteckbares Item hinzufügen will, ist das nicht ohne Erweiterung der bestehenden Schnittstelle möglich (s. [New07] Part14). CAB bringt von sich aus eben ein Adapter mit, das von der Klasse ToolStripItem abgeleitet ist. Für andockbare ToolStrips, wie in der Abb. oben zu sehen, muss man ein eigenes Adapter schreiben, dass z.b. von ToolStripPanel abgeleitet ist Objekterzeugung Wie schon oben erwähnt, wird die lose Koppelung in CAB auch dadurch erreicht, dass Objekte nicht direkt erzeugt werden, sondern dass die Instanzen über eine Factory, den ObjectBuilder erzeugt und erreichbar sind. Über Metaattribute kann man dem ObjectBuilder seine Aufgabe (über Reflektion) mitteilen: z.b. bedeutet das Attribut [ServiceDependency] bei einem Property, dass beim Starten dieses Moduls über Setter-Injektion die passende Instanz diesem Property zugewiesen wird (s. Abbildung hier wird eine WorkItem Instanz über Property/Setter Injection zugewiesen). Über diesen Mechanismus lassen sich Implementierungen sehr leicht austauschen. Abbildung 16: Metaattribut [ServiceDependency] Fehlerbehandlung Für die Behandlung der Exceptions gibt es in CAB keine eigene Implementierung. Im Zusammenhang mit der unten dargestellten SCSF, wird dafür üblicherweise das Exception- Handling der Enterprise Library benutzt.

37 Composite User Interface Application Block (CAB) Zusammenfassung CAB Hier sind nocheinmal stichwortartig die Vor- und Nachteile von CAB zusammengefasst: CAB Vorteile Loose Coupling wird unterstüzt Separation of Concern wird gefördert Integrated Desktop wird emöglicht Erweiterbarkeit gut möglich durch offene Quellcodes Gewisse Architektur wird vorgegeben (s. Nachteile) und damit zu einem guter Programmierstil angeregt, z.b. durch Patternbenutzung CAB Nachteile Gewisse Architektur wird vorgegeben (s. Vorteile) und damit gewisse Einschränkungen erzeugt zu komplex, damit hohe Einarbeitungszeit Abhängigkeiten vom Framework können nicht vermieden werden (Loslößen vom Framework kostet Arbeit) zu langsam, besonders beim Laden von vielen Modulen (durch die häufige Reflektion im Object Builder)

38 Smart Client Software Factory (SCSF) 30

39 Smart Client Software Factory (SCSF) 31 7 Smart Client Software Factory (SCSF) Zur Einleitung diese Kapitels zitiere ich hier die ersten Absätze der ausführlichen Hilfe-Datei zur SCSF, in denen der Zweck der Factory zusammengefasst und abgegrenzt wird: The Smart Client Software Factory helps architects and developers create composite smart client applications. A composite smart client application is composed of a number of discrete, independent, yet functional pieces. These pieces are integrated together within a host environment (such as a Windows Form application) to form a fully coherent smart client solution.... The Smart Client Software Factory is designed to address requests from architects and developers who create smart client applications and need to: Build clients composed of independent yet cooperating modules. Separate the concerns of module builders from the concerns of the shell developer, allowing business units to concentrate on development of domain-specific modules instead of the client architecture. Use an architectural framework for producing a consistent and high quality integrated desktop development. Increase productivity and reduce overall development time through consolidating architect and developer efforts. Because the Composite UI Application Block is designed to address these application needs, the applications you create with the Smart Client Software Factory use the Composite UI Application Block. To fully understand the guidance in the Smart Client Software Factory, you must be familiar with this application block The Smart Client Software Factory is an integrated collection of tailored software assets that support composite client application development. The collection includes: Patterns that architects and developers frequently use when creating composite smart client applications. How-to topics that contain step-by-step development instructions. Sample application source code in the form of two reference implementations: o The Appraiser Workbench, an application that illustrates an occasionally disconnected client o The Branch Client, an application that illustrates a multi-module, complex, and always connected client A Guidance Automation Toolkit guidance package that automates the developer activities in Visual Studio. Architecture documentation.

40 Smart Client Software Factory (SCSF) 32 Abbildung 17: SCSF Überblick (aus der SCSF Hilfe-Datei Kapitel: Introducing the Smart Client Software Factory ) 7.1 Architektur Wie oben erwähnt, baut die SCSF auf CAB auf und erweitert dabei die CAB Funktionalität. Zusätzlich werden folgende weitere Softwarepaket mit eingesetzt: Composite UI Application Block Enterprise Library Exception Handling Application Block, Logging Application Block, Caching Application Block, and Security Application Block Guidance Automation Extensions Guidance Automation Toolkit Bei der Installation der einzelnen Elemente ist auf die richtige Reihenfolge zu achten, vgl. [AschSCSF] oder in der SCSF-Hilfe Datei das Kapitel Installing Smart Client Software Factory.

41 Smart Client Software Factory (SCSF) 33 Abbildung 18: SCSF Architektur 7.2 Projektstruktur Wie oben erwähnt bietet die SCSF Templates an, wie z.b. beim Erstellen eines SCSF- Projektes. Hier die vom Guidance Automation Toolkit erstellte Projektmappe: Abbildung 19: SCSF Automatische Projekterstellung Durch das Template wird eine Struktur für das Projekt erzeugt, die einem einige Schritte der Projekterstellung abnehmen (im Anhang finden Sie eine kurze Beschreibung zu den erstellten Modulen Infrastructure.Interface, Infrastructure.Library, Infrastructure.Module). Die optional erstellbare Infrastructure.Layout.dll bietet z.b. die Möglichkeit, die schon beim Startvorgang in die Shell plazierten UI-Elemente zu unterscheiden, z.b. für benutzerabhängige Startbildschirme (s. [Pla07] S. 40f.). Durch diese Automationen wird der Entwickler von der oft müh-

42 Smart Client Software Factory (SCSF) 34 samen, aber immer gleichen Zusammenstellung der grundlegenden Module entlastet und kann sich seinen eingentlichen Aufgaben widmen. Abbildung 20: SCSF Projektgerüst 7.3 Features Rezepthilfen Die Dokumentation zur SCSF bietet Hilfen zum weiteren Vorgehen nach der Erstellung des Projektes über das Toolkit an. Hier wird durch die blaue Farbe angezeigt, bei welchen weiteren Vorgängen das Toolkit Erstellungshilfen (Guidance) anbietet. Diese Rezepte werden durch die ergänzenden Programme GAX (Guidance Automation Extension) und GAT (Guidance Automation Toolkit) installiert und verfügbar gemacht. Man kann auch eigene Rezepte hinzufügen, da der Sourcecode mitgeliefert wird. Für den weiter unten aufgezeigten Service Agenten gibt es z.b. eine Rezepthilfe ( Add Service Agent Recipe ), die Hilfe anbietet diesen zu erstellen mit einer Beispielimplementierung Enthalten im Paket Guidance Package with Service Agent Recipe im Smart Client Development Guidance Package (Community Release 1) vom 24. Juli 2006.

43 Smart Client Software Factory (SCSF) 35 Abbildung 21: SCSF Rezept (s. Hilfe-Datei der SCSF - Stichwort Recipes ) Services Die SCSF bietet gegenüber CAB unter anderem folgende weitere Services an: Authentifizierung/Autorisierung Logging Exception-Handling Caching Für selber geschriebene Funktionalität wird das Vorgehen mittels eines ServiceAgenten empfohlen. Dieses Vorgehen bietet die oben erwünschten Vorteile der losen Kopplung, Trennung der Zuständigkeiten und des Einsatzes von WebServices (s. Praxisteil Kapitel: Authentifikation).

44 Smart Client Software Factory (SCSF) 36 Abbildung 22: Service Agents (aus SCSF-Hilfedatei) Pattern Hier eine kurze Übersicht über die eingesetzten Pattern in CAB und in der SCSF, durch die hauptsächlich die Funktionalität des Frameworks erreicht wird: Abbildung 23:Patterns implementiert und unterstützt von Cab und der SCSF

45 Smart Client Software Factory (SCSF) 37 [MSSCSF] Microsoft Patterns and Practices: Overview of the Composite UI Application Block. Microsoft 2007, (CD) Hier sind noch einmal die wichtigsten in der SCSF realisierten Pattern aufgezählt: Inversion of Control oder Dependency-Injection Model-View-Presenter, Model-View-Controller Chain of Responsibility Publish Subsriber Command UI Adapter Builder / Factory (ObjectBuilder) Service Locator (ObjectBuilder) Lifetime Container (ObjectBuilder) Adapter Plugin Dabei wird Inversion of Control durch Dependency-Injection angewendet (zur näheren Erläuterung bzw. zur Unterscheidung der Begriffe s. [New07] und auch [Gre07] ).

46 Enterprise Library 38

47 Enterprise Library 39 8 Enterprise Library Hier nur ein kurzer Hinweis auf die Enterprise Library. Diese ist, wie auch CAB, ein Open- Source Projekt der Patterns&Practices Group von Microsoft. Sie besteht aus mehreren wieder verwendbaren Applikationsblöcken, die dem Entwickler bei der Erstellung von Standardlösungen unterstützen sollen. Diese Bibliothek gibt es inzwischen in der Version 4.0. Hier wird noch die Version 3.1 vom Mai 2007 benutzt, die mit der Version der SCSF-Library 3.0 vom Februar 2007 gut zusammenarbeitet. Folgende Applikationsblöcke stehen in der Version zur Verfügung: Caching Application Block. Developers can use this application block to incorporate a local cache in their applications. Cryptography Application Block. Developers can use this application block to incorporate hashing and symmetric encryption in their applications. Data Access Application Block. Developers can use this application block to incorporate standard database functionality in their applications. Exception Handling Application Block. Developers and policy makers can use this application block to create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications. Logging Application Block. Developers can use this application block to include standard logging functionality in their applications. Security Application Block. Developers can use this application block to incorporate authorization and security caching functionality in their applications. Validation Application Block. Developers can use this application block to create validation rules for business objects that can be used across different layers of their applications. Policy Injection Application Block. Developers can use this application block to implement interception policies that can be used to streamline the implementation of common features, such as logging, caching, exception handling, and validation, across an application. Hier werden vor allem der Exception, der Logging und der Security Block zur Anwendung kommen. In dieser Arbeit geht es aber nicht um die EnterpriseLibrary. Deshalb hier noch der Verweis darauf, wo nähere Informationen zur Library zu finden sind: Enterprise Library Project. Auf der nächsten Seite befindet sich noch eine Grafik, die den Einsatz der Blöcke in CAB verdeutlicht (von msdn.microsoft.com/practices Application Blocks und CAB ):

48 Enterprise Library 40 Abbildung 24: Application Block Coverage

49 Architektur 41 9 Architektur Layers Dies ist die von Microsoft vorgeschlagene Architektur für.net Entwicklungen: Abbildung 25: Architektur.NET ([MSScArch]) Dies ist für normale Architektur gedacht. Wie sieht es aber bei einer Anwendung aus, die hauptsächlich aus Komponenten (Plug-Ins) besteht, die auch noch auf Server- und Clientseite benutzt werden sollen? Plug-In (SOFA) Architektur Im Falle von Plug-Ins müssen die Module selber auch eine Schichtenarchitektur verfolgen. Im Sinne der Separation of Concern ist eine horizontale und vertikale Trennung angezeigt.

50 Architektur 42 Abbildung 26: Separation of Concern ([Gre08]) Auch Newman verfolgt diese Idee, indem er die Architektur seiner Applikation so entwirft: Abbildung 27: Architektur eine Anwendung mit PlugIn-Modulen ([NewSoa])

51 Architektur 43 Als Beispiel sei hier die Patientenverwaltung angeführt, die selber als Service (horizontale Trennung) implementiert ist und die über einen anderen Service die Verbindung zur Datenquelle herstellt und somit (vertikale Trennung) den Datenbankzugriff kapselt Modul und Assembly Als Modul wird in CAB eine Assembly verstanden, die in CAB geladen werden kann und das Interface IModule implementiert. Die Unterscheidung von einer Assembly hat den Sinn darin, dass unter Modul eine unabhängigere Einheit zu verstehen ist als es mit einer Assembly gemeint ist. Diese Module referenzieren sich nicht direkt, sondern kommunizieren indirekt miteinander. So können allein über die Konfiguration Funktionalität per Modul hinzugefügt oder weggenommen werden. Der Eintrag in die Konfigurationsdatei, normalerweise die ProfilCatalog.xml Datei, sorgt dafür, dass die Assembly als Modul behandelt und über den Module- Loader gelesen wird, wobei dann z.b. die Attribute ausgewertet und behandelt werden. Die Implementierung des IModule Interfaces führt dazu, dass zwei Methoden zur Initialisierung des Moduls ausgeführt werden AddServices und Load. Module können UI-Elemente (SmartParts), WorkItems oder auch nur Services enthalten Einbindung der Module und Services Die SCSF-Struktur wurde oben schon betrachtet. Im Anhang sind ihre einzelnen Projekte und ihre Funktionalität näher beschrieben (Infrastructure.Interface, Infrastructure.Library, Infrastructure.Module). Gemeinsame Interfaces bzw. Services werden in einem so genannten Infrastructure Module untergebracht, falls sie nicht außerhalb der Anwendung wieder verwendet werden sollen (z.b. ModuleLoaderService oder der UserSelectionService). Sollen die Services noch in anderen Projekten benutzt werden, dann sind hierfür separate Module zu erstellen. Die Einbindung von Services kann auf 3 Wegen erfolgen, über einen Eintrag in die app.config, deklarativ über das Attribut [Service] per Dependency Injection oder programmgesteuert über die Methode WorkItems.Services.AddNew. Wenn man auch die Shellstruktur abhängig vom Benutzer einstellen will, dann muss auch dieses Layout in einem separaten Modul erstellt werden, was in diesem Prototyp nicht der Fall ist. CAB ist vorrangig als Framework für clientseitige, UI-einsetzende Module auf Window- Forms aufbauend entwickelt worden. Da hier viele Services aber auch ohne UI zur Verfügung stehen müssen (serverseitig), gilt es dies mit möglichst wenig Unterschieden in den Realisierungskonzepten zusammenzubringen, damit nicht Arbeit auf Client- bzw. Serverseite doppelt zu machen ist. Es stellen sich folgende grundsätzliche Fragen: 1. Wie werden Module geladen (wo steht, welche Module geladen werden sollen)? 2. Wann werden Module geladen ( lazy loading )? 3. Wie werden die Abhängigkeiten zwischen den Modulen aufgelöst? 4. Wie wird die Kommunikation zwischen den Modulen ermöglicht?

52 Architektur 44 Außerdem sind noch folgende unterschiedliche Anwendungsfälle zu berücksichtigen: 1) Clientseitig a) Mit GUI b) Ohne GUI (nur Services) 2) Serverseitig a) Ohne GUI (nur Services) Bei der Realisierung ohne GUI sollte nicht auf die Verwendung des OB verzichtet werden, um eine möglichst homogene Entwicklung zu erreichen. CAB bietet die Möglichkeit auch ohne GUI-Elemente über die CAB-Application ein Workitem als ServicesHost zu erstellen und auf Services zuzugreifen CAB-Module ohne GUI-Elemente Durch Ableitung von CabApplication 13 anstatt wie normalerweise von WinApplication kann die Einbindung in die Message Loop und die WinForms UI-bezogenen Services vermieden werden. Damit kann man beim Client auch auf die Einbindung der Unit Microsoft.Practices. CompositeUI.WinForms verzichten. Das Assembly Microsoft.Practices.CompositeUI ist für das WorkItem und der ObjektBuilder zur Verwaltung der Instanzen weiterhin notwendig. Auf der CD findet sich ein CabHost-Projekt CabHostAufruf als Beispiel für den GPSService Aufruf und TestCabApplication zur Erstellung des Services (Als Vorlage diente das Hosting-Beispiel von M. Woloski, s. CD/CAB/Code). 13 s. Klassenhierarchie im Anhang Kapitel 18.7

53 Architektur Abhängigkeiten zwischen Modulen Da die Module möglichst nur über Schnittstellen verbunden sind und die Kommunikation nicht über die direkte Referenzierung von Objekten, sondern über Nachrichten geschieht (Command-, Public-Subscriber-Pattern), wird eine direkte Abhängigkeit untereinander vermieden. Direkte Referenzierungen gehen nur auf Schnittstellendeklarationen und auf die grundlegenden Assemblies von CAB und gegebenenfalls auf andere grundlegende Libraries (EnterpriseLibrary, SCSFContrib). The Composite UI Application Block uses the Object Builder for Dependency Injection. Nevertheless, it does not completely decouple the modules from the framework since the modules use Attributes to control the injection. The Attributes are part of the framework. Therefore a reference to the framework is necessary. Other dependencies arise through sub classing of the ModuleInit class and the use of own sub WorkItems. Additionally, the Dependency Injection implementation is not able to inject primitive types. If a service has to be configured with primitive types, it has to be manually instantiated and passed to the Service Locator. The use of the Service Locator also requires a reference to the framework assembly. With all these dependencies to the framework they are still lower as without using Dependency Injection at all. (aus [Ber07] S. 39). Außerdem besteht noch eine Abhängigkeit zwischen SmartPart und Workspace denn der Workspace hat die Fähigkeit das SmartPart (visuelles Element eines Workitems) darzustellen. Diese Abhängigkeit ist von Hause aus durch eine Kenntnis des Namens des Workspaces implementiert. Durch den Einsatz eines ShellExtensionService lässt sich diese Abhängigkeit vermeiden (s. Abb. Abbildung 29: UIExtension Sites über einen Shell Extension Service angesprochen (s. [Szp06]).) Kommunikation zwischen Modulen Die statische Kommunikation zwischen den Modulen kann durch Ansprechen der jeweiligen Services über den OB per DependencyInjection oder den ServiceLocator geschehen. Die dynamische Kommunikation zur Laufzeit geschieht über den Gebrauch des Event Broker Systems oder die Benutzung des Command Patterns. Für eine lose gekoppelte Kommunikation ohne die Anforderung, dass auf eine Anfrage sofort eine direkte Antwort gegeben wird, ist der Event Broker das geeignete Mittel ( fire and forget ). Damit kann der Sender des Events allerdings auch nicht wissen, wer der Empfänger der Information ist (s.a. Anhang). Ist dagegen eine sofortige Antwort notwendig bzw. muss man den Auslöser kennen, dann ist das Command Pattern angebracht. Der Command kann direkt an den Event eines Controls (z.b. Click-Event) gebunden werden. Hier kommt natürlich auch eine Service Implementierung in Frage, wenn es sich um einen Foundational Service handelt ohne UI-Bezug. Dieser hat eine größere Abhängigkeit als der Event-Broker Mechanismus, z.b. vom Service Interface. Dafür bekomme ich aber eine Antwort: die Service Implementierung ist also eher in dem Sinn zu sehen: Tue etwas für mich und antworte mir!.

54 Architektur 46 Ein weiterer Unterschied der beiden Mechanismen ist der, dass man bei einem Event entscheiden kann, in welchem Thread der Event ausgeführt wird. Für die Beeinflussung des UI ist die Option Thread.UserInterface als Angabe beim Event-Handler notwendig.

55 Lösungskonzept Lösungskonzept Hier beziehe ich mich auf die Arbeit von Mario Szpuszta ([Szp06]), der den Prozess der Erstellung einer SmartClient-Anwendung darstellt. Aufgrund der Kürze der Arbeit kann hier nicht der ganze Prozess verfolgt werden, aber die grundsätzlichen Ideen sollen hier berücksichtigt werden. Hier handelt sich es im Sinne von Szpuszta um die Erstellung eines Prototypen (s. [Szp06] S. 13) 14. Als wichtigste Anfangspunkte bei der Entwicklung nennt Szpuszta die Überlegungen zum Shelldesign und den Infrastrukturdiensten, dass sind Dienste, die von allgemeinem Interesse sind Shelldesign Für das Shelldesign gibt es Beispiele und Überlegungen von Newman ([NewDesign]). Da es bei einem existierenden Modul eine Auswahl in einer Buttonleiste für den Aufruf von weiteren (Teil-)Modulen schon gibt, es darüber hinaus für die Zukunft interessant werden wird auch eine Baumstruktur zur Auswahl zur Verfügung zu haben (Patientenpfade, Order&Entry), wird hier die Outlookvariante für den linken Teil des Navigationsbereiches gewählt, eben durch die Anzeige einer Outlookbar. Die Auswahl der Module wird in einer Outlookbar über Buttons ermöglicht. Dort kann dann eine Baumstruktur unterhalb eines Outlookbarbuttons dargestellt sein bzw. auch keine weiteren Elemente, falls es das Modul nicht erfordert. Da es des Weiteren einer Realisierung eines Moduls mit Dockable Windows schon gibt, bietet sich dies für den Arbeitsbereich an. Je nach Modul kann man die Dockability der Windows benutzen. (Hier bestände auch die Möglichkeit, dies von bestimmten Rollen abhängig zu machen oder einen Expertenmodus einzuführen). Der Zugriff auf die Shell-UI geht über einen Service zur Entkopplung zwischen den in der Shell sich darstellenden Modulen und der Shell selber. Dieser Service ist hier eng mit dem Shelllayout verbunden. Eine andere Möglichkeit wäre, diesen Service in ein eigenes Modul auszulagern. Wenn dieser Service auch in andern Applikationen genutzt werden sollte, ist diese Vorgehensweise von Vorteil. Dies könnte für eine spätere Entwicklungsphase notwendig werden. Dann müsste allerdings noch ein Vertrag zwischen Shell und Shellextension- Service etabliert werden (s. [Szp06] Checklist 9). In der folgenden Abbildung ist das Shelldesign mit den verschiedenen Workspaces und Shell- Extension Sites dargestellt 14 Zur Installation der Implementierung beachten Sie bitte die Datei Installation.txt im Projektordner Infrastructure/Shell/Dokumentation.

56 Lösungskonzept 48 Abbildung 28: Shelldesign der Implementierung Zum Shelldesign gehören die Erweiterungspunkte, die CAB anbietet, an denen sich jedes Modul mit eigenen Elementen einhängen kann. Im Gegensatz zu den Workspaces sind diese Sidts immer vorhanden und können eben nur erweitert werden. Wie oben genannt. sind dies die UIExtensionSites Menü, Toolbar und Statusbar. Um eine möglichst große Unabhängigkeit zwischen den Modulen und der Shell zu erreichen, wird die Verbindung zur Shell über ein Interface als Service hergestellt (IShellExtensionSer-

57 Lösungskonzept 49 vice). Die Module kennen nicht die Shell direkt, sondern erweitern über Methoden des Services den Desktop. Hier das Diagramm dazu: Abbildung 29: UIExtension Sites über einen Shell Extension Service angesprochen (s. [Szp06]) Infrastruktur-Services Bei den Services wird oft unterschieden zwischen Services von allgemeinem Interesse (Infrastrukturservice) und speziellen, modulbezogenen Services. Die zu realisierenden Services von allgemeinem Interesse sind folgende: Authentifikation (WCF 15 -Service) Autorisation Kontextwechsel (teilweise implementiert) ModuleLoader Logging/Trace Viewer Persistenz/Database (hier nur Testdaten) Konfiguration (WebService) Utilities: MessageBox, Help Service, SplashScreen, AboutView Entity Translator (nicht implementiert) WorkItems/Module/Services identifizieren (Use cases) Nach Szpuszta gibt es zwei Wege um WorkItems zu identifizieren, entweder über UseCases oder über Business Entities. Die Orientierung allein an UseCases für Workitems hat sich inzwischen in der Praxis als nicht ganz tauglich erwiesen: 15 WindowsCommunicationFoundation: Vertragsbasierende Kommunikationsplattform von Microsoft

58 Lösungskonzept 50 I mean, they said the Module represented a Use Case. Since August 2007, they changed their story and said, well, that didn t work. It seems that the Use Case pattern was too inflexinonagilicalmonoconceptual. ([Joh08]) 16 Da es sich hier um eine im Umfang sehr eingeschränkte Testversion handelt, kann man bei diesem Prototypen jedoch von UseCases ausgehen. Diese sind hier dargestellt anhand unterschiedlicher Rollen von Benutzern: 16 smart-client-design-pattern

59 Lösungskonzept 51 Integrated Desktop: Use Cases System Hilfe aufrufen * * * * Alle * Patient suchen «verwendet» Arbeitsliste erstellen * Patientenverwaltung «verwendet» * «verwendet» «verwendet» * Stationsbelegung anzeigen * Drag&Drop Stationsbelegung->Arbeitsliste Arzt * Patiententermin * erstellen * * Drag&Drop Arbeitsliste->Terminplan * * LogViewer aufrufen Administrator Module: Abbildung 30: UseCases SCSF-Prototyp

60 Lösungskonzept 52 Fast jeder UseCase wird in einem eigenen Modul erstellt und jeder UseCase resultiert in einem eigenen WorkItem. Es gibt kein Subworkitem, alle WorkItems hängen direkt unter dem RootWorkItem, da sie nicht voneinander abhängen. Dadurch sind die einzelnen Module wieder verwendbar, einzeln konfigurierbar und auswählbar. Die Patientenverwaltung ist kein UseCase, sondern ein Service, der kein WorkItem benötigt, d.h. ein reines Foundation-Modul: A foundational module is a module that either provides services to the shell and other modules, provides a layout, or both. It does not implement a use case or contain a WorkItem. (aus SCSF-Hilfe Datei). Root Stationsbelegung Terminplanung Patientenverwaltung Patientensuche Log-Viewer Befund-Viewer Abbildung 31: WorkItem-Hierarchie

61 Module und Services Module und Services Das Hauptziel der GUI in dieser Anwendung ist die Integration von unterschiedlichen Funktionsteilen in einer Oberfläche durch die SmartClient Architektur. Damit sollen existierende Win32-, Visual Basic- und HTML/Web-Anwendungen für den Anwender als ein Produkt erscheinen (vgl. die Bedeutung des Composite Interfaces - Harness in [CommSee]: The client is known as the Harness because it acts as a container for multiple UI components known as WinParts. ). Hier ist eine Übersicht der Module und der Infrastruktur des Projektes. Die Shell Assembly beeinhaltet den Einstiegspunkt nämlich die ShellApplication.cs Datei. Hier liegen projektübergreifenden Objektinterfaces und Entities als Interfaceimplementationen, z.b. IPatient und Patient: IPatient. Die Struktur und viele Units dieses Ordners stammen aus der SCSF und werden ergänzt durch eigene Services, Views und anderem. Hier sind die einbindbaren Module als eigene Assemblies abgelegt. Sie werden über den ProfileCatalogService konfigurierbar eingebunden Hier sind die WCFHosts bzw. alternativ zu verwendende WebServices. Abbildung 32: Übersicht der Module im Projektmappenexplorer von Visual Studio

62 Module und Services Verwaltung Unter den Modulen der Verwaltung sind die Services zusammengefasst, die nicht direkt mit dem Geschäftsprozeß zu tun haben, sondern nur zu dessen Unterstützung bzw. Vorbereitung gebraucht werden Login (Authentifikation und Autorisation) Zum Themenkomplex Login gehören die Problemkreise der Authentifikation ( Wer bin ich? ) und der Autorisation ( Was darf ich? ) auf die im Folgenden näher eingegangen wird. Sicherheitsaspekte sind im Gesundheitswesen von besonderem Interesse. Die Arbeit mit Patientendaten unterliegt einer besonderen Sicherheitsstufe. Hier hängt die Höhe der Sicherheitsanforderungen davon ab, ob es sich um einen externen(webportal)- bzw. internen (Intranet)- Datenverkehr handelt. Da es schon erste praktische Anwendungen für die beiden Arten des Datenverkehrs (extern als Einweiserportal für Ärzte von außerhalb der Klinik) gibt, müssen auch für die unterschiedlichen Sicherheitsanforderungen entsprechende Realisierungen in der Software möglich sein und mitbedacht werden. Des Weiteren ergibt sich aus der Realität, da es sich um eine Verbindung von WebApplication und.net Applikation handelt, unterschiedliche Gefahren allein aus der unterschiedlichen Technik und darauf muss entsprechend reagiert werden. Es ist aber nicht das Thema dieser Arbeit darauf im Einzelnen einzugehen. Nähere Informationen dazu gibt es z.b. auf der Patterns & Practices Website ( Component: Authorization service Description: An interface Create an out-of-process component that (or gatekeeper) to runs under a security context that can the authorization data How to use: access the authorization store. Using an out-of-process component allows you to authorize access to the store by checking to see whether the access occurs by the account specified. This allows you to prevent other users from accessing the store. Alternatively, you can build an XML Web service for central reuse. This provides the greatest interoperability. Remember to protect the communication channel between the authorization service and the authorization framework. ([MSDAMAZ], S. 50 Table 2) Authentifikation Die Umsetzung des Authentifikationsservice ist als WebService mit der WCF realisiert. Dadurch kann sowohl eine ASP.NET- wie auch eine WinForms - Anwendung diesen Service nutzen und somit eine Wiederverwendbarkeit gewährleisten. Als Speicherort für die Benutzerdaten dient eine LDAP-Datenbank, wobei die Umsetzung davon nicht abhängen soll. Dazu wird ein Interface benötigt, das 3 Methoden definiert: Authenticate(), IsInRole() und GetRoles() (vgl. [Löw05] Appendix B).

63 Module und Services 55 Gespeichert werden die Benutzerdaten in einem CustomPrincipal-Objekt, dass das Interface IPrincipal implementieren muss und den normalen Windows-Principal ersetzt. Äquivalentes gilt für die Rollen des Benutzers. Die Möglichkeit des Cachings der Rollen soll berücksichtigt werden. Die Form wird in die Applikation mit eingebunden. Leider ist ein Benutzerwechsel, was einen Rollenwechsel beinhalten kann und damit ein erneutes Laden der Module erfordert, nicht im laufenden Betrieb des Programmes möglich. Dies ist eine Beschränkung von.net (s. [PazCabIso] 17. Weitere Recherchen ergaben allerdings, dass es hier doch noch zu evaluierende Möglichkeiten gibt s. [Ric06] S. 550, Entladen einer AppDomain ). Die Funktionalität wird anhand einiger Serviceschnittstellen abgebildet, dazu gehören die folgenden Schnittstelle: IUserManagerService, IAuthenticationService, IRoleService, IUser- SelectorService. Wie man einen Service in SCSF erstellt steht z.b. in den Developer Labs4, den Beispielanwendungen zur SCSF für Developer (weiter Beispiele gibt es für Architekten). 18 Das Interface IUserManagerService ist als Operation-Contract innerhalb einer WCF- Vertragsvereinbarung realisiert. Die Vorteile der WCF sind in diesem Zusammenhang, dass z.b. das Binding zwischen Server und Client ausgetauscht werden kann, z.b. statt SOAP per Http-Protokoll (http-binding) direkt über TCP Sockets (NetTcpBinding) zu gehen oder den Webservice gegen einen anderen auszutauschen, der den selben Operation-Contract erfüllt. So ist der Service unabhängig gegenüber einem bestimmten Protokoll, einer Codierung und der hostenden Umgebung (IIS 19, WindowsService etc.). Hier der Auszug aus dem C# - Code über die Vertragsvereinbarung der IUserManagerService Schnittstelle: /// <summary> /// Service zur Authentifikation eines Benutzers als Vertrag, s.wcf /// </summary> [ServiceContract(Namespace = " public interface IUserManagerService { /// <summary> /// Authenticates the user. /// </summary> [OperationContract] bool Authenticate(string applicationname, string username, string password); /// <summary> /// Verifies user role's membership. /// </summary> [OperationContract] bool IsInRole(string applicationname, string username, string role); } /// <summary> /// Returns all rolelist the user is a member of. /// </summary> [OperationContract] string[] GetRoles(string applicationname, string username); 17 Logout - How to implement it. (CD) und CAB: How to unload/reload a module (CD) 18 Aus den Beispielen zur SCSF: HandsOnLabs-Developer (s. CD/SCSF/Code). 19 IIS: Internet Information Services WebServer für Microsoft Windows Systeme

64 Module und Services 56 Das Metaattribut [ServiceContract] sorgt dafür, dass der Service dem DependencyInjection System zur Verfügung steht. Das Attribut [OperationContract] zeichnet die Funktionen als Vereinbarung für eine Vertrag über eine Operation in der WCF aus. Der Authentifizierungs-WebService ist als WCF-Service implementiert, 20 orientiert am aktuellen Paradigma von Softwareentwicklung (jedenfalls wie Microsoft es sieht). From Objects to Services 1980s 1990s 2000s Object-Oriented Polymorphism Encapsulation Subclassing Component-Oriented Location Transparent Tight Coupling Runtime Metadata Service-Oriented Message-based Schema+Contract+Policy Broad Interop Abbildung 33: From Objects to Services (.Net Framework) 20 WCF: s. z.b. Löwy Juval, Programming WCF Services, O Reilly,

65 Module und Services 57 Im folgenden ist der Login-Service schematisch dargestellt: (vgl. [Löw05]Appendix B) Abbildung 34: Login Service (Schematische Darstellung)

66 Module und Services 58 Der Ablauf der Authentifizierung mit den beteiligten Komponenten ist hier im Sequenzdiagramm dargestellt: Abbildung 35: Sequenzdiagramm Authentifizierung Autorisation Hier geht es um die Frage: Was darf ich tun?. Dies ist davon abhängig, in welcher Rolle ich mich am System angemeldet habe. Durch die Rolle werden bestimmte Berechtigungen gebündelt und die Verwaltung der Berechtigungen vereinfacht. Im Kapitel Sicherheit wird die Autorisation näher behandelt Konfiguration Für die Konfiguration der Anwendung sind in der Regel die Dateien app.config (Enterprise- Library) und Profile.xml zuständig. In der Profile.xml können die zu ladenden Module mit ihren Abhängigkeiten und das rollenspezifische Zugriffsrecht abgelegt werden Laden von Modulen und Services Loading modules is an expensive operation because it entails loading assemblies, creating services, registering WorkItemExtensions, and calling ModuleInit methods. ([WolLoad]) In almost all cases (the vast majority from my experience so far) the performance of this implementation is enough, but there are always exceptions. For example, when we ported CAB into the Compact Framework for mobile development, performance was a key requirement. Mobile devices normally don't have the same memory and CPU power desktops have and reflection was a big tax. The solution was to create a tool (2 actually: CABGen and OBGen) that "compiles" the dependencies and dynamically generates an assembly with all the required relationships. Enabling these tools required minor changes in CAB & Object Builder (a code diff between the 2 versions will reveal those). The end result is that the code runs faster because everything is resolved upfront, the price you pay is the flexibility of loading modules on the fly. However, the system works in hybrid modes too, meaning that you can mix modules that have been "CAB and OBgen'ed" with standard ones. So you still have the choice of only optimizing those that are critical for your performance requirements. Eugenio Pace: Notes on (extreme) Performance requirements for CAB, August 23, 2006

67 Module und Services 59 Die Information, welche Module bzw. Services beim Start des Programmes geladen werden sollen steht in der Datei ProfileCatalog.xml. Der Ablauf beim bzw. vor dem Laden der Module ist wie folgt: Before modules are loaded (in the CAB sense, at least), for each module listed in the ProfileCatalog.xml file, the CAB loads the assembly (in the.net Assembly.LoadFrom sense) and reflects over all the public types found on the assembly, creating simple lists of types it cares about: types that implement ModuleInit, types with ServiceAttribute tags, types that extend WorkItem, and other things. Armed with this metadata (including assembly-level attributes declaring CAB module dependencies), it builds a dependency-ordered list of modules to load and loads them one by one. For each module, it tries to fill the Services collection with all its services before initializing the module classes but it does this by simply iterating over all the types with a [Service] attribute, it doesn t solve any dependency graph of those services first. So if the first class in the list depends on another service, the CAB will throw. (aus [Ove06]). In einer neueren Version werden auch Abhängigkeiten aufgelöst (s.u. DependenModuleLoader). Es sind zwei Methoden, die für das Laden ursprünglich in CAB zuständig waren, eine für die Information über die zu ladenden Module (ModuleEnumerator()) und eine zweite, die diese Information zum Laden eben dieser Module benutzt ModuleLoader(). Dabei liefert der Enumerator die Information in der Form von IModuleInfo. In einer neueren Version wurde die IModuleInfo-Schnittstelle erweitert, um z.b. Abhängigkeiten unter den Modulen oder Sektionen darstellen zu können (IDependentModuleInfo). Der neue Enumerator erzeugt aus V1 oder V2 Xml-Dateien eine Liste von IModuleInfo Elementen (XmlStreamDependentModuleEnumerator). Diese werden vom DependentModuleLoader für das Laden der Module benutzt (s. auch Klassendiagramm im Code der Infrastructure.Library). Abbildung 36: Sequenzdiagramm Module Loader ([Wils06]) Damit der Zugriff auf die ProfileCatalog.xml-Datei flexibel ist und möglicherweise noch in einen grösserene Konfigurationszusammenhang gestellt werden kann, bietet sich ein WebService zur Realisation an. Hier bietet die SCSF schon einen Service, den WebServiceCatalog Service. Dieser muss nur noch konfiguriert und durch das entsprechenden WebService- Backend implementiert werden. In der SCSF-Referenzimplementierung (BankBranchWorkbench) ist dies so realisiert. Im Prototypen ist dafür ein WCF-Service implementiert, der den Einsatz des IIS unnötig macht.

68 Module und Services 60 Das verzögerte Laden von Modulen erst dann, wenn sie gebraucht werden, kann durch folgende Ergänzung zu einem Serviceattribut erreicht werden: [Service(typeof(IMyService), AddOnDemand=true)] By doing this we get significantly different behavior in the CAB module load. Instead of trying to instantiate that type and add the instance to the Services collection, the CAB puts a placeholder for it into the Services collection. It doesn t have to worry about any further service dependencies of this service because it s not actually creating it; so the CAB can merrily cycle through this list creating placeholder after placeholder, fully populating its Services collection. When your code actually wants the service, the CAB can succesfully generate the dependencies on demand because it has all the necessary info to do so in the Services collection. (aus [Ove06]). Hier ist ein Ausschnitt aus der ProfileCatalog.xml-Datei zu sehen: <Section Name="Apps"> <Dependencies> <Dependency Name="Infrastructure" /> <Dependency Name="Services" /> </Dependencies> <Modules> <ModuleInfo AssemblyFile="SCSF_Diplom.LogViewerModule.dll" > <Roles> <Role Allow="Administrator"/> </Roles> </ModuleInfo> In diesem Teil der Sektion Apps (Applications) wird über das Tag <Dependencies> eine Abhängigkeit der folgenden Module von den unter <Dependency Name> genannten Modulen konfiguriert. Dem Moduleloader wird damit mitgeteilt, dass zuerst die Module Infrastructure und Services zu laden sind, da das Module LogViewer von diesen abhängig ist. Durch das <Role Allow> Tag kann man die Berechtigungen auf ein Modul über eine Rollenbezeichnung einstellen Kontext-Service Als Kontextservice ist hier nur die Auswahl des Patienten ausgeführt. Im Referenzbeispiel der SCSF-Contribution ist erläutert, was der Vorteil einer solchen Implementierung gegenüber einer Speicherung im WorkItem-State bedeutet: Why didn t we use the WorkItem state to store the current customer? We wanted to have more control over the context, hence we decided to implement a custom service named ContextService that will provide a CurrentCustomer property. We added this context service to each child workitem as shown below. workitem = WorkItem.WorkItems.AddNew<ControlledWorkItem<CustomerWorkItemController>>(key); ContextService context = workitem.services.addnew<contextservice>(); context.currentcustomer = e.data;

69 Module und Services 61 The ContextService will be a singleton on the context of the new controlled Customer- WorkItem. We will have access to the customer in the workitem environment (views, subworkitems, etc). (aus der Erläuterung zum Bsp. BankTeller des SCSFContrib Projektes - Scsfcontrib-WPFSolution) Logging-Service Abbildung 37: LogViewer Für das Logging wird ein Objekt der EnterpriseLibrary, das LogEntry-Objekt, verwendet. Mit der entsprechenden Konfiguration in der app.config ist dies ein schnelle, ausreichende und erweiterbare Möglichkeit, zentrale Informationen zu beobachten. Des Weiteren wird hier auf den LogRecorder von Berchtel zurückgegriffen, der auf der Patterns&Practices Seite 22 zur Verfügung gestellt wird MessageBox-Service Für die Anzeige von Messages gibt es einen eigenen Service, der den Zugriff auf die Messagebox der Standart.NET Messagebox vereinfacht und erweitert Visualizer-Service Schon mit Cab wurde ein Visualizer integriert, der es ermöglich die geladenen Workitems zu visualisieren, um einen Überblick über diese zu behalten. Über ein eigenen Workitembaum hat der Visualizer Zugriff auf die anderen Workitems und kann diese durchlaufen und Informationen über sie anzeigen. Alles das, wozu das Workitem als Container dient, kann dabei visualisiert werden, z.b. auch die eigenen Services. Man kann auch seinen ganz eigenen Visualizer schreiben und den eigenen Typ beim Start der Applikation dem Programm zuweisen. An derselben Stelle kann man den Visualizer deaktivieren. public class MyProgram : ShellFormApplication<MyWorkItem, MyShell> { [STAThread] public static void Main() { 22 Die Testsuite mit dem LogRecorder ist zu finden unter CabExtensions/TestSuite

70 Module und Services 62 MyProgram p = new MyProgram(); p.visualizertype = typeof(myvisualizer); p.run(); } } (aus der ShellApplication.cs - Datei) David Platt hat z.b. einen Event-Visualizer realisiert, der auch hier implementiert ist ( Konfiguriert wird der Visualizer in der App.cfg. (s. auch SampleVisualizer in Cab). Abbildung 38: Cab Visualizer View Splash-Screen Da das Laden der Module und sonstige Vorarbeiten einige Zeit dauern können, ist es üblich, einen Splash-Screen dem Benutzer beim Start des Programmes anzuzeigen. Die hier implementierte Variante benutzt dazu einen eigenen Thread. Außerdem ist ein Fade-In und ein Fade-Out realisiert. 23 Andere Arten von Splahscreens sind z.b. in [Ber07], [Hau06] und [Sim07] zu finden. Der Screen ist nicht als eigener Service bzw. eigenes Modul angelegt, da er bis jetzt nur in dieser Anwendung zum Einsatz kommt Siehe auch Juval Löwy, IDesign WinFormsEx - Control Library. 24 Anmerkung: Die Erstellung des Splashscreens beinhaltet einige Herausforderungen aufgrund des Threadings, der Aktualisierung des Screens während der Anzeige und aufgrund der Steuerung vom Hauptthread aus.

71 Module und Services Sicherheit Auf den i.allg. wichtigen Aspekt der Sicherheit gehe ich nur kurz ein. Die notwendige Einbindung in ein übergreifendes Sicherheitskonzept wird hier nicht betrachtet. Die Sicherheitsanforderungen betreffend geht es um die Fragen, wer ist der Benutzer und was darf er tun (hier am Beispiel einer Webanwendung aufgezeigt): (aus ErhoehenDerSicherheitVonWebanwendungen) CAB orientiert sich an der Sicherheitsimplementierung des.net Frameworks: Die.NET Framework-Benutzersicherheitsimplementierung heißt rollenbasierte Sicherheit. Die Codesicherheitsimplementierung heißt Codezugriffssicherheit. Die Möglichkeiten der rollenbasierten Einflussnahme kann also auf Modul- und auf Codeebene zum Tragen kommen. Cab bietet, wie oben erwähnt, die Möglichkeit, das Laden von Modulen über eine Konfiguration von der Zugehörigkeit zu einer Rolle abhängig zu machen. Weiterhin kann durch Attribute auf Codeebene für einzelne Methoden entschieden werden, wer diese ausführen darf. Bill Simser verwendet hierzu den Action Catalog, um auf Codeebene rollenbasierte Sicherheit zu implementieren ([SimActCat] oder 25 ). In der Reference Implementation wird die Funktion IsInRole dazu benutzt: if (amount >= &&!Thread.CurrentPrincipal.IsInRole("BranchManager")) { View.ShowMessage(Resources.UserNotAuthorizedMessage); View.ShowApproval(true); } Hier kann allerdings auch der Object -Builder ins Spiel kommen, wenn man auf Methodenebene ein Attribut mit Rollenunterscheidung einführt, auf das der OB entsprechend reagieren kann (s. [Szk06] ). Szupka weist darauf hin, dass auch beim Zusammenstellen der WorkItems zu Modulen Sicherheitsüberlegungen eine Rolle spielen, eben wenn für WorkItems unterschiedliche Sicherheitstufen notwendig sind. 25 SCSF KnowledgeBase Security

72 Module und Services 64 Das Framework bietet die Möglichkeit den Application-Blocks der EnterpriseLibrary zu benutzen, sowie den Cryptography- und den Security- Block Infrastruktur Unter dem Begriff Infrastruktur werden in der SCSF Dinge subsummiert, die von allgemeinem Interesse sind, d.h. die z.b. von mehreren anderen Modulen benutzt werden Patientenverwaltung Dieses Modul dient als Servicemodul zur Kapselung von Funktionen der Patientenverwaltung. Hier wurde allerdings nicht der ObjectBuilder zur Objekterzeugung verwendet, sondern der Weg über einen Patientenverwaltungsservice gewählt. Dazu dienen auch die Assemblies KisFr.Entities und KisFr.Interfaces im Ordner Common. Dadurch, dass die Interfaces von ihrer Implementierung in den Entities getrennt sind, wird eine direkte Abhängigkeit von der Implementierung vermieden. Über das Dependency Attribut in der Konfigurationsdatei wird die Abhängigkeit der UI- Module Patientensuche und Stationsbelegung von diesem Modul berücksichtig User Interface (UI) In diesem Abschnitt werden die Module, die grafische Elemente enthalten, erläutert. Dabei werden noch weitere Libraries zur Unterstützung verwendet: - Cab Extensions (vor allem für den OutlookBarSmartPart 26 und den Visualizer ) - DockManager (Dock Panel Suite von Weifen Luo für die Floating Windows) - The HelperTrinity (Hilfe für Exception-, Argument- und Eventbehandlung) Patientensuche 26 Die Outlookbar wird jetzt im Projekt Scsf Contrib geführt.

73 Module und Services 65 Im Folgenden ist das UserInterface für die Patientensuche dargestellt: Abbildung 39: Patientensuche View Funktion Die Realisierung der Patientensuche ist als ein modales Fenster gedacht, über das in der zentralen Patientenverwaltung ein Patient gesucht werden kann nach bestimmten Kriterien, z.b. Nachname und eine Liste von Treffern zurückbekommt. Dann muss man aus dieser Liste den gewünschten Patienten auswählen und das Fenster schließt sich. Der Patient wird dann in die Navigationsleiste übernommen zur weiteren Bearbeitung bzw. zur Bereitstellung, um mit ihm weitere Aktionen durchzuführen (Terminvergabe etc.) Problematik Es ist möglich, dass der Benutzer die Patientensuche aufruft, während er an einer anderen Stelle im Programm Diagnosen für einen anderen Patienten verschlüsselt. Bei einem Wechsel des Patienten sollte die Diagnoseerstellung erst abgeschlossen bzw. abgebrochen werden, um nicht eine Verwirrung beim Arbeiten zu erzeugen. Nun handelt es sich bei den Modulen Diagnosenerstellung und Patientensuche eben um verschiedene Module, die lose gekoppelt sein sollen. Die Patientensuche will daher gar nicht wissen, welche anderen Module geladen sind und welche anderen Module an der Patientenauswahl interessiert sind. Es will nur einen Patienten auswählen und diese Auswahl bereitstellen, so dass evtl. von einer Patientenwahl abhängigen Module sich aktualisieren können. Wie oben beschrieben reicht aber eine Aktualisierung nicht aus und wie oben beschreiben ist es notwendig, dass ggf. ein anderes Modul ein Veto einlegen und/oder eine Aktion verlangen kann bevor der Event(hier Patientenwechsel) durchgeführt werden darf. Dies würde z.b. durch eine Nachfrage an den Benutzer geschehen, ob er die eingegebenen Diagnosen speichern oder die Arbeit abbrechen will. Eine Benutzung des Event-Publish-Subscriber System reicht deshalb nicht aus (s.a. [Pla07] Kapitel 7)!

74 Module und Services Lösung (ActionCatalog Service ) Für die Lösung des Problems bietet SCSF den Action Catalog Service an, der es ermöglich eine Durchführung einer Aktion mit einer Bedingung zu verknüpfen. Die Aktion Auswahl eines Patienten wird in einen Katalog gestellt. Ein daran interessiertes Modul kann nun diese Aktion mit einer action condition versehen. Abbildung 40: Fields and methods of the ActionCatalog class (aus SCSF Contrib) Der Ablauf bei der Prüfung einer Aktionsbedingung ist im folgenden Bild verdeutlicht: Abbildung 41: Action Catalog Verhaltensschema ([Pla07] S. 141)

75 Module und Services 67 Ein Diagnoseerstellungsmodul kann jetzt über eine eigene Methode, die die Schnittstelle IActionCondition implementiert, zu dem CatalogService Patientenwechsel die Prüfung einer Bedingung fordern. Diese Bedinung wird erst abgeprüft, bevor die Aktion duchgeführt oder abgebrochen wird. D.h. in unserem Falle soll erst die laufende Aktion der Diagnoseerstellung durch Rückfrage an den User (sollen die Eingaben gespeichert oder verworfen werden) abgeschlossen werden, bevor der Patientenwechsel wirklich vollzogen wird. Im praktischen Beispiel wird die Auslösung der Prüfung des Action Catalogs durch eine Messagebox angedeutet Stationsbelegung Abbildung 42: Stationsbelegung View Die Auswahl eines Patienten für die Terminvergabe soll auch über eine Stationsbelegung (Überblick über die auf eine Station aufgenommenen Patienten hier mit der KostenstellenId ) möglich sein. Dazu dient das Stationsbelegungsmodul. Dieser SmartPart wird im DockPanel als TaskView-Window angezeigt (s. Abbildung 28: Shelldesign der Implementierung). Von hier aus können per Drag&Drop Patienten in die Arbeitsliste oder in den Terminplaner gezogen werden. An dieser Stelle sind mögliche Sub-WorkItems in der Navigationsleiste (Outlookbar) angedeutet, wie z.b. die Stammdatenanzeige (Adresse, Krankenkasse, Hausarzt u.a.m. des Patienten) oder die Patientenhistorie (Historie über alle Patientenaufenthalte in der Klinik).

76 Module und Services Terminplan Abbildung 43: Terminplanung View Mit diesem Business-Modul wird die Terminvergabe für Patienten angedeutet Aus der Stationsbelegung bzw. der Arbeitsliste kann per Drag&Drop ein Termin für einen Patienten erstellt werden. Es findet keine Speicherung der Termine statt! Dieses Modul wird über den ISmartPartInfoProvider als DocumentView konfiguriert und im DockPanel angezeigt. An diesem Modul werden kurz exemplarisch die wichtigsten Punkte bei der Erstellung eines Moduls erklärt. Modul ist ein.net Projekt, das getrennt von anderen Modulen entwickelt werden kann. Verbindungen zu anderen Modulen sind natürlich notwendig, z.b. wenn das Modul in der Shell angezeigt werden soll und evtl. Menüeinträge hinzufügt. Dies geschieht aber nie direkt, sondern nur über Interfaces. Die Verbindung zur Infrastructur geschieht z.b. nur über das Infrastructur.Interface. Die anderen Libraries sind nicht referenziert! Hier ein Bild von dem typischen Aussehen einer in der SCSF erstellten Assembly:

77 Module und Services 69 Abbildung 44: Projektmappenansicht des Terminplan-Modules Bei der Erstellung eines typischen Moduls sind folgende Schritte notwendig: 1. Über ein Recipe wird das Business-Module erstellt, zugleich mit einem Interface und auch einem Testmodulgerüst. So entstehen u.a. Modul.cs, ModulController.cs und das Gerüst unter dem Ordern Views hier wurde eine Interface Assembly erstellt für die Terminplanerfunktionalität: public interface ITerminplan { void ShowTermine(ITermine termine); void LoadTermine(out ITermine termine); void SaveTermine(ITermine termine); } 2. Modul in ProfileCatalog.xml eintragen, als Hinweis für die SCSF das Modul zu laden. 3. Dort wird ein Workitem Controller erstellt und die Run-Methode aufgerufen. (Das zusätzliche ControlledWorkItem wurde von den SCSF-Entwicklern eingeführt, um die Verantwortlichkeiten der Elemente klar zu trennen: die Business Logic gehört ins Controlled WI - genauer in die ModuleController Class -, die Containerfunktionalität gehört zum normalen WI. ) 4. Die SCSF stellt für den Controller vier Methodenrümpfe in der Run-Methode bereit: public class ModuleController : WorkItemController { public override void Run() { AddServices(); ExtendMenu(); ExtendToolStrip(); AddViews(); } - Hier werden z.b. die Services zur Anzeige in der Shell hinzugefügt: // Service für die Erweiterung der Shell holen shellextension = WorkItem.Services.Get<IShellExtensionService>();

78 Module und Services 70 - Menüitems zur Shell hinzugefügt IMenuItem menuitem = uielementcreationservice.createmenuitem("terminplan", Resources.ModuleIcon.ToBitmap()); shellextension.addmenuitemtomenuitemgroup(infrastructure.interface.constant s.uiextensionsitenames.viewmenuitem, menuitem); - Der Eintrag für die Navigations-(Outlook-)bar hinzugefügt // Verbindung zur Shell über Service OutlookItem.OutlookItem outlookitem = WorkItem.Items.AddNew<OutlookItem.OutlookItem>("OutlookItem"); - Methoden für das Aufräumen nach der Anzeige des SmartParts und den Aufruf des eigentlichen Views 5. Der View (ist hier ein aktiver View, da über Drag&Drop direkt Daten in den View gelangen) wird über das Model-View-Presenter-Pattern (s. [Gre07], [New07] und [RazMVP]) implementiert. Dazu gehören die Klassen IModulView.cs (Verbindung zwischen View und Presenter), ModulViewPresenter.cs (der Presenter) und Modul- View.cs (den eigentlichen View). Das Model, die Repräsentation der Daten, kann nicht automatisch erstellt werden und ist hier nur in eine Richtung über Drag&Drop implementiert das Model ist hier sogar verteilt über andere Module (Patientensuche, Stationsbelegung) in der Patientenverwaltung. Für dieses kleine Testprojekt ist das MVP-Pattern fast etwas zu komplex Nachrichten und Alarmhinweisanzeige Zur Anzeige von aktuellen Nachrichten bzw. anderen Hinweisen sind prototypisch zwei weitere Module erstellt. Abbildung 45: Nachrichten-Modul

79 Testen Testen Die SCSF bringt für ihre eigenen Services bzw. Objekte schon einige Tests mit, z.b. ein TestableRootWorkItem und einige Servicetest, s. Abbildung: Abbildung 46: Infrastructure Testprojekte Es gibt zwei Implementierungen der Tests, einmal als NUnit-Test und zum anderen als VSTS Unit Tests für die TeamEdition von VisualStudio, die die Library der Team Suite Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll benötigen. Beim Erstellen von Modulen über das GuidancePackage, gibt es die Möglichkeit gleich ein Test-Projekt für das Modul mit zu erstellen. Hier wird aber allerdings normalerweise ein VSTS-UnitTest erzeugt. Will man stattdessen ein NUnit-Testprojekt erzeugt bekommen, muss man das GuidancePackage entsprechend verändern Anleitung dazu unter

80 Testen 72 Da die Module in CAB lose gekoppelt sind und damit eine Trennung der Zuständigkeiten erreicht wird, lassen sich Test für die einzelnen Teile leichter erstellen. Ebenso verhält es sich durch den Einsatz des MVP-Patterns. Dabei ist es für das Testen von Vorteil, wenn z.b. für Services gegen Interfaces implementiert wird. Dann kann dafür statt der realen Implementierung ein Mockobjekt zum Testen eingesetzt werden. In der Referenzimplementation der BankBranchWorkbench sind weitere Tests enthalten. Hinweise zum Erstellen von Unit Tests, sind in den Developer Labs 28 im Lab 4: Creating a Service im Task 5. Create Unit Tests for the Presenter zu finden. 28 Aus den Beispielen zur SCSF: HandsOnLabs-Developer

81 Ergebnisse Ergebnisse Die für das Projekt geforderten Ziele aus Kapitel 4 Anforderung an die Integrationsplattform sind hier nochmal aufgezählt, und die Ergebnisse in Bezug auf die Erreichung der Ziele sind hier zusammengefasst: 1) Modularität (plug in, add-ins, add-ons ) a) Lose Kopplung zwischen den Modulen (dabei notwendige Auflösung von Abhängigkeiten) und damit gute Wiederverwendbarkeit b) Lazy Loading (erst wenn Modul/Service benötigt wird, wird Modul/Service geladen) Ergebnis: Modularität ist erklärtes Ziel von CAB und wird gut unterstüzt (s. Kapitel Zweck/Ziele a) Lose Kopplung wird über den ObjectBuilder und den DI-Container WorkItem erreicht b) Lazy Loading ist über das Attribut OnDemand möglich. 2) Module sind in einem GUI integrierbar (gemeinsames Look and Feel ) Ergebnis: Die Shell als UI-integratives Element mit ihren Workspaces und UI-Extensionssites sorgt für die Integration der Module auf dem Desktop. Menüs, Statusbar und Toolbars können von den Modulen gemeinsam genutzt werden und so für ein einheitliches Aussehen sorgen (s. Kapitel Wie werden diese Ziele erreicht? (Funktionsweise, Philosophie, Design) ) (Für das einheitliche Aussehen innerhalb der Module müssen die Programmierteams selber sorgen.). 3) Einbindung von Legacy - Modulen (Win32-Module,.NET Module) und Modulen von anderen Herstellern Ergebnis: Legacy Module sind einbindbar, ohne UI sowieso und mit UI z.b. über dll-injection. Dies wurde hier nicht getestet, ist aber im Case Study der ComSee realisiert worden: The composite Smart Client is capable of hosting existing applications in some cases inprocess, and in other cases using techniques such as Dynamic-Link Library (DLL) injection ([CommSee] S. 9). 4) Dezentrale Konfigurierbarkeit Ergebnis: Durch die Möglichkeit die Konfiguration über einen Service zu steuern und in unterschiedlichsten Speichermedien hinein zu erstellen (Datenbank, Datei), ist eine sehr flexible Konfigurierbarkeit möglich (s. Kapitel Konfiguration ). 5) Benutzerverwaltung (Rechtevergabe, Sicherheitskonzept) a) Rollenkonzept

82 Ergebnisse 74 b) Authentifizierung und Autorisierung Ergebnis: Für die Rechtevergabe werden über Authentifizierungsservice und Autorisierungsmöglichkeiten Hilfen für die Realisierung dieser Ziele angeboten. Dies kann auf Codeund/oder Modulebene geschehen. Die EnterpriseLibrary bietet zusätzlich Hilfen zur Umsetzung eines Sicherheitskonzeptes an. a) Eine Autorisierung über Rollen ist z.b. in der Konfiguration möglich. Auf Codeebene kann über Attribute der Zugriff auf einzelne Methoden über die Rollen gesteuert werden (s. Kapitel 11.2 Sicherheit ) b) Ein Authentifizierungsservice ist als Gerüst angeboten und muss selber nach eigenen Wünschen implementiert werden (s. Kapitel Authentifikation ). 6) Aufrufbarkeit von Fremdanwendungen aus (von Java, Delphi etc. heraus) Ergebnis: Hier gilt dasselbe wie für den Einsatz von.net Assemblies in Fremdanwendungen (s. Hinweis zu diesem Themenkomplex findet man unter dem Stichwort.Net und interop.) 7) Anbindung verschiedener DB - und BackEnd Systeme ohne die Notwendigkeit der Installation von DB-Treibern Ergebnis: Dies ist keine Eigenheit des Frameworks, wird aber über.net Datenbankproviderschicht und Datenbankservices (auch als WebService denkbar) ermöglicht (In der Testanwendung werden Benutzerdaten und Konfigurationsdaten über einen WebService aus verschiedenen Quellen geladen). 8) Module müssen auf Client- und auf Serverseite (WebServices) einsetzbar sein Ergebnis: Ein Beispiel für CAB Hosting ohne UI-Elemente wurde in der Arbeit dargestellt. Dies zeigt die Möglichkeit Cab-Module ohne UI-Elemente zu erstellen und damit ohne großen Aufwand auf Client-, und auch auf Serverseite einzusetzen (s. Kapitel CAB- Module ohne GUI-Elemente ). 9) Offenheit für den Einsatz von WebServices (Unternehmensstrategie aus Wiederverwendbarkeitgründen und wegen der Installationsfreiheit; ebenfalls zur Vorbereitung von SOA) Ergebnis: Da CAB und die SCSF serviceorientiert angelegt sind, steht einem Einsatz von WebServices nichts im Wege. Vielmehr gibt es dazu sogar ein ServiceAgentRecipe (s. Abbildung 22: Service Agents (aus SCSF-Hilfedatei)). 10) automatische, zentrale Softwareverteilung (Deployment Click once) a) Versionierung b) Updates/Erweiterungen Ergebnis: Darauf wurde in dieser Arbeit nicht eingegangen. Aber über ClickOnce (s. Anhang SCSF Deployment and updates 29 ) werden die beiden Punkte a) und b) unterstützt und ermöglicht. 11) Caching zur Performancesteigerung ist realisierbar 29 s. auch auf der CD unter CAB/ClickOnce. Unter den Stichworten Cab und ClickOnce findet man zahlreiche Beiträge im Internet.

83 Ergebnisse 75 Ergebnis: Dies ist in der SCSF, dadurch dass die EnterpriseLibrary ApplicationBlock eingebunden werden können, leicht möglich - dazu benutzt man den Caching Application Block Kritik Die Kritik an CAB und der SCSF entzündet sich meistens an der zu grossen Komplexität 30 des Frameworks und an der damit für ein Verständnis notwendigen langen Einarbeitungszeit in das Framework. Aus meiner eigenen Erfahrung kann ich dies bestätigen - besonders dann, wenn man noch keine anderes PlugIn Framework kennt und wenn man bei der Verwendung von Patterns noch ungeübt ist. Dass das Verständnis schwieriger ist, hat strukturelle Gründe bei einem Framework, dass auf lose Kopplung setzt und hängt nicht allein von diesem Framework ab. Durch die lose Koppelung sind die Zusammenhänge nicht direkt erkennbar, sondern müssen oft durch Hintergrundwissen hergestellt werden. Die Kommunikation zwischen den Modulen läuft eben nicht direkt, sondern über Services, Messages (Events), wobei die Kommunikationspartner nicht gleich ersichtlich sind. Diese grössere Komplexität ist natürlich nur dann sinnvoll, wenn sie auf der anderen Seite für ausreichende Vorteile führt. Hier geht das Framework vielleicht einen Schritt zu weit und ist deshalb auch noch in weiterer Entwicklung 31 (s. weiter unten in diesem Kapitel). Ein weiteren Kritikpunkt betrifft den ObjectBuilder. Auch der ObjectBuilder wird als zu groß und schwerfällig angesehen. Beim Debuggen stellt man fest, dass im ObjectBuilder während der Reflektion die unterschiedlichen Strategien sehr oft durchlaufen werden. Selbst beim Laden per OnDemand Attribut, wird schon am Anfang das Modul nach Attributen durchsucht und damit Zeit gebraucht, auch wenn der Service noch nicht erzeugt wird. Bei einer großen Anzahl von Modulen, die geladen werden müssen, kann es damit zu Performance-Problemen kommen. Dazu bemerkt Chris Holmes, dem ich hierbei zustimme (ohne allerdings Erfahrung zu haben, ob dies auch praktisch möglich ist), folgendes: The better solution (imo) is to figure out what use cases you have and code your application so that dependent use cases reside in the same module or in modules that can be loaded together. Then associate use cases with user roles. In this way you can modularize your application such that when a particular user logs in, only the parts of the application that they require will load. Thus, you could have a giant CAB application that, if all modules were loaded on startup, might exceed the bounds of your memory capacity, but you can prevent that from ever happening because you have wisely coded your use cases to match user roles, and so no user role will ever require the entire application to be loaded at one time s. z.b. Post von Glenn Block unter Weitere kritische Seiten sind im Ordner Kritik auf der CD zu finden. 31 Vgl. Unity, ObjectBuilder2 und GAC. 32 aus (s. CD/Kritik). Auch die anderen Beiträge dieses Threads sind in diesem Zusammenhang lesenswert!

84 Ergebnisse 76 Bei der geringen Anzahl von Modulen in diesem Prototyp ist dies noch kein Problem der Start dauert im Durchschnitt 9 Sekunden bei der Anmeldung als Administrator (alle Module werden geladen). Wie in dieser Testanwendung geschehen, ist es sinnvoll per UseCase rollenabhängig nur die notwendigen Module zu laden. Ein weitere Möglichkeit der Beschleunigung wurde auch für Mobile Clients ( Mobile CAB und Mobile OB ) gewählt, durch eine Vorkompilierung und Verringerung von Reflektion (dabei wurden OBGen 33 and CabGen benutzt s. Fussnote 21). Der Code des ObjectBuilders ist in einer neuen Version überarbeitet worden. 34 Hier bietet sich die Möglichkeit auf einen leichteres DI-Werkzeug auszuweichen, wie z.b. Spring für.net (Zum Vergleich von Application-Frameworks s. im Anhang Application Frameworks im Vergleich). Inzwischen gibt es auch einen neuen leichteren DI-Container namens Unity 35. In dem neuen Framework CAG (Composite Application Guidance, was sozusagen ein Cab für WPF beeinhaltet) von der Patterns&Practices Group ist der DI- Container über ein Adapter frei wählbar. Desweiteren war die Dokumentation für den ObjectBuilder am Anfang von Microsoft aus sehr dürftig. Nur über andere Quellen war für mich eine Einarbeitung in die komplexe Struktur möglich 36. Als Beschränkung (allerdings von.net herührend) hat sich herausgestellt, dass ein Entladen von Modulen bei einem Benutzerwechsel nicht möglich ist. Für Assemblies gilt das jedoch nicht (s. [Ric06] S. 550, Entladen einer AppDomain ). Hier ist eine weitere Evaluation notwendig, um einen Benutzerwechsel ohne Neustart des Programmes zu ermöglichen. Auf den Punkt des Testens bin ich nur kurz eingegangen und hatte nicht die Zeit, mich in das Gebiet einzuarbeiten und das Projekt konsequent von Testfällen heraus zu entwickeln. Hier setzt z.b. Steve Miller mit seiner Serie Build your own Cab an, der von der TDD 37 - Seite aus versucht ein UserInterface zu entwickeln (Hier ist allerdings noch nicht abzusehen, wann die Serie abgeschlossen sein wird dies war schon für Sommer 2007 angekündigt!). Diese Kritik hat ihren Sinn, da wie man jetzt sieht, nach WinForms die WPF als neue UI- Technology von Microsoft favorisiert wird und die nächste UI-Technology wahrscheinlich schon in der Schublade liegt und deshalb eine noch stärkere Trennung vom UserInterface und eine leichtere Testbarkeit notwendig wird. Meiner Meinung nach werden weitere Schritte auf dem Weg zur losen Kopplung bei der Entwicklung des Composite Client am klinischen Arbeitsplatzsystem gemacht werden müssen, gemäß den 3 Aspekten, die Udi Dahan (s. [Dahan]) im Zusammenhang mit SOA nennt: Plattformunabhängigkeit ( Interoperability ) Zeitliche Unabhängigkeit ( synchron, asynchron ) 33 s. auch Folie ObGen Strong Typed Policies bei David Cazzulino [Caz07] 34 Brad Wilson and Scott Densmore took it upon themselves to rewrite this into a much more usable piece of code. You can download the original and unencumbered ObjectBuilder2 from CodePlex here. (aus IoC Containers, Unity and ObjectBuilder2 - The Saga Continues) 35 The Unity Application Block (Unity) is a lightweight, extensible dependency injection container with support for constructor, property, and method call injection. (aus MSDN: Introduction to Unity) 36 Anmerkung: Allerdings gab es dann doch einen WebCast von David Cazzulino [Caz07] zum Verständnis der Hintergründe des ObjectBuilders 37 TDD = Test-Driven-Developement

85 Ergebnisse 77 Räumliche Unabhängigkeit (Ein Servicekunde sollte nicht den Ort kennen müssen, von dem er aus bedient wird ) Auch das KAS wird sich in dieser Richtung entwickeln müssen und auf dem Weg des Zusammenwachsens von Desktop- und Weboberflächen fortschreiten. Da ist der Schritt von CAB mit seiner Ausrichtung auf WinForms hin zur in der CompositeApplicationGuidance verwendeten WPF (XAML ist XML ähnlich) sicher eine sinnvolle Entwicklung. Die Einarbeitung in CAB war auf jeden Fall keine sinnlose Arbeit, auch wenn es schließlich im KAS nicht zum Einsatz kommen sollte. Die Beschäftigung mit den implementierten Pattern und Konzepten zur losen Kopplung ist eine gute Grundlage für jede Client UI- Entwicklung.

86 Ergebnisse 78

87 Ausblick Ausblick Als Ausblick seien hier einige Themen genannt, die zur weiteren Evaluierung eines Integrated Desktops im Zusammenhang der Arbeit interessant sind. Als weiteren, zu implementierenden Service bietet sich z.b. ein Ressourcenservice (s. Cabana) an, der unabhängig von einer.net Implementierung ist: While Resources are not likely to change, they're offered as a service rather than direct from the.net so that clients do not have a dependency on the assembly that holds the resources and so we can extend the service with other kinds of resources (e.g., colors) that are not supported by the ResourceManager. (aus [Cabana]). Innerhalb des.net Frameworks gib es nun auch einen ResourceApplicationBlock in der EnterpriseLibary, der mehr bietet als der ResourceManager des.net Frameworks. Für das CSLA Projekt von Lhotka, das z.b. ein Undo-Pattern realisiert, gibt es auch eine CAB Implementierung (s. cslanet oder primos und für die Praxis SCSF_CSLA_ProjectTracker). Für die Verteilung der Anwendung lohnt ein näheren Blick auf das Click Once Deployment. Desweitern gibt es einige Projekte, die die Funktionalität von CAB ergänzen und fortführen: Prism Projekt für WPF-Unterstützung ( CompositeWPF) jetzt CAG genannt SDMS Projekt (von Bill Krat versucht CAB gemäß MCSD Microsoft Solution Architecture zu entwickeln SCContrib.CompositeUI.MDI) SCSF Contrib Project Unity Application Block: neuer Container für Objekt Builder SCSF für Visualstudio 2008 Enterprise Library 4.0 Build you own Cab (Steve Miller) Für den medizinischen Bereich gibt es jetzt eine Microsoft HealthCare Initiative mit einem common user interface MicrosoftHealth. Dort werden die neuen UI-Möglichkeiten von WindowsVista eingesetzt.

88 Literatur 80

89 Literatur Literatur [Asch06] Klaus Aschenbrenner: Unabhängige WinForms-Module. Composite UI Application Block (CAB). dotnetpro , S (CD) [AschSCSF] Klaus Aschenbrenner: Baukasten für Smart Clients. Smart Client Software Factory. dotnetpro , S (CD) [Bana06] Atanu Banerjee: What Are Composite Applications? Microsoft, Dez (CD/Architektur) [BellReq] Ward Bell: Requiem for Acropolis; Fanfare for CAB +. Blog Eintrag (CD) [BellCaba] Ward Bell: The Cabana Experience. Building UI with DevForce and CAB. PowerPoint Presentation (CD) [BellComp] Ward Bell, Don Robins: Building Composite User Interfaces. Slides zum Webinar von IdeaBlade in MSDN Webcasts 8/28/07 PartnerWebcast: Outformations (CD) [Ber07] Jürgen Berchtel: Evaluation of Plug-In Architectures for a Test Suite. Diploma Thesis. Fachhochschule Vorarlberg GmbH, September (CD) [Caz04] Cazzulino Daniel. Lightweight Containers and Plugin Architecture: Dependency Injection and Dynamic Service Locators in.net., July 16, eshttp:// (CD) [Caz07] Cazzulino Daniel: Dependency Injection and Object Composition put into practice. Powerpoint Presentation 2007 [Cli05] Marc Clifton: What is a Framework? Artikel im Web ework/tabid/95/default.aspx (CD) [CommSee] [Dahan] [Gre07] [Gre08] [GS04] Commonwealth Bank of Australia CommSee Solution Case Study, Microsoft 2006 (CD) Udi Dahan: SOA Distilled (CD/Allgemein) Derek Greer. Interactive Application Architecture Patterns. An Introduction to the Model-View-Controller, Model-View-Presenter, and Presentation- Abstraction-Control Patterns (CD) Derek Greer. The Art of Separations of Concerns Jack Greenfield, Keith Short: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley Publishing Inc., 2004.

90 Literatur 82 [FFSB06] Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Entwurfsmuster von Kopf bis Fuß, O Reilly, ( Head First - Reihe) [Fow00] Martin Fowler: Refactoring: improving the design of existing code. Addison-Wesley, [FowIOC] Martin Fowler. Inversion of Control Containers and the Dependency Injection Pattern. [GK07] Gudenkauf, J., and Kaplan, J CLR Inside Out:.NET Application Extensibility. MSDN Magazine. February (CD) [GK07a] Gudenkauf, J., and Kaplan, J CLR Inside OUT:.NET Application Extensibility, Part 2. MSDN Magazine. March (CD) [GoF95] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, [GS04] Jack Greenfield, Keith Short: Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley Publishing Inc., [Has] Sayed Y. Hashimi. Demystifying the Object Builder. ObjectBuilder.aspx (CD) [Hau06] Andreas Hauri: Konsole für den Einsatz von unmanaged C++ und.net. Pflichtenheft und Bericht Diplomarbeit. Berner Fachhochschule, (s. CD) [Hil04] David Hill: What is a SmartClient anyway. WebLog (CD) [Jen07] William C. Jensen: IdeaBlade. Cabana Reference Application. IdeaBlade Version 06 (CD) [Joh08] Kimball Johnson: Smart Client Design Pattern (CD- Pattern) [Kru06] Adrian Krummenacher: Lose Kopplung mit CAB, dotnetpro 12/2006 Seite (CD) [Löw05] Juval Löwy: Programming.NET Components. 2. Auflage O Reilly Sebastopol [MSAA] Microsoft Patterns and Practices: Application Architecture for.net: Designing Applications and Services. Microsoft (CD) [MSDAMAZ] Microsoft Patterns and Practices: Designing Application-Managed Authorization. Microsoft [MSDAAG] 59D7-46E2-8DFA AC67&displaylang=en (CD) [MSESP] Microsoft Patterns and Practices: Enterprise Solution Pattern Using Microsoft.Net. Version 2, Microsoft 2003, (CD)

91 Literatur 83 [MSSCSF] Microsoft Patterns and Practices: Overview of the Composite UI Application Block. Microsoft 2007, (CD) [MSScArch] Microsoft Patterns and Practices: Smart Client Architecture and Design Guide. Microsoft 2004, u.a. (CD) [Nen05] Dhananjay Nene: A beginners guide to Dependency Injection. July [New07] (CD) Rich Newman: Introduction to CAB/SCSF. 25 Parts. July 2007 March (CD) [NewDesign] Rich Newman: User Interface Design for Business Applications. Okt (CD) [NewSoa] Rich Newman: Some Thoughts on SOA and Application Design using the CAB/SCSF. August (CD) [Ove06] Ken Overton: Creating CAB-module service dependency hierarchies. Aus Lab49 Blog» Blog Archive», 30. Nov [PazCabIso] Eugenio Paz: CAB Modules isolation requirements. Sept (CD) [Pla07] David S. Platt: Composite UI Application Block and Smart Client Software Factory. Programming Microsoft. Microsoft Press 2008 [RazCAB] SalRazzay: Mircosoft Composite Application Block (CAB). Version 0.92, [RazMVP] [RP06] [Ric06] [Sim07] (CD) Sal Razzaq: Model-View-Presenter (MVP) (CD) Alexander Ramisch, Burkhard Perkens-Golomb: NET-Komponenen in großen Geschäftsanwendungen. Komponentenbasierte Softwareentwicklung auf der.net-plattform (Teil1-3). dot.net Magazin 3.06 (CD) Jeffrey Richter: Microsoft.NET Framework-Programmierung in C#. Expertenwissen zur CLR und dem.net Framework 2.0. Microsoft Press Deutschland, Bil Simser: Adding a splash screen to a CAB application. Fear and Loathing. Published Monday, March 19, 2007 (CD) [SimActCat] Bil Simser: Taming the Action Catalog in SCSF. 10, (CD) [Szk06] [Szp06] Mario Szklanny: CAB - Adding Command-level security to applications. Blog, cab-adding-command-level-security-to-applications (CD/Cab/Autorisation) Mario Szpuszta: Designing Smart Clients Based on CAB and SCSF. Architectural Guidance for Composite Smart Clients. White Paper. Microsoft, %20Architecture%20Guidance%20-%20Raiffeisen.pdf (CD) [TavOB] Tavares Chris: Deconstructing - ObjectBuilder. 4-teilig, ObjectBuilder.aspx (CD)

92 Literatur 84 [TK06] [VolOB] [Wils06] [WolHost] [WolLoad] [Wol06] Christian Thilmany, Jim Keane: Neue Anleitungen und Tools zum Erstellen von Integrated Desktop-Anwendungen., 02. Oktober (CD) Stephan Volmer: Verstecktes Juwel, der Object Builder Application Block, dotnetpro 9/2006, Seite 130 ff. (CD) Brad Wilson, New Module Loader For CAB, CAB.aspx (CD) Matias Woloski: Hosting CAB in a UserControl In depth. (CD) Matias Woloski: HowTo: load CAB modules on demand. CD. Eberhard Wolff: Spring. Framework für die Java-Entwicklung. dpunkt.verlag, Heidelberg, 2006 (CD Kapitel 2 Objekte finden zueinander Dependency Injection)

93 Literatur Links CAB CAB Dokumentation Offizielle CAB Einführung, Wissensdatenbank etc. CAB Diskussionsforum Extensions CAB Erweiterung für die Infragistics NetAdvantage OutlookBarWorkspace (Matias Woloski) The HelperTrinity (Kent Boogaart) DockManager - Dock Panel Suite (Weifen Luo) Cab Extensions Enterprise Library Enterprise Library Projekt Application Blocks und CAB Patterns&Practices (CD/Dok/finalposter-1.pdf) Object Builder ObjectBuilder und zu Dependency Injection. Dokumentation Brad Wilson WebCast: Extending Microsoft patterns & practices ObjectBuilder Smart Client Software Factory Smart Client Software Factory Projekt SCSF Smart Client Architecture Features Patterns&Practices (CD/Dok/finalposter2.pdf) Knowledgebase

94 Literatur 86 SCSF Contrib Projekt Beinhaltet die OutlookBar, die TestSuite von J.Berchtel u.a.m Diverse ClientApplicationGuidance (aka. Prism) for WPF - Codeplex - MSDN WebServiceFactory Projekte/Beispiele/Case Studies [Berchtel] Diplomarbeit Berchtel (s.[ber07]) [Cabana] Cabana IdeaBlade [CommSee] Commonwealth Bank of Australia CommSee Solution Case Study, Microsoft 2006 (CD) [CSD] Infragistics CAB Application Demo: Client Services Desktop CSD, 2006 Infragistics (CD) [Hauri] Diplomarbeit Hauri (s.[hau06]) [MsdnCounselor] CounselorDesktop, MSDN Magazin November 2006 [PetShop] Pet Shop application upon CAB [Raiffeisen] Raiffeisenbank Österreich, Microsoft 2006 (Planung und Realisierung) (s. [Szp06]) rd Party Components und CAB DeKlarit Infragistics IdeaBlade Toolset, das CAB (genauer Infragistics NetAdvantage CAB Exensibility Kit) in seiner Implementierung benutzt DK:. What's New in 4.x - Composite Application Block Client Service Dektop (CSD) Implementation von CAB mit Einbindung von Infragistics.Net Komponenten (DockWorkspace, TreeView, ToolbarsManager u.a.) Bietet eine Version von CAB in das eingene Framework noch eingebaut

95 Index Index A ActionCatalog Anforderung an die Integrationsplattform... 7 Attribut...Siehe Injection Authentifikation C CAB Architektur Assemblies Funktionsblöcke Item Collection ohne GUI (Hosting) Services Was ist Cab? Chain of Responsibility14, Siehe ObjectBuilder- Strategien ClickOnce... 6 Composite Client... 1 Container WorkItem D Dependcy Injection Dependency Inversion Design Smells... 9 E Enterprise Library Event Publish/Subsribe I Injection per Attribut per Constructor per Property Integrated Desktops... 7 Integrierter Desktop... 1 Inversion of Control K Kis... 1 Kontextservice L Logging Login Lose Kopplung M Modul Erstellung Module Laden O Object Builder Injection Constructor Strategien Order&Entry... 6 P Patientensuche Patientenverwaltung Pattern Performance... 9 ProfileCatalog Projekt Übersicht (Mappe) Q Qualitätskriterien... 9 R Recipe...Siehe SCSF Rezepte S SCSF Architektur EventSubscription Pattern Projektstruktur Rezepte ServiceAgents... 36, 74 Überblick Separation of Concern ServiceContract ServiceDependency Shell (Theorie) Shelldesign (Praxis)... 48

96 Index 88 ShellExtensionService (Praxis)... 45, 49 Sicherheit Singleton ObjectBuilder SmartPart Stationsbelegung T Terminplanung Projektmappe Testen U UI ExtensionSites UseCase UserManager V Visualizer W WCF WorkItem Baumstruktur Workspace... 20

97 Glossar Glossar ActiveX API CAB CAG CASE CLSID COM DI EAI EDRA GAT GAX GoF GUI GUID HIS-Server Hl7 http IDE IDF IIS IFW KAS KIS LDAP MVC MVP MDA Komponente die auf COM basiert, welche in andere Applikationen eingebunden werden kann. Meistens bietet eine ActiveX Komponente ein graphisches Interface. application programming interface Composite User Interface Application Block Composite Application Guidance computer aided software engineering GUID welche vom Windows System für die eindeutige Identifizierung einer COM.Klasse verwendet wird Microsoft zur Interaktion von Softwarekomponenten. Die Erstellung und der Aufruf von COM-Komponenten können innerhalb desselben Prozessraums oder über die Grenzen von verschiedenen Prozessräumen hinweg erfolgen. dependency injection enterprise application integration Enterprise Development Reference Architecture (patterns&practise group) Guidance Automation Toolkit. Templates zur Codeerzeugung (s. SCSF) Guidance Automation Extension. Templates zur Codeerzeugung (s. SCSF) Gang of Four, siehe Autoren [GHJV95] graphical user interface Globally Unique Identifier Ein weltweit praktisch einmaliger 128 Bit Wert. Dieser wird u.a. als Datenbankschlüssel eingesetzt. HostIntegrationServer health level 7 (Schnittstellendefinition für das Gesundheitswesen) hypertext transfer protocol integrated development environment integrated desktop framework Internet Information Services (früher Internet Information Server) Ibm InformationFrameWork (Bankingmodell) Klinische Arbeitsplatz-Systeme Klinische Informations-Systeme lightweight directory access protocol model view controller (Strategiemuster, ursprünglich aus Smalltalk) model view presenter (ähnlich dem MVC) model driven architecture

98 Glossar 90 OB RPC SCSF SOA SOFA SOAP Type Library UI URI WCF WPF object builder remote procedure calls smart client software factory service oriented architecture service-oriented framework architecture simple object access protocol Eine COM-Typbibliothek ist die formale Beschreibung der Fähigkeiten einer Komponente user interface Uniform Resource Identifier - Ein Identifikator aus einer Zeichenfolge, die zur Identifizierung einer abstrakten oder physischen Ressource dient. Windows Communication Foundation Windows Presentation Foundation (weitere Informationen findet man z.b. unter

99 Anhang Anhang 18.1 CAB-, SCSF-Glossar Class / Term WorkItem Service Module ProfileCatalog ModuleLoader ModuleInit Description, Purpose Seen technically, a WorkItem is just a container for managing objects, which are required for accomplishing a certain task. Such objects are state objects, views and their presenters/controllers, or commands for launching an action. At a more high-level view, a WorkItem is a class encapsulating logic for one dedicated use case. It can be seen as a use case controller that knows all the different aspects of a use case. As such, a WorkItem holds state for all parts involved in a use case, such as views necessary to display, or sub-use cases. Furthermore, it acts as an entry point into the use case (or one of its sub-use cases) it is responsible for. Services encapsulate functionality that is common for the whole client application, for a specific module, or just for WorkItems within a certain hierarchy of WorkItems (for example, for sub-workitems of a specific parent WorkItem). Typical services are security services responsible for authentication or authorization or Web service agents encapsulating service communication and offline capability Multiple, logically related WorkItems can be summarized into a single unit of deployment. A module is an example of a unit of deployment. Configuration of CAB-based smart clients basically works on a module-level. Therefore, finding the right granularity for encapsulating WorkItems into modules is crucial. The profile catalog is just a configuration that specifies which modules and services need to be loaded into the application. By default, the catalog is just an XML file that resides in the application directory. This XML file specifies which modules need to be loaded. By writing and registering a custom IModuleEnumerator class, you can override this behavior to get the catalog from another location, such as a Web service. This is a general service provided by CAB, which is responsible for loading all the modules specified in a profile catalog. It just walks through the configuration of the profile catalog, tries to dynamically load the assembly specified in a catalog entry, and then tries to find a ModuleInit class within that assembly. Each module consists of a ModuleInit class, which is responsible for loading all the services and WorkItems of a module. (In addition to services and WorkItems, the class is also responsible for aspects, such as user interface extensions to the shell; for more information, see the description for UIExtensionSite later in this table.)

100 Anhang 92 Shell application Shell Workspace UIExtensionSite Command EventPublication EventSubscription Model View The Shell application is the primary application that is responsible for initializing the application. It is responsible for dynamically loading modules based on the configuration and launching the base services for the smart client application, in addition to starting the main form (Shell). This is the main form of the application; it provides the user interface that is common to all dynamically loaded modules. The Shell always hosts the root WorkItem, which is the entry point into any other parts of the application, such as services, modules, and WorkItems that are created and registered by these modules. A workspace is a control that is primarily responsible for holding and displaying user interface elements created by WorkItems. Usually workspaces are added to the Shell (or to other extensible views within your WorkItem hierarchy) and act as containers for parts of the UI that are going to be dynamically filled with UI items that are provided by WorkItems or sub-workitems. Any user control can be a workspace by implementing the IWorkspace interface. Out-of-the-box, CAB includes classic container controls as workspaces, such as a tabbed workspace. UIExtensionSites are special placeholders for extending fixed parts of the Shell such as menus, tool strips or status strips. Unlike workspaces, they are intended to be used for parts of the UI, which should not be completely overridden by WorkItems; instead, they should just be extended (such as adding a new menu entry). Command is a base class of CAB for implementing the Command pattern. CAB supports classic commands created manually or declarative commands by applying the [CommandHandler] attributes to the method; these attributes act as command handlers. You can register multiple invokers for one command (such as click events of multiple controls). EventPublications are used by event publishers for loosely coupled events. An event publisher implements the event through.net Framework events that are marked with the [EventPublication] attribute. Events are uniquely identified by event URIs (unique strings). Only subscribers using subscriptions with the same event URI will be notified by CAB. A subscriber needs to have a method with the same signature as the event used [EventPublication] and needs to be marked with the [EventSubscription] attribute. EventSubscription is the opposite of EventPublication. Any class that wants to subscribe to an event with a specific event URI needs to implement an event handler that matches the method signature of the EventPublication. You must mark this event handler with the [EventSubscription] attribute and the publisher s event URI (in the attribute s constructor) and CAB makes sure that a subscriber will be notified each time a publisher raises an event with a matching event URI and method signature. Model is the (client-side) business entity a WorkItem processes; for example, Customer, BankAccount, or Loan. View is an ordinary.net Framework user control that is responsible for presenting a part of or the whole model to the user and allowing the user to modify its contents through user interface controls. Typically, the view implements only UI logic; whereas the related

101 Anhang 93 client-business logic is implemented in the presenter/controller. SmartPart Controller ObjectBuilder Dependency Injection ( aus [Szp06] S.7 ff.) A SmartPart is a.net Framework user control with the [Smart- Part] attribute applied. Optionally, a SmartPart can implement the ISmartPartInfoProvider interface. As such, it provides additional information about itself, such as a caption or a description. Controller is a class that implements the logic for modifying a model. One controller can modify a model presented by many views. Origin: Model-View-Controller ObjectBuilder is a foundation component of CAB that acts as the factory for creating objects that require specific builder strategies to be created or that need features, such as automatic instantiation and initialization of dependant objects when creating instances. As such, the ObjectBuilder has a combined role as a factory, a dependency injection framework, and a builder strategy framework. Dependency Injection is a pattern that allows a factory to automatically create or initialize properties or members of objects with dependant objects. ObjectBuilder provides this functionality. Tabelle 2: Anhang: Important Terms and Definitions for CAB Class / Term WorkItemController ControlledWorkItem ModuleController Presenter Description, Purpose A WorkItemController is a class introduced by the Smart Client Software Factory that encapsulates common initialization logic for a WorkItem. When creating WorkItems with SCSF, instead of directly inheriting from the WorkItem base class, you inherit from this class to get the added initialization logic. Again, this is a class introduced by the Smart Client Software Factory; it is a generic class for instantiating new WorkItems based on a WorkItemController. It launches the added initialization entry points provided by the WorkItemController for you. ModuleController classes are introduced by the Smart Client Software Factory and are used for encapsulating a special WorkItem within a module taking on the role of a root WorkItem within a module. The default ModuleInit implementation of a module created with the Smart Client Software Factory automatically creates a WorkItem for a module named ModuleController. Therefore, the ModuleController is the primary entry point for all WorkItems provided by a module. Presenter is a class that implements the logic for one single Smart- Part (view). The presenter is based on the Model-View-Presenter (MVP) pattern, which is basically a simplified variant of the Model- View-Controller (MVC) pattern. The big difference between MVP and MVC is that with MVP, the View is completely controlled by the

102 Anhang 94 ( aus [Szp06] S.10 f.) presenter, whereas in the MVC, the controller and the model can update the view. Tabelle 3: Anhang: Important Classes/Terms Required to Understand for SCSF Project Infrastructure.Interface Infrastructure.Library Infrastructure.Module Infrastructure.Layout Shell Service Entity Translator Base Class Basic SmartPart Info Classes ActionCatalog Service DependentModuleLoader Description Defines interfaces for basic services created by SCSF. The added services created by SCSF are listed in Table 4. Contains the implementations of the additional services generated by SCSF for you. An empty module where you can add your own infrastructure services. By default, this module consists of an empty module controller (which is a default root WorkItem for a module). In this module, you should only add services used by the whole smart client application that is typically always loaded with your application independently of other modules. A project SCSF creates if you selected that you want to put the shell s layout into a separate module. It contains a SmartPart and a presenter for this SmartPart for the shell layout. The actual Windows-based application of the smart client that contains the configuration and the actual main form that hosts the shell layout. Description Base classes for building translators of entities. These are used for complex smart clients where you typically need to implement a mapping from the smart client s object model to the (Web) service s object models for loose coupling between those two. CAB allows you to create classes that implement ISmartPartInfo. You need to implement this interface in a class when you want to display additional information for a SmartPart when it is being added to a workspace. For example, if you want to display a caption in a tab created within a tabbed workspace, you need to pass an implementation of ISmartPartInfo to the workspace so it displays the information. SCSF creates some basic implementations of this interface that are frequently used. Allows you to define specific methods of your classes as actions that are automatically called when the security context of your user allows the user using these actions as explained in the sections Error! Reference source not found. and Developing CAB Business Modules. By default, CAB comes with a simple profile catalog and module loader for dynamically loading modules based on the configuration of the ProfileCatalog.xml file stored in the application s directory. SCSF adds a new module loader that allows you to specify relationships between modules in the configuration. With the DependantModuleLoader, you can specify that one module depends on others to be loaded before it gets loaded itself. By default, the DependantModuleLoader is used in SCSF-based projects.

103 Anhang 95 WebServiceCatalog Service With this added service, you can retrieve the modules to be loaded at startup of your smart client from a Web service. All you need to do is implement the Web service back-end and then configure this service in the smart client s application configuration. Tabelle 4: Anhang: Projects Created by the Smart Client Software Factory Ergänzend (für die SCSF): Infrastructure.Interface Infrastructure.Library Infrastructure.Module This project is the interface for Infrastructure modules and contains only the elements that need to be exposed to other modules of the application. It is composed of service interfaces, constant definitions, commands, business entities (only those that are passed between modules) and other shared elements such as general purpose base classes. This project contains the implementation of common components used by a set of smart client applications. For example, it includes the service to retrieve the profile catalog from a Web service. This project is a Composite UI Module that acts as container for the implementation of elements that are shared across projects in your smart client application. When the CreateSolution recipe is executed, this module is added to the Profile Catalog. This means that Composite UI Application Block loads the Infrastructure.Module module when the application starts. When created, this module is empty. You modify it to include the implementation of elements that different modules of your application will use, such as services Tabelle 5: Anhang: SCSF Infrastructure (aus SCSF Developer Labs 1: Creating the Initial Solution)

104 Anhang What is a SmartClient? Smart client applications can be designed to combine the benefits of a rich client application with the deployment and manageability strengths of a thin client application, although the precise nature of the balance between the two approaches depends on the exact scenario. Smart client applications often have very diverse requirements, and so vary greatly in design and implementation. However, all smart clients share some or all of the following characteristics: Make use of local resources Make use of network resources Support occasionally connected users Provide intelligent installation and update Provide client device flexibility Many applications do not need all of these characteristics. As you design your smart clients, you will need to carefully consider your application scenario and decide which of these characteristics your smart client application requires. Incorporating all of these characteristics into your application will require very careful planning and design, and in many cases you will need significant implementation resources. (aus David Hill's WebLog : What is a Smart Client anyway? [Hil04]. Vgl. auch Atanu Banerjee: What Are Composite Applications? [Bana06] ) 18.3 Using Other User Interface Elements as UIExtensionSites (aus [New07] Part 14) As mentioned above we can use other user interface elements than just ToolStrips, MenuStrips and StatusStrips as UIExtensionSites. However, we have to do a little more work to get this going. In fact, we have to write an adapter class for our user interface element. This tells the CAB what to do when the Add or Remove methods are called on the associated UIExtensionSite. Before we discuss how to do this we ll quickly recap the Adapter pattern. The Adapter Design Pattern The adapter is a pattern that we use when we want a class to implement a standard interface but don t want to (or can t) change the actual code of the class. In the case of our UIExtensionSites our user interface elements (e.g. ToolStrips) will have methods for adding and removing individual items (e.g. ToolStripButtons). However we want to be able to use a generic Add method on a UIExtensionSite object to add ToolStripButtons. We clearly can t change the ToolStrip class to implement this, so we use an adapter. The book Design Patterns: Elements of Reusable Object-Oriented Software (the Gang of Four book) says the intent of the Adapter pattern is to:

105 Anhang 97 Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn t otherwise because of incompatible interfaces. The Adapter class diagram is below: The idea here is that we have some class Adaptee that has a SpecificRequest method that the client wants to call. However, the client code uses an Adapter class to invoke the functionality, calling the Request method. Adapter is an abstract base class: it s just defining an interface that the client code will use. Furthermore we can t, or don t want to, change the Adaptee class to actually inherit from Adapter. So instead we write a ConcreteAdapter class. This inherits Adapter, and so has a Request method. It also takes a reference to the Adaptee class (usually in its constructor) and caches it in a data member. This means we can write a very simple implementation of the Request method in our Adapter class that simply forwards the call to the SpecificRequest method on the Adaptee object in the data member. Now the client code can work with Adapter objects, calling the Request method, but still get the functionality of the SpecificRequest method of the Adaptee. Of course the Adapter class can do much more work than just forwarding method calls to methods with different names. The Adaptee might need several calls to do the work we want done in the call to Request on the interface, and the Adapter class can clearly deal with that as well. One consequence of the use of this pattern is that we can t cast our Adaptee class to Adapter since it doesn t implement it directly. This explains why in our examples we can t cast our UIExtensionSite (or the IUIElementAdapter data member it contains) back to our original ToolStrip. As mentioned above this restricts quite severely what we can do with a UIExtensionSite. How this is Implemented in the CAB for UIExtensionSites For UIExtensionSites in the Composite Application Block this pattern is made slightly more complex. The Patterns and Practices group have separated out the interface implemented by our Adapter base class into an actual C# interface called IUIElementAdapter which is then implemented by our abstract base class UIElementAdapter<TUIElement>. You don t need to worry about the details of this. All you need to know is that to implement your own adapter you need to inherit from UIElementAdapter<TUIElement> where TUIElement is the type of the objects that will be added to or removed from the UIExtensionSite. Inheriting this class compels you to override the abstract Add and Remove methods that it contains.

106 Anhang 98 As you ve probably realized, the Composite Application Block already contains an adapter class for ToolStrips, MenuStrips and StatusStrips. This is snappily called ToolStripItemCollectionUIAdapter and is in the CompositeUI.WinForms library EventSubscription in der SCSF CAB supports the loosely coupled events even on dependency injection level. The publishers have to define their event declaration with the EventPublication attribute. The subscribers define the event handler method with the EventSubscription attribute. The attributes use a string as identifier for the event topic. The event publisher and subscribers are wired together by the framework during the object creation. (aus [Ber07] S. 37) aus SCSF-Lab4 Creating a Service Note: For more detailed information about the entity translator service and entity translators, see How to: Translate Between Business Entities and Service Entities in the Smart Client Software Factory help Modul Abhängigkeitsdiagramme Auf der folgenden Seite ist ein Diagramm mit den Abhängigkeiten zwischen den Modulen dargestellt: erstellt mit Lutz Roeders Reflector und dem Reflector.AddIn 5.0 Graph zur Verdeutlichung, dass keine zyklischen Abhängigkeiten existieren.