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 Modelling and Managing theSoftware Architecture Landscape

in a large Enterpriseby an Extension of the UML

OOPSLA 2002 2nd Workshop on

Domain Specific Visual Languages

2002-11-04

ARCUS-Team

Marcus Heberling, FAST GmbHChristoph Maier, Bayerische LandesbankDr. Thomas Tensi, sd&m AG

ARCUS Software Architecture Modelling

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 method:A model connecting different submodels

server host

client

Business Process Layer

System Architecture Layer

Problem Domain Layer

Logical Application 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






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

Example:Car Shop

offer processorder process

customer salesperson

customer informs himself about models

preparation of offercustomer wants car offer

idream car

zooming invia menu

zooming in

icar offer

imodel catalogue

iconfiguration catalogue

ifinancing 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

*

<<Assignment>>

<< Information Flow >>

behaviour

*

*

*

*

*

*

Target

1

0..1

0..1

0..1

1

1

*

*

Condition Iteration Clause

EventSynchronizerExecution Variant

Process

Flow Net

Activity

Event

Information

Actor

Flow ElementTransition

Source

<<transition>>

AttributedFlow Net

*

{istNotOfType(Business_Process)}

Generic Process << Information Flow >>

*

*

<< Implementation >>

*

*

The metamodel ist defined by a structured text file and not hard-wired in the tools!

Metamodel: Business Process Layer


11

Textual Definition of the Metamodel (Extract)

------------------------------------------------------------------ Business Process Layer -----------------------------------------------------------ELEMENT NAME=Role DETAILABLE=FALSE REMOTE_VALID=FALSE ELEMENTGROUP=AkteurEND ELEMENT

ELEMENT NAME=Org-Unit DETAILABLE=TRUE REMOTE_VALID=FALSE ELEMENTGROUP=Org-UnitEND ELEMENT

ELEMENTGROUP NAME=Org-Unit SUPERGROUP=ActorEND ELEMENTGROUP

ELEMENTGROUP NAME=Actor SUPERGROUP=BusinessProcessLayerEND 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_RELATIONEND RELATIONS


12


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

Example:Car Shop

Order

*

1

*

1manages

1..*

Equipment package

Offer

*

1

*

1manages

Equipment

0..*1 0..*1

1

1

Car

1..*

1

V is interested in

Customer

Loan

*

1

1

Financing 0..1 0..11 0..11

Radio Air condition LM-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


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

Online-Car-Catalogue

Offer- and Order-Management

Example:Car Shop

OOM-Client

employee master data

Access Rights Component

car inventory catalogue basic equipment catalogue

extra equipment catalogue

customer master data

offer master data

Car Component Sales Component

GUI-Component

Component

ApplicationData


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

Geschäftspartner-PCs

Kunden SB-Terminals Verkäufer PCs (NT)

Zentraler Server (NT)Autohaus LAN

FirewallInternet Internet-Server

Clientstations Netzwerk Server Firewall


18

Verkäufer PCs (NT)

Zentraler Server (NT)

Autohaus LAN

Beispiel (2):Client/Server-Struktur

Angebots- und Bestellungssystem (proxy)

Angebots- und Bestellungs-GUI

Fahrzeugmodellsystem (proxy)

Angebots- und Bestellungssystem Fahrzeugmodellsystem

Oberflächen-Programm

Proxy fürSoftwaresystem

Softwaresystem


19

Ebenenübergreifende Beziehungen

*

*

*

Aktivität

Klasse

Prozeßarchitekturebene

Anwendung Komponente

Information

Daten

Fachbegriffsarchitekturebene

AnwendungsarchitekturebeneAnwendungselement

Anw-Modul

Systemarchitekturebene

Softwaresystem ProgrammSW-ModulDaten(Ebene 4)

*

**

**

**

**

*

*

* *

* *

* *

* *

*

Akteur

*

*

*

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

Auto Ausstattung

Ausstattungspaket

AngebotKunde

Darlehen

Grundausstattung festlegen Sonderausstattung festlegenAngebot erstellen Bestellprozeß

Angebots- und BestellungsverwaltungFahrzeugfachkernVerkaufsfachkern


21

am Selbstbedienungsterminal informieren

Autobestandskatalog

Grundausstattungskatalog

Sonderausstattungskatalog

FahrzeugdatenbankFahrzeugmodellsystem

Modelldatensystem

Auto Ausstattung

Online-FahrzeugkatalogFahrzeugmodell

„Ebenendurchstich“

Nutzen:ebenenübergreifende Beziehungen erlauben systematische Erforschung des Modells

zusätzlich:automatisch generierte Beziehungen (abgeleitete Beziehungen)

«abgeleitet»


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

• 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

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

Documents

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