Aufrufe
vor 3 Jahren

02 | 2011 NEWS

  • Text
  • Daten
  • Experten
  • Innovationen
  • Analyse
  • Security
  • Management
  • Erfolgreich
  • Internet
  • Banking
  • Technologie
  • Msggillardon
  • Anforderungen
  • Steuerung
  • Banken
  • Kreissparkasse
  • Sculptor
  • Stresstests
  • Basel
  • Marzipan
  • Risiken
Druck von allen Seiten

Effizientes Werkzeug

Effizientes Werkzeug Schlanke automatische Codegenerierung – Domain Driven Design mit Sculptor Von Hans-Peter Keilhofer Viele Softwareprojekte stehen vor der Frage, modellgetrieben vorzugehen. Ein Codegenerator leitet vom fachlichen Modell immer synchron ein Softwaremodell ab, wovon Fachbereiche und IT selbst Jahre nach der Initialentwicklung bei Wartungsänderungen noch profitieren. Gerade bei Projekten von kleiner bis mittlerer Größe liegen die Opportunitätskosten für einen Codegenerator aber oft nicht im Budgetrahmen. Und selbst wenn aus einem vergangenen Projekt bereits ein Codegenerator vorliegt, muss dieser auf aktuelle technische Randbedingungen angepasst werden. msgGillardon hat sich in einem mittelgroßen Projekt bei der Bayern LB für Sculptor – eine automatisierte und dadurch effiziente Lösung für Softwareentwicklung im Bereich Client-Server- Anwendungen – entschieden. Was ist Sculptor? Sculptor ist ein freies Produktivitätstool basierend auf einer textuellen DSL und ermöglicht auch kleineren bis mittleren Projekten Model Driven Software Development mit relativ geringem Einarbeitungsaufwand. Aus der textuellen DSL, mit der das Modell beschrieben wird, wird Code in Form von Javaklassen und vielen weiteren Artefakten wie XML-Dateien oder JSF-Seiten generiert. Dies bedeutet einen Qualitätsgewinn durch die automatisierte Konsistenz zwischen Modellen, Programmcode und Dokumentation. Weitere Garanten für eine höhere Qualität sind der durch den Generator vorgegebene stringente Implementierungs- und Architekturrahmen sowie die Trennung von Fachlichkeit (Modell) und Technik (generierter Code). Durch die Reduzierung von Routinetätigkeiten (z. B. Erstellen der Persistenzschicht mit Hibernate), die Formalisierung von Analyse- und Designergebnissen sowie früheres Feedback durch generierte Prototypen (insbesondere GUI) wird die Effizienz der Entwicklung gesteigert. Da beim Einsatz von Sculptor keine Eigenentwicklung des Generators nötig ist und alle Sculptor-Projekte gleich aufgebaut sind, d. h. die Projektstrukturen vereinheitlicht sind, potenzieren sich die Vorteile beim Einsatz in mehreren Projekten. Das wiederum ermöglicht eine deutliche Produktivitätssteigerung. Das Sculptor-Projekt hat es sich außerdem zum Ziel gesetzt, modellgetriebene Entwicklung mit der Domain-Driven-Design-Vorgehensweise zu vereinen und so Softwareprojekte bei der Entwicklung zu unterstützen. 42 I NEWS 02/2011

Business t Informationstechnologie t Vorstellung Domain Driven Design Es wird von folgenden Annahmen ausgegangen: Domain Driven Design (DDD) definiert sich als eine Denk- und Herangehensweise an die Probleme eines bestimmten Fachbereichs, der Domäne. Die Herangehensweise kann von Fall zu Fall abweichen, konzentriert sich im Wesentlichen aber immer darauf, dass die größte Komplexität in Projekten nicht aus technischen Gegebenheiten heraus, sondern aus dem Tagesgeschäft des Endanwenders der Software entsteht. Domain Driven Design ist nicht an eine bestimmte Technologie oder Methodik zur Erstellung von Software gebunden. Um zu verhindern, dass die fachliche Ausdrucksweise von Analyse nach Entwicklung überführt werden muss, führt Domain Driven Design das zentrale Konzept der sogenannten ubiquitous language – übersetzt in etwa „allgegenwärtige Sprache“ – ein. Diese gemeinsame Sprache, die fachliche Experten zusammen mit Softwareentwicklern während der Entwicklung eines Domänenmodells finden und definieren müssen, ist entscheidend für den Erfolg des Softwareprojekts. Wenn sich die beiden Gruppen von vornherein auf eine gemeinsame Sprache verständigen, entfällt die Übersetzung des Analysemodells in das Implementierungsmodell, und die Entwicklung kann schneller und effizienter durchgeführt werden. Dazu startet man mit einem einfachen, aber präzisen gemeinsamen Modell von Domänenexperten und Entwicklern, verfeinert dieses dann zusammen mit den Domänenexperten und reichert es um relevante Informationen und Methoden an. Am Ende erhält man somit ein gemeinsames Domain-Model für Domänenexperten und Entwickler, das nicht unbedingt die Realität widerspiegelt, aber die für die zu erstellende Software wichtigen Aspekte der Realität abbildet. Anwendungsbeispiel Am Beispiel einer Baufinanzierungserfassungsanwendung wird im Folgenden kurz dargestellt, wie ein Sculptor-Modell in textueller DSL aussehen würde. Das Modell ist für diesen Artikel stark vereinfacht. > Ein Baufinanzierungsantrag soll 1 bis n Darlehensnehmer und ein Darlehensobjekt besitzen. > Die Anwendung soll die Baufinanzierungsanträge verwalten, d. h., es muss mindestens die Möglichkeit der Suche mit einem Filter geben. Listing 1 zeigt ein mögliches zugehöriges Sculptor-Modell. Es werden drei Arten von Domain-Objekten unterschieden. Entities haben eine Identität als wichtigstes Merkmal sowie Attribute und Methoden inklusive Businesslogik. Die Identität kann über die Systemgrenzen hinaus „leben“. So kann z. B. ein in einem Baufinanzierungsantrag erfasster Darlehensnehmer mit seiner eigenen Identität (Kundennummer) in einem CRM-System weiter existieren und mehrere Verträge besitzen. Über an der Entität definierte Methoden wird das Domain-Model um Businesslogik oder fachlich atomare Aktionen (wie z. B. das Ändern der Postleitzahl zusammen mit dem Ort) angereichert und zum „Rich Domain Model“ oder „Rich Model“. Modelle ohne Fachlogik dagegen werden etwas abfällig als „anemic“, also blutleer bezeichnet. Der Grund für diese Bezeichnung ist, dass Anemic-Modelle das Verhalten der Domänenobjekte gar nicht oder nur unzureichend beschreiben. Im Gegensatz zu einem Entity hat ein persistentes Value Object keine Identität, hier sind nur die Eigenschaften des Objektes wichtig. Wichtig ist in diesem Zusammenhang die Unterscheidung von Value Objects und Data-Transfer-Objekten. Die Data- Transfer-Objekte dienen dem Transport von nichtpersistenten Daten (z. B. Filterkriterien für eine Suche) oder werden verwendet, um die Übertragung nur eines Teils der Daten aus Entitäten performant zu bewerkstelligen. Transferobjekte sind somit auch nicht Teil der Domäne, sondern gehören zur Service Facade und dienen – wie der Name schon sagt – rein dem Austausch der Daten mit dem Client. Im DDD-Kontext werden Value Objects hingegen als persistente Objekte ohne eigene Identität definiert, die in der Regel auch immutable, also nicht veränderbar sind, nachdem sie erzeugt wurden. Einkommen oder Vermögen des Darlehens- NEWS 02/2011 I 43

msg

01 | 2018 public
02 | 2017 public
01 | 2017 public
02 | 2016 public
01 | 2016 public
02 | 2015 public
01 | 2015 public
01 | 2014 public
01 | 2014 msg systems study
01 | 2015 msg systems Studienband
Future Utility 2030
Lünendonk® Trendstudie
Digitale Transformation | DE
Digital Transformation | EN
DE | inscom 2014 Report
EN | inscom 2014 Report

msgGillardon

03 | 2016 NEWS
02 | 2016 NEWS
01 | 2016 NEWS
03 | 2015 NEWS
02 | 2015 NEWS
01 | 2015 NEWS
02 | 2014 NEWS
01 | 2014 NEWS
02 | 2013 NEWS
01 | 2012 NEWS
02 | 2011 NEWS
01 | 2010 NEWS
MaRisk
01 | 2017 banking insight
01 | 2015 banking insight
01 | 2014 banking insight
01 | 2013 banking insight
01 | 2012 banking insight
02 | 2011 banking insight
01 | 2011 banking insight
01 | 2010 banking insight
2016 | Seminarkatalog | Finanzen

Über msg



msg ist eine unabhängige, international agierende Unternehmensgruppe mit weltweit mehr als 6.000 Mitarbeitern. Sie bietet ein ganzheitliches Leistungsspektrum aus einfallsreicher strategischer Beratung und intelligenten, nachhaltig wertschöpfenden IT-Lösungen für die Branchen Automotive, Banking, Food, Insurance, Life Science & Healthcare, Public Sector, Telecommunications, Travel & Logistics sowie Utilities und hat in über 35 Jahren einen ausgezeichneten Ruf als Branchenspezialist erworben.

Die Bandbreite unterschiedlicher Branchen- und Themenschwerpunkte decken im Unternehmensverbund eigenständige Gesellschaften ab: Dabei bildet die msg systems ag den zentralen Kern der Unternehmensgruppe und arbeitet mit den Gesellschaften fachlich und organisatorisch eng zusammen. So werden die Kompetenzen, Erfahrungen und das Know-how aller Mitglieder zu einem ganzheitlichen Lösungsportfolio mit messbarem Mehrwert für die Kunden gebündelt. msg nimmt im Ranking der IT-Beratungs- und Systemintegrationsunternehmen in Deutschland Platz 7 ein.


© 2018 by msg systems ag - powered by yumpu Datenschutz | Impressum