1212 30.10.2001 Grundlagen: Units VL Software Architektur-Modelle Dr. Harald Störrle Vorbereitung ·FAA auf Folie ? ·Gliederung auf Folie ·Spektrum-Bericht

30.10.2001Grundlagen: Units

VL Software Architektur-Modelle

Dr. Harald Störrle12

Vorbereitung

· FAA auf Folie ?· Gliederung auf Folie· Spektrum-Bericht über Windows2k

(##) als Handout kopieren· alle ?? entfernt?!




Vorbereitung

· Beamer, Laptop, Maus· 2 Exemplare der Diss· Anwesenheitsliste· Handout

• Artikel aus Spektrum d. Wiss: Windows2k

· Fragen?




Vorlesung

Software Architektur-ModelleGrundlagen 1: Einheiten („Units“)

Dr. Harald Störrle

Ludwig-Maximilians-Universität MünchenWintersemester 2001




Organisatorisches

• Feedback [email protected]

• Gastvortrag 18.12., Norbert Grass, IBM S/390 („Host“)

• Folienlayout

• WWW-Angebot - Probleme gelöst (?)www.pst.informatik.uni-muenchen.de/lehre/WS0102/architektur

• Aufgaben vom letzen Mal




Einleitung– Architektur-Einheiten („Units“)– Modellierungs-Notationen (UML, ...)– Semantik-Formalismen (CSP, PN; Traces, LTS, PW)– Wright– Darwin– UML/AM– Konsistenz, Verifikation– S/390 („Host“) & CICS vs. EJB & Applicationserver– Grundbegriffe am Beispiel Änderungsverwaltung– elementare Methodiken– Validation, Soft-FactorsRückschau

SemestervorschauÜberblick (neu)

Prozesse

ADLs

Grundlagen3

5

3

Host vs. EJB




Organisatorisches

• Feedback [email protected]

• Gastvortrag 18.12., Norbert Grass, IBM S/390 („Host“)

• Folienlayout, WWW-Angebotwww.pst.informatik.uni-muenchen.de/lehre/WS0102/architektur

• Buch - bitte nach der Vorlesung abholen

• Aufgaben vom letzen Mal




Aufgaben vom letzten Mal

· Lektüre – Vorlesungsseite besuchen, im Netz stöbern

· Beispiele finden– Finden Sie Beispiele für Systeme mit SWA in Ihrer

täglichen Umwelt! Identifizieren Sie Stakeholder und deren Anforderungen. Gibt es Konflikte?

· Vorbereitung– Schauen Sie sich EJBs, BOs, & UML Components an

· Entscheiden Sie sich, ob Sie teilnehmen!




Programm für heute

· Was heißt eigentlich „große Systeme“?

· Aus was für Einheiten sind sie aufgebaut?

· Welche Anforderungen müssen diese Einheiten erfüllen?

· Erste Notationen




Was heißt eigentlich „groß“?

Größe in Anzahl Dauer der LoC EntwicklerErst-

Entwicklung

sehr groß 106-108 102-104 5-15 Jahre groß 105-106 101-102 2-5 Jahre

System Zeilen CodeWindows 2000 29 Mio.große militärische SW 27 Mio.typische Unternehmens-SW 19 Mio.typisches BS 12 Mio.




Große Software ist anders

· Die Herstellung großer SW-Systeme ist ein inhärent eigenes Problem

– Proportionen von Phasen und Aufwänden – bis zu 95% des Gesamtaufwandes gehen in Tests:

Kosten für Definition, Bereitstellung und Administration von Testumgebung, Testfällen, Testergebnissen. Regressionstests!

– nicht enthalten: konstruktive QS-Maßnahmen.

– Aufgaben– KM/ÄM wird zu einem enorm wichtigen Thema

– typischen Probleme– Mitarbeitermotivation (Fluktuation, innere Kündigung, Politik)– Kommunikationsaufwand wächst mindestens quadratisch– ebenso der Aufwand für Planung und Controlling




Große Software ist anders

· Daher gibt es entscheidende Unterschiede zwischen großen und kleinen Projekten bezüglich:

– Infrastrukturen– Organisationsformen, Kommunikationswege und -mittel – Methodik, Werkzeuge, Aktivitäten, Phasen– Schwerpunkte, Probleme, Aufgaben– Beteiligte...=> letztlich bezüglich ALLER Aspekteund: große Systeme brauchen eine Architektur

· Siehe zum Beispiel Windows2000.




Windows 2k als Großprojekt

• Bislang größtes kommerzielles System• Ca. 27 Mio. LoC (meistenteils C++)• täglicher Build-Test-Zyklus• kontrolliertes Ignorieren von Fehlern• wöchentliches Motivationstreffen

– ca. 4200 Leute– halber Tag

• ca. 90.000 Emails täglich• täglich aktualisiertes Download von Sourcen• über Nacht werden ca. 2000 CDs gebrannt &

verteilt




Was heißt groß bei Systemen?

· Ausstattung von Siemens Business Services (SBS), Stand Ende 2000

– 35 Mainframes– 1.140 Unix/NT-Server mit insgesamt 257 TByte– 3.120 Workstations– 3.100 Leitungen– 2.100 Router mit insgesamt 500 Tbit/s Volumen– 2.750 UNIX/NT-Server– 72.500 PCs– 170.000 Terminals und Peripherie-Geräted

ezen

tral

zen

tral




Was sind Einheiten?Einmal Träumen, bitte

Einheiten sind...

...langlebig

...wiederverwendbar

...integrierbar

...robust

...verteilbar

...getrennt entwickelbar (bzw. beschaffbar)

...Gegenstand von Verhandlungen & Verträgen




Was sind Einheiten?Terminologie· Einheiten sind die „Bausteine“, aus denen

sich Architekturen zusammensetzen.· Diese Bausteine werden durch „Mörtel“ zu

einem „Ensemble“ zusammengefügt.

· TerminologieBausteine Components

Mörtel Glue (Connectors, Ports)Ensemble Configuration




Was sind EinheitenVom Traum zur Realität

· Wie müssen Einheiten beschaffen sein, welche Eigenschaften müssen sie aufweisen, um unsere Ziele zu erreichen?

· Zwei Beobachtungen aus der Praxis helfen uns, Fehler früherer Ansätze zu vermeiden.




Empirische Ergebnisse 1/2

· Frühe Fehler sind die teuersten.




Schlußfolgerung: durchgängig

· Die Bausteine einer Architektur müssen schon frühzeitig im Zuge eines Projektes definiert werden, nicht erst zur Implementierungszeit.

· Daher müssen sie als Modelle vorliegen, nicht (nur) als Code.

· Um gleichzeitig die Übersicht zu gewährleisten, sollten sie durch Sichten organisiert sein.




Exkurs: Sichten/Sichtweisen(engl.: View/Viewpoint)

Vorschläge• Kruchten „4+1 View Model“

physical, logical, scenarios, process, development

• Amigos „UML Manual“deployment, design, use case, implementation, process

• RM-ODP (ISO/IEC 10746-a...d bzw. ITU-T X.901...904)information, enterprise, technology, engineering, computation

• Davis/Williamscomponent, domain, context, interfaces, platform




Exkurs: Sicht/Sichtweise

• Wie ist ihre Beziehung zueinander?• Wie ist ihre Beziehung zu UML?

• Wie werden die Sichten dargestellt?

• Welche Sichten sollten fixiert werden?• Für alle Anwendungen die gleichen Sichten?

• Lösung: IEEE Architecture Working Group, P1471• generisches Konzept Sicht/Sichtweise




Exkurs: Sichten in P1471

· „a view is a representation of a whole system from the perspective of a related set of concerns“

· „a viewpoint is a specification of the conventions for constructing and using a view“

-- Ende des Exkurses --





· Studien zeigen: nur in frühen Phasen ist Wiederverwendung effektiv:• dort geht es um große Einheiten• die Domänen- oder Systemwissen kodifizieren• und relativ leicht änderbar sind

· Daher ist Wiederverwendung von kleinen Einheiten (z.B. Klassen) unwirtschaftlich.





Kosten vs. Nutzen bei Wiederverwendung

n Nutzen in LoCk Kosten Aktivität abhängig von

kq query Formulieren der Suchanfrage Expertise in der Wv.-Domäne

ks Search Suche in Komponenten-DB Größe der DB

kc choice Auswahl der Kandidaten Recall, Qualität der Ergebnisse, Expertise des Bearbeiters

ka adapt Anpassen Precision & Größe

ki integrate Integrieren in Gesamt-System Komplexität der Schnittstelle

Die Kosten sind nur wenig abhängig von der

Menge des wiederverwendeten Codes.




Schlußfolgerung: groß

· Die wiederzuverwendenden Komponenten sollten möglichst groß sein.

· Einschränkung: mit steigender Größe steigt der durchschnittliche Anpassungsaufwand.




Schlußfolgerung: autark

· Daher müssen die Einheiten sehr autark sein, d.h. unabhängig und selbstgenügsam („self-containedness“).

· Insbesondere müssen sie sehr harte, wohl-kontrollierte schmale Schnittstellen aufweisen.




Schlußfolgerung: formal

· Um die Kosten zu reduzieren, müssen Arbeitsschritte automatisiert werden.

· Um auf Modellen automatisiert arbeiten zu können, müssen die Modelle formal sein.

· Um gleichzeitig Akzeptanz zu erreichen, muß diese Formalität versteckt werden.




Zusammenfassung der Anforderungen

· Damit Einheiten als Architektur-Einheiten wirklich einsetzbar sind, müssen sie folgendes sein:

• Durchgängig - in allen Phasen brauchbar• Groß - von großer Granularität• Autark - sehr unabhängig• Formal - aber bitte verständlich!




Erfüllen heutige Ansätze diese Anforderungen?

· Welche Ansätze gibt es?• Klassen/Objekte• Java Beans (und ähnliche)• Enterprise Java Beans (EJBs)• UML Components• UML Subsystems• Business Objects

• Units




Klassen/Objekte

· Sehr kleine Einheiten

· starke Abhängigkeit zum Kontext

· nur Zugriffskontrolle nach innen, nicht nach außen, nur alles-oder-nichts Kontrolle

· Analyse-Klassen haben keinen Bezug zu Implementations-Klassen („semantic gap“)




Java Beans (und ähnliche)

· Java-Klassen mit einigen zusätzlichen Namenskoventionen.

· Gleiche Kritik wie bei Klassen/Objekten




Enterprise Java Beans (EJB)• Mehr als Java Beans• Ablaufumgebung (Application Server) stellt

gewisse Basisdienste zur Verfügung(Persistenz, Transaktionskotrolle, Sicherheit, Naming,

Kommunikation, ...)

• Probleme– kleine Einheiten– sehr implementierungslastig– einige ungelöste technische Probleme

• zur Zeit Integration– mit Corba 3 als „Corba Component Model“ (CCM), und – mit UML als „UML Profile for EJBs“




UML Components

In UML 1.4 sind Components Bit-Folgen

„A component represents a physical piece of implementation of a system“

=> genau nicht das, was man braucht




UML Subsystems

Pakete mit 2-3 Kompartimenten

+ richtige Granularität+ Im Prinzip durchgägngig verwendbar

- vage Definition, keine Semantik- keine Konzepte für

• Schnittstellen• Sichten




Business Objects

Business Objects sind

„...interoperable [...] high-level application components relevant to and usable by application domain developers...“ (OMG BO-RFP, cf/96-01-04)




Business Objects

· Interne Schichtung• Präsentation

– GUI– Dialog-Steuerung

• Applikation– Dienste– Anwendungs-Logik

• Persistenz– DB-Zugriff– DB




Business Objects

Aufgaben der GUI-Schicht· Anzeige der graphischen Schnittstelle· Eingaben auffangen und kanalisieren

· Dies „dünne“ Schicht ganz oben ist entscheidend für Portabilität und Multi-Kanalfähigkeit• Desktop (Fat Client)• WAP• Internet (Kunden!)• Intranet• Druckstraße• DMS• Batch-Verarbeitung• ...




Business Objects

Aufgaben der Dialog-Steuerung

· Steuerung der GUI-Schicht· Plausibilisierung· zum Teil auch Sicherheit




Business Objects

Aufgaben der Dienste-Schicht

· Bereitstellung von Diensten für• den Benutzer• die Nachbarsysteme

in einheitlicher und kontrollierter Weise

· Synchronisation· Transaktionssteuereung




Business Objects

Aufgaben der Logik-Schicht

· Implementierung der eigentlichen Fachlogik

· Schritte von Geschäftsprozessen

· Domänenwissen

· fachliche Objekte




Business Objects

Aufgaben der DB-Zugriffs-Schicht· Umsetzung Relationen/Klassen bzw.

Zeilen/Objekte· Umsetzung technische/fachliche Transaktionen,

Schwebeverwaltung (z.B. Halbbuchungen)· Caching und Garbage Collection für fachliche

Objekte· transparenter Daten-/Dateizugriff, optimistische

Sperrstrategie· Versionierung, Historisierung· Unabhängigkeit von DB-Produkten (siehe z.B.

R/3, row-level locking gab`s damals noch nicht)




Business Objects

Aufgaben der DB-Schicht

· klassische DB-Aufgaben, also

· Persistenz

· Recovery-Fähigkeit

· Performanz

· Konsistenz· ...




Business Objects

+ Richtige Granularität+ Abgeschlossenheit+ erste Werkzeuge

- aufwändig, relativ starr- keine präzise Definition- Durchgängigkeit?- Sichten?- Kein Bezug zu UML




Units

· Einheiten sind aufgebaut aus einer (beliebigen) Menge von Sichten, idR. ist eine davon die Schnittstellen-Sicht, die Ports enthält.

· Ein Port kontrolliert eingehende wie ausgehende Nachrichten.

· Alle Kommunikationen einer Einheit geht über Ports.




Units

· „kleines“ Konzept• Verallgemeinerung von Business Objects• Paßt auch auf andere Ansätze

· Anforderungen erfüllt?+ Durchgängigkeit / frühe Phasen+ Autark + Granularität+ UML-Integration + Formal




Literatur (zur Nachbereitung)

· Technische Komponentenmodelle– EJB 2.0, http://java.sun.com/products/ejb/whitepaper.html– Corba Component Model

· Bücher von Oliver Sims (alle bei Wiley/OMG Press)

– Business Objects (1994)– Building Business Objects (1998, Sims & P. Eeles)– Business Component Factories (2000, Sims & P.

Herzum)




Literatur (zur Vorbereitung)

Bernd Oesterreich:OO Software-Entwicklung mit der UML??, Oldenbourg, 5. Auflage

OMG:The Unified Modelling Languagev1.4, September 2001




Aufgabe

· Beschreiben Sie die Geschäftsprozesse einer Bibliotheka) alle (die sie finden) im Überblickb) einen oder zwei im Detail

· Wie?• Nachdenken oder Interview (Bibliothekar)• Beliebiger Formalismus, Text, ...

· Umfang etwa 1-2 Seiten· Was sind ihre Probleme/Erfahrungen

gewesen?




Nächstes Mal

Unified Modelling Language

Documents

1212 30.10.2001 Grundlagen: Units VL Software Architektur-Modelle Dr. Harald Störrle Vorbereitung ·FAA auf Folie ? ·Gliederung auf Folie ·Spektrum-Bericht