Visual%20Modelling%20and%20Managing%20the%20Software%20Architecture%20Landscape%20in%20a%20large%20Enterprise%20by%20an%20Extension%20of%20the%20UML%20%20OOPSLA%202002%202nd%20Workshop%20on%20Domain%20Specific%20Visual%20Languages%20%202002-11-04

1
Visual Modelling and Managing theSoftware
Architecture Landscapein a large Enterpriseby
an Extension of the UML OOPSLA 2002 2nd
Workshop onDomain Specific Visual Languages
2002-11-04

• ARCUS-TeamMarcus Heberling, FAST GmbHChristoph
  Maier, Bayerische LandesbankDr. Thomas Tensi,
  sdm 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
ARCUS methodA 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
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
ExampleCar 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
Textual Definition of the Metamodel (Extract)

• --------------------------------------------------
  
• ---------------- Business Process Layer
  ---------
• --------------------------------------------------
  
• ELEMENT
• NAMERole
• DETAILABLEFALSE
• REMOTE_VALIDFALSE
• ELEMENTGROUPAkteur
• END ELEMENT
• ELEMENT
• NAMEOrg-Unit
• DETAILABLETRUE
• REMOTE_VALIDFALSE
• ELEMENTGROUPOrg-Unit
• END ELEMENT
• ELEMENTGROUP
• NAMEOrg-Unit

• RELATIONS
• SOURCES Activity
• VALID_RELATION
• KINDassociation
• STEREOTYPNAMEAssignment"
• NAMING_CONVENTION""
• TARGETS Actor
• END VALID_RELATION
• VALID_RELATION
• KINDassociation
• STEREOTYPNAMEInformation Flow"
• NAMING_CONVENTION""
• TARGETS Information
• END VALID_RELATION
• -- inter-layer relations
• VALID_RELATION

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).

13
ExampleCar Shop
Rules All rules for UML-diagrams are valid
exceptdependencies may not be used. Those are
reserved in ARCUS for inter-layer-relations.
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!

15
ExampleCar Shop
GUI-Component
Component
Data
Application
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.

17
Beispiel (1)Hardware von Autohandel
Netzwerk
Firewall
Clientstations
Server
Geschäftspartner-PCs
18
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
Bsp. Definition der ebenenübergreifenden
Beziehungen
21
Ebenendurchstich

• Nutzen
• ebenenübergreifende Beziehungen erlauben
  systematische Erforschung des Modells
• zusätzlichautomatisch 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
• gt5000 Klassen, gt5000 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