© arc solutions gmbh 2008. all rights reserved 10. informatik-tag, htwm dipl.-inf. chris hübsch,...

© ARC Solutions GmbH 2008. All rights reserved

10. Informatik-Tag, HTWM

Dipl.-Inf. Chris Hübsch, ARC Solutions GmbH

EINSATZ VON DESIGN PATTERNS BEI DER ENTWICKLUNG DES

CSM-FRAMEWORKS REMARC


Inhalt

1. ARC Solutions

2. REMARC

3. Design Patterns

4. Patterns in Remarc


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


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


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


Creator


Consumer


Datenmodell


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]


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


Klassifikation

Scale [A System of Patterns]

Architectural

Design Pattern

Idiom

Matrix [Design Patterns]

Wirkbereich

Klassenorientiert

Objektorientiert

Zweck

Objekterzeugung

Strukturbildung

Verhaltensbeschreibung


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.


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.


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.


Lösung:


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


Lösung:


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.


Lösung:


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


Ende

Vielen Dank! Fragen?

© arc solutions gmbh 2008. all rights reserved 10. informatik-tag, htwm dipl.-inf. chris hübsch,...

Documents