Visual Modelling and Managing the Software Architecture Landscape in a large Enterprise by an Extension of the UML OOPSLA 2002 2nd Workshop on Domain Specific.

Präsentation zum Thema: "Visual Modelling and Managing the Software Architecture Landscape in a large Enterprise by an Extension of the UML OOPSLA 2002 2nd Workshop on Domain Specific."—  Präsentation transkript:

1 Visual Modelling and Managing the Software Architecture Landscape in a large Enterprise by an Extension of the UML OOPSLA 2002 2nd Workshop on Domain Specific Visual Languages 2002-11-04 ARCUS-Team Marcus Heberling, FAST GmbH Christoph Maier, Bayerische Landesbank Dr. Thomas Tensi, sd&m AG

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

3 ARCUS Software Architecture Modelling 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 ARCUS Software Architecture Modelling 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 ARCUS Software Architecture Modelling 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 ARCUS Software Architecture Modelling 6 ARCUS method: A model connecting different submodels serverhost client Business Process Layer System Architecture Layer Problem Domain Layer Logical Application Layer

7 ARCUS Software Architecture Modelling 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 ARCUS Software Architecture Modelling 8 Business Process Layer Problem Domain Layer Logical Application Layer System Architecture 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 ARCUS Software Architecture Modelling 9 Example: Car Shop offer process order process customersalesperson customer informs himself about models preparation of offer customer wants car offer i dream car zooming in via menu zooming in i car offer i model catalogue i configuration catalogue i financing offer define car model prepare offer offer car financing define basic configuration car characteristics are defined [customer wants financing] define extra configuration [customer wants extra configuration] Process Role Information Event Action

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

11 ARCUS Software Architecture Modelling 11 Textual Definition of the Metamodel (Extract) -------------------------------------------------- ---------------- 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

12 ARCUS Software Architecture Modelling 12 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). Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer

13 ARCUS Software Architecture Modelling 13 Example: Car Shop Order * 1 * 1 manages 1..* Equipment package Offer * 1 * 1 manages Equipment 0..* 1 1 1 1 Car 1..* 1 V is interested in Customer Loan * 1 1 Financing0..1 1 1 RadioAir conditionLM-RimSeat heater Salesperson 0..* 1 < cares for Rules: All rules for UML-diagrams are valid except: dependencies may not be used. Those are reserved in ARCUS for inter-layer- relations.

14 ARCUS Software Architecture Modelling 14 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! Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer

15 ARCUS Software Architecture Modelling 15 Online-Car-Catalogue Offer- and Order-Management Example: Car Shop OOM-Client employee master data Access Rights Component car inventory cataloguebasic equipment catalogue extra equipment catalogue customer master data offer master data Car ComponentSales Component GUI-Component Component Application Data

16 ARCUS Software Architecture Modelling 16 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. Business Process Layer Problem Domain Layer Logical Application Layer System Architecture Layer

17 ARCUS Software Architecture Modelling 17 Beispiel (1): Hardware von Autohandel Geschäftspartner-PCs Kunden SB-TerminalsVerkäufer PCs (NT) Zentraler Server (NT) Autohaus LAN Firewall Internet Internet-Server Clientstations Netzwerk Server Firewall

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

19 ARCUS Software Architecture Modelling 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 ARCUS Software Architecture Modelling 20 Bsp.: Definition der ebenenübergreifenden Beziehungen AutoAusstattung Ausstattungspaket AngebotKunde Darlehen Grundausstattung festlegenSonderausstattung festlegen Angebot erstellen Bestellprozeß Angebots- und Bestellungsverwaltung Fahrzeugfachkern Verkaufsfachkern

21 ARCUS Software Architecture Modelling 21 am Selbstbedienungsterminal informieren Autobestandskatalog Grundausstattungskatalog Sonderausstattungskatalog Fahrzeugdatenbank Fahrzeugmodellsystem Modelldatensystem AutoAusstattung Online-Fahrzeugkatalog Fahrzeugmodell Ebenendurchstich Nutzen: ebenenübergreifende Beziehungen erlauben systematische Erforschung des Modells zusätzlich: automatisch generierte Beziehungen (abgeleitete Beziehungen) «abgeleitet»

22 ARCUS Software Architecture Modelling 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 ARCUS Software Architecture Modelling 23 Beispiel für Werkzeuge (Suche im Modell) Elementsuchdialog Werkzeugleiste

24 ARCUS Software Architecture Modelling 24 Anbindung an Konfigurationsverwal-tung ClearCase 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 Ebene Elementart Geschäftsf. Anwendung...

25 ARCUS Software Architecture Modelling 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