ARCUS-Team Marcus Heberling , FAST GmbH Christoph Maier , Bayerische Landesbank Dr. Thomas Tensi , sd&m AG

1. Visual Modelling and Managing theSoftware Architecture Landscapein a large Enterpriseby an Extension of the UMLOOPSLA 20022nd Workshop onDomain Specific Visual Languages2002-11-04 ARCUS-TeamMarcus Heberling, FAST GmbHChristoph Maier, Bayerische LandesbankDr. Thomas Tensi, sd&m AG

2. Outline of the Talk • Goals of ARCUS • Metametamodel and the UML • ARCUS-Modelling in Detail • Tools • Demonstration

3. Goals of ARCUS • Formal overview over all software applications in a large enterprise • usable even for non-IT-experts • Consistent, integrated and navigable documentation • ... of business processes and business notions • ... across the logical design of the applications • ... to the concrete hardware and software structure • Explicit description of actual and target application landscape resembling a “land use plan“

4. Benefit of an Enterprise Application Architecture Model Centrally available information on • how business areas are supported by applications, • how new requirements (e.g. new technology platforms) influence existing applications, • how to reuse existing solutions, • how to restructure the application landscape, • ...

5. Boundary Conditions • Tools: Rational Rose & Rational ClearCase • Notation: UML extended by standard mechanisms • stereotypes, tagged values • Metamodel: freely configurable, not hard-wired • see below • Implementation: only with the standard resources of Rose • RoseScript • Exploration of the model by successive completion of diagrams • not via complex queries

6. server host client ARCUS method:A model connecting different submodels Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer

7. ARCUS-Metamodel and the UML • Metamodel: model elements and rules • model elements in all 4 layers are UML classes • distinction done by stereotypes • rules (for easy optical recognition) • relation within a layer have to be associations • detailing relation modelled by aggregation or composition • inter-layer-relations have to be dependencies • Rose is used as a metamodel engine. „ARCUS-model-checker“ does a a-posteriori check of the metamodel rules.

8. Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer Business Process Layer • The business process layer describes the business relevant processes which are supported by applications. • ARCUS uses flow networks(which are UML-activity diagrams with some extensions).

9. i model catalogue define car model [customer wants extra configuration] offer process order process i define basic configuration configuration catalogue customer salesperson define extra configuration [customer wants financing] preparation of offer customer informs himself customer wants car characteristics are about models car offer defined i offer car financing car offer i i prepare offer financing offer dream car Example:Car Shop Process zooming in via menu Action Role zooming in Event Information

10. Metamodel: Business Process Layer The metamodel ist defined by a structured text file and not hard-wired in the tools!

11. -------------------------------------------------- ---------------- Business Process Layer --------- -------------------------------------------------- ELEMENT NAME=Role DETAILABLE=FALSE REMOTE_VALID=FALSE ELEMENTGROUP=Akteur END ELEMENT ELEMENT NAME=Org-Unit DETAILABLE=TRUE REMOTE_VALID=FALSE ELEMENTGROUP=Org-Unit END ELEMENT ELEMENTGROUP NAME=Org-Unit SUPERGROUP=Actor END ELEMENTGROUP ELEMENTGROUP NAME=Actor SUPERGROUP=BusinessProcessLayer END ELEMENTGROUP RELATIONS SOURCES = Activity VALID_RELATION KIND=association STEREOTYPNAME=“Assignment" NAMING_CONVENTION="" TARGETS = { Actor } END VALID_RELATION VALID_RELATION KIND=association STEREOTYPNAME=“Information Flow" NAMING_CONVENTION="" TARGETS = { Information } END VALID_RELATION -- inter-layer relations VALID_RELATION KIND=dependency STEREOTYPNAME="Trace" NAMING_CONVENTION="" ZIELE = { ProblemDomainLayer, Application, Component } END VALID_RELATION END RELATIONS Textual Definition of the Metamodel (Extract)

12. Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer Problem Domain Layer • The problem domain layer describes the business notions by types and objects with their static and dynamic relations. • focus on important business notions • ARCUS uses the standard UML static structure diagrams (i.e. class diagrams).

13. < cares for Salesperson 0..* 1 1 1 1 1 1 manages manages Customer 1 * * * * * Loan V is interested in Financing 0..1 1 1 1 0..1 0..1 Offer Order 1..* 1 1 1 1 0..* 0..* Car 1..* Equipment Equipment package Radio Seat heater Air condition LM-Rim Example:Car Shop Rules: All rules for UML-diagrams are valid except:dependencies may not be used. Those are reserved in ARCUS for inter-layer-relations.

14. Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer Logical Application Layer • The logical application layer describes an abstract logical view of the application structure • the applications, • the components of the applications, • the business data and • relations between those elements. • It is a business view on the IT-systems. Modeling is done independent of the technical realization!

15. OOM-Client Offer- and Order-Management Access Rights Component Car Component Sales Component customer master data car inventory catalogue basic equipment catalogue Online-Car-Catalogue offer master data employee master data extra equipment catalogue Example:Car Shop GUI-Component Component Data Application

16. Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer Systemarchitektur: Allgemeines • Die Systemarchitekturebene ist die Realisierungs-ebene der Anwendungslandschaft und besteht aus einer Hardware- und Softwaresicht. • Die Hardwaresicht beschreibt die physische Rechnerlandschaft und deren Topologie. • Die Softwaresicht modelliert die EDV-technische Realisierung der logischen Anwendungsarchitektur. • ARCUS definiert hierfür 7 hardware- und 21 softwarespezifische UML-Stereotypen.

17. Firewall Internet Internet-Server Autohaus LAN Zentraler Server (NT) Kunden SB-Terminals Verkäufer PCs (NT) Beispiel (1):Hardware von Autohandel Netzwerk Firewall Clientstations Server Geschäftspartner-PCs

18. Angebots- und Bestellungssystem Fahrzeugmodellsystem Beispiel (2):Client/Server-Struktur Oberflächen- Programm Proxy für Softwaresystem Softwaresystem

19. Ebenenübergreifende Beziehungen • Man muss auch Verbindungen zwischen den Ebenen erfassen. Dafür gibt es ein Modell der erlaubten Abhängigkeiten zwischen den Architekturebenen.

20. Angebot erstellen Grundausstattung festlegen Sonderausstattung festlegen Bestellprozeß Fahrzeugfachkern Darlehen Ausstattungspaket Angebots- und Bestellungsverwaltung Kunde Angebot Auto Ausstattung Verkaufsfachkern Bsp.: Definition der ebenenübergreifenden Beziehungen

21. am Selbstbedienungsterminal informieren Auto Ausstattung Fahrzeugmodell Online-Fahrzeugkatalog Grundausstattungskatalog Sonderausstattungskatalog «abgeleitet» Autobestandskatalog Modelldatensystem Fahrzeugdatenbank Fahrzeugmodellsystem „Ebenendurchstich“ • Nutzen: • ebenenübergreifende Beziehungen erlauben systematische Erforschung des Modells • zusätzlich:automatisch generierte Beziehungen (abgeleitete Beziehungen)

22. Werkzeuge • Modellierung in Rational Rose erweitert um diverse Skripten zur • Generierung von Modellteilen (z.B. abgeleitete Beziehungen) • Navigation im Modell (z.B. Zoomen in Details) • Suchen im Modell • Prüfung der Wohlgeformtheit des Modells • Export (in relationale DB, als HTML-Ausgabe usw.) • Versionsverwaltung (Anbindung an Rational ClearCase) • Sprache: um Modulkonzept, Typen und strukturierte Ausnahmen erweitertes RoseScript-Basic • Umfang: circa 80 Module mit 1,2MB Umfang (~40.000 LOC)

23. Beispiel für Werkzeuge (Suche im Modell) Elementsuchdialog Werkzeugleiste

24. Anbindung an Konfigurationsverwal-tung ClearCase Ebene Elementart Geschäftsf. Anwendung • hohe Zahl von Modellelementen • >5000 Klassen, >5000 Beziehungen • starke Paketierung des Systems zur Abschottung unterschiedlicher Architekturebenen, Geschäftsfelder und Projekte • versionierte Einheit  Paket • circa 800 versionierte Einheiten • sehr flexible Konfigurierbarkeit über regelbasierte Auswahl von versionierten Einheiten (ClearCase „Config Specs“) • z.B. Mischung von Ist- und Soll-Modellen aus unterschiedlichen Geschäftsfeldern möglich ...

25. Erfahrungen mit Werkzeugumgebung • Rational Rose ist kein Metamodellierungswerkzeug • mit RoseScript nur Prüfung im Nachhinein (optional; wie ein Compiler) • Korrektheit per Konstruktion über Mechanismen von RoseScript nicht erreichbar • Verwaltung der extremen Granularität des Gesamtmodells führt mit ClearCase zu größeren Reaktionszeiten • repositorybasierter Ansatz wahrscheinlich sinnvoll • sehr gute Erweiterbarkeit von Rational Rose für spezifischen Anwendungsbereich • robuste und reichhaltige Programmierschnittstelle • auch Oberflächenanpassung möglich • leistungsfähige Skriptsprache • freie Konfigurationszusammenstellung über ClearCase sehr flexibel • Ist-/Sollmodellteile frei kombinierbar