EINSATZ VON DESIGN PATTERNS BEI DER ENTWICKLUNG DES CSM-FRAMEWORKS REMARC

Transkript

1 EINSATZ VON DESIGN PATTERNS BEI DER ENTWICKLUNG DES CSM-FRAMEWORKS REMARC 10. Informatik-Tag, HTWM Dipl.-Inf. Chris Hübsch, ARC Solutions GmbH

2 Inhalt 1. ARC Solutions 2. REMARC 3. Design Patterns 4. Patterns in Remarc

3 1 ARC Solutions Servicepartner von Siemens PLM für NX und Teamcenter Entwicklungspartner PTC (Pro Engineer), CAD SCHROER (Medusa), PIT (pit fm) eigenes REMARC MultiCAD Component Framework für Wiederverwendung & Standardisierung

4 2 REMARC Eigenentwicklung der ARC Solutions Historie in C/C++/Fortran Neuentwicklung in Java (Eclipse RCP) Modularer Aufbau ~180 Plug-Ins ~10,000 Commits seit 10/2005 ~400,000 LOC

5 Use Cases Erzeugen von Bauteildatensätzen (Normbasiert bzw. frei) Ableiten geometrischer Repräsentationen Auswahl von Bauteilen und Einbau in CAD-Modelle Verwalten von Repräsentationen und Bauteildatensätzen in PLM und ERP-Systemen Grundlegende Rollen: Creator vs. Consumer

6 Creator

7 Consumer

8 Datenmodell

9 3 Design Patterns Each pattern describes a problem which occurs over and over again in out environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing the same way twice. [Alexander, C., Ishikawa, S. und Silverstein, M.: A Pattern Language: Towns, Buildings, Construction, 1977]

10 Was macht ein Pattern aus? Kontext Situationsbeschreibung Problem Zwänge, die auf das System wirken Lösung Statische und dynamische Aspekte Konsequenzen Kompromiss zwischen Zwängen

11 Klassifikation Scale [A System of Patterns] Architectural Matrix [Design Patterns] Wirkbereich Design Pattern Idiom Klassenorientiert Objektorientiert Zweck Objekterzeugung Strukturbildung Verhaltensbeschreibung

12 4 Patterns in Remarc Systemarchitektur: Plugins-Pattern Kontext: Modulare Anwendung, die flexibel erweitert werden soll. Problem: Ständiges Compilieren angepasster Produkte zu aufwändig. Erweiterungsmöglichkeit auch für Dritte schaffen.

13 Lösung: Anwendung in einzelne Module (Plugins) zerlegen. Metabeschreibung der Plugins vorsehen. System zum Laden der Plugins zur Laufzeit. Konsequenzen: Klare Strukturierung und sauber definierte Schnittstellen notwendig. Höhere Startzeit als bei monolithischen Anwendungen. Metabeschreibung für Plugins erfassen.

14 Design-Patterns I Adapter-Pattern (Zugriff auf DIN-Interpreter) Kontext: Anpassung des Interfaces einer Klasse an ein domainspezifisches API. Problem: Clienten erwarten ein spezifisches API, die anbietende Klasse bietet dieses nicht an. Modifikation der anbietenden Klasse ist nicht möglich.

15 Lösung:

16 Design-Patterns II Command-Pattern (Kapselung von Interaktivität, Undo/Redo) Kontext: Anwendung mit Nutzer-Interaktiviät oder Job-Funktionalität. Problem: Verschiedene Eingabeformen gegenüber der Anwendung (Menü, Button, Short-Cut, Befehlszeile, Undo/Redo-Mechanismus Macros Logging

17 Lösung:

18 Design-Patterns III Composite-Pattern (Zusammenfassung von Kommandos) Kontext: Anwendung mit Datenobjekten, die sowohl atomar als auch gruppiert auftreten können. Problem: Gruppierte Datenobjekte erfordern teilweise andere Behandlung als atomare Objekte. Gruppierung soll möglicherweise vor Client verborgen werden.

19 Lösung:

20 Fazit Wiederverwendung wird auf neue Ebene gehoben. Kenntnis von Design-Patterns ist wichtiges Handwerkszeug für Informatiker. Klare Auszeichnung in Entwicklerdokumentation und Code ermöglichen schnelleres Codeverständnis. Bessere Toolunterstützung erleichtert Verwendung von Patterns. Literaturtipps: A System of Patterns, Design Patterns

21 Ende Vielen Dank! Fragen?