1111 16.10.2001 Einführung VL Software Architektur-Modelle Dr. Harald Störrle Vorbereitung...

16.10.2001Einführung

VL Software Architektur-Modelle

Dr. Harald Störrle11

Vorbereitung

· Raumänderungsaushang· Projektor, Ersatzfolien (?)· Beamer, Laptop· Tafel, Kreide, Ausgedrucktes Skript· Klebepunkte am Eingang verteilen· Teilnehmerbögen· Punktabfrage Erwartungen, fetter

Filzer




Vorlesung

Software Architektur-Modelle

Dr. Harald Störrle

Ludwig-Maximilians-Universität MünchenWintersemester 2001




Ziel heute

· Themenüberblick alsEntscheidungshilfe

· zunächst aber einigesOrganisatorisches




Organisatorisches

• Liste: bitte alle eintragen

• „Skript“: meine Dissertation(Autorenexemplare zu DM 25, statt �35)

• 26.10.: entfällt• Prüfung: Säulen PG & A (Prof. Wirsing)• Aufgaben: 3 Blätter • Schein: nein• Übungen: Bedarf?• Exkursion: Bedarf?




Zur Person

· StudiumInformatik & Psychologie in Tübingen, Hamburg & Edinburgh

· Promotion„Models of Software Architecture“an der LMU, Prof. Wirsing

· IndustrieCompetence Center InformatikFJA AG




· Rang• das führende Beratungs- und Sw-Haus für

Versicherungen im deutschsprachigen Raum

· Mitarbeiter• ca. 850 weltweit, ca. 500 in München

· Niederlassungen• M, M, K, S, HH, B, Zürich, Wien, NY, Maribor

· Lage• 30% Wachstum p.a., seit 1980

(Personal, Umsatz, Gewinn)

Zu FJA




Zum Titel

• Wieso bloß „Modelle“ - „Architekturen“ wären doch interessanter?!

=> SWA muß man praktisch erlernen, also z.B. in langen Jahren industrieller Tätigkeit.

• Man tut sich aber erheblich leichter, wenn man die nötigen theoretischen und technischen Grundlagen hat.

• Und die zu legen ist genau das Ziel dieser Vorlesung.




Motivation

· Warum sollten Sie hier mitarbeiten?

• SWA ist eines der interessantesten, vielseitigsten und praxisrelevantesten Gebiete.

• Das Gebiet wird an der Uni nahezu nicht gelehrt, und wenn, dann in rein akademischer Form.

• Diese Veranstaltung ist wahrscheinlich einmalig.




Motivation: Chancen & Risiken

· Sehr großer thematischer Bogen– viele interessante und relevante Themen, großer Lerneffekt– ABER: roter Faden könnte verloren gehen

· Top-aktuelles Thema– sowohl wissenschaftlich fundiert als auch praktisch erprobt– ABER: anspruchsvoll, viel Arbeit

· Brandneue Vorlesung– interaktiv gestaltbar, ich bin sehr motiviert, VL nicht abgenudelt– ABER: Pannen und Überziehen möglich




Apell zur Mitwirkung

· Bin auf Ihre Mitwirkung angewiesen• Nachsicht bei Pannen• Fragen• Diskussionen• Übungsaufgaben• Feedback• Mitarbeit

· Was sind Ihre Erwartungen?




Erwartungen der Teilnehmer

· Gruppenübung Punktabfrage• Jeder bekommt einen Klebepunkt• Alle gehen gemeinsam nach vorne• Jeder klebt seinen Punkt in das

Koordinatensystem „Erwartungen“• Dimensionen:

– gewünschter Inhalt: theoretisch/praktisch– verfügbarer Aufwand: hoch/niedrig

· Los geht’s!




ZumeigentlichenInhalt!




Gliederung für heute

• Grundfragen– Was ist das, Software-Architektur? – Wozu sich damit beschäftigen?

• Grundbegriffe– Beispiele

– A-7E, GoLife!, SL45i

– System, Anforderung, Stakeholder– Stil– Elemente

• Semestervorschau




Ziel für heute

· Grundbegriffe und Fragen einführen

· Themenvielfalt auffächern

· Zum Nachdenken anregen




KEIN Ziel heute

· Echte Architekturbeispiele im Detail

· Antworten auf die gestellten Fragen

· Handwerkszeug des Architekten




Was ist das,„Software Architektur“?

· Der Name „Software-Architektur“ (kurz: SWA) ist als Analogie zu sehen, als eine programmatische Aussage, eine Absichtserklärung:

„da, wo die Architektur heute steht, da wollen wir auch hin“.

· Aber trägt diese Analogie wirklich?




Analogie: Gemeinsamkeiten

Architektur• große Bauwerke mit langer

Lebensdauer (Jahrhunderte)

• große Auswirkungen auf viele Beteiligte

• schwierige Koordination; komplexer, arbeitsteiliger Prozesse („Leistungsstufen“)

• Bedeutung von Planung und Modellen

Software-Architektur• große Systeme mit langer

Lebensdauer (Jahrzehnte)

• große Auswirkungen auf viele Beteiligte

• schwierige Koordination; komplexer, arbeitsteiliger Prozeß (Vorgehensmodelle)

• Bedeutung von Planung und Modellen




Analogie: Unterschiede

Architektur • Vorläufer seit 10.000 Jahren,

etablierte Disziplin seit ~1800 Ausbildungsgang/Abschluß

• Wissenskanon, Werkzeuge

• mehr oder minder künstlerischer Anteil

• wenige Freiheitsgrade, unmittelbar anschaulich

Software-Architektur • SE gerade mal seit 1968,

kein eigenes Fach, kein Ausbildungsgang/Abschluß

• kaum Theorie/ Werkzeuge

• sehr technisch-mathematisch ausgerichtet

• extrem viele Freiheitsgrade, sehr abstrakt





„Architecture is the set of design decisions [...] that keeps ist implementors and maintainers from exercising needless creativity.“

(D`Souza & Wills, Catalysis)

„ Architecture is a framework for change“

(Tom De Marco)

...ein Mittel zur Verfolgung technischer, politischer, wirtschaftlicher oder strategischer Ziele durch die Einschränkung von Freiheitsgraden bei der Herstellung





„Architecture is defined [...] as the fundamental organization of a system, emodied in its components, their relationships to each other and to the environment, and the principles governing its design and evolution.“

(IEEE AWG, Std P1471, 1999)

... Bestandteile und Struktur eines Systems auf einer bestimmten Abstraktionsebene.




Wieso SWA-“Modelle“ ?

· Ein Modell ist eine Abstraktion, die leichter zu handhaben ist, als das reale Ding.

Beispiel: ein Hochhaus und seine Modelle– Anschauung: Pappmodell, virtuelles Modell– Planung und Ausführung von x: x-Plan

mit x aus {Elektrik, Klima, Wasser, Heizung, Treppen & Aufzüge, Raumordnung, Infrastrukturanbindung, Kosten, Zeit, Logistik, Bauplanung, Statik...}

· Nur mit Modellen kann man Planen und Entwerfen.




Wieso sich mit SWA beschäftigen?

· Die „üblichen“ Gründe– Qualität– Kosten– Time-to-market– Wartbarkeit– Wiederverwendbarkeit– Investitionssicherung




Wieso sich mit SWA beschäftigen? ...Kosten

• Mangelhafte Software verursacht– betriebs- und volkswirtschaftliche Schäden im Bereich

10-100 Billionen US$ p.a. weltweit

– für deutsche Groß- & Mittelständische Unternehmen p.a. ca. 165 Mrd. DM (entspricht 1/3 des IT-Budgets)

– davon 17% Fehlerbeseitigung und 83 % Produktionsausfälle– zum Vergleich: Großfeuer verursachen jährlich in Deutschland

Schäden in Höhe von 2 Mrd. DM

– der Ariane-5-Fehler alleine hat 500 Mio Euro an Schaden verursacht (nicht versichert), Folgeschäden und Ausfälle nicht gerechnet.




Software Architektur: Geschichte des Begriffs

1960

2010

2000

1990

1980

1970

Garmisch-Konferenz•„Software Engineering“•Wiederverwendung•Komponenten

Hype

theoretische Vorarbeiten

Erste Erwähnung•SARA

?




Software Architektur:Hype und Realität

· Maßgebliche Ergebnisse in den 90`ern· Hype seit ca. 1997

· Der erste Hype ist vorbei, aber viele schwierigen Fragen sind noch offen




Gliederung:Grundbegriffe• System, Stakeholder, Anforderungen

• Arten von Architekturen– Stil, Domänenarchitektur, Produktfamilie, Architektur

• Elemente– Komponente– Port – Konnektor– Rolle/Protokoll– Konfiguration




Beispiele:Vorbemerkungen• Große Beispiele sind zu groß.

In einer Vorlesung sind sie kaum abzuhandeln.

• Echte Beispiele sind zumeist streng geheim.Eine Freigabe ist nicht zu bekommen.

• Aber kleine & Spielzeug-Beispiele sind keine!Die spezifischen Probleme und Fragen treten nicht/anders auf.

• Die Beispiele basieren auf realen Beispielen, sind aber teilweise fiktiv, verfremdet und erraten.

Das ändert aber nichts an ihrer Tauglichkeit.




Beispiele:Übersicht• A-7-Avionik System

– Waffen- und Navigations-System für ein Kampfflugzeug

• GoLife!– Online-Lebensversicherung

• SL45i– High-End Mobiltelefon

• Repräsentativer Querschnitt. Weitere Beispiele bzw. Vertiefung davon im Lauf des Semesters!




Beispiele: A-7EÜberblick

• Die A-7E Corsair II ist ein Trägergestütztes Kampfflugzeug, das in den 60er bis 80er Jahren in Betrieb war.

• Sie hatte als eines der ersten Flugzeuge einen Bordcomputer (special purpose).

• In den USA wird die Software-Engineering Forschung zu großen Teilen vom Militär finanziert.




Beispiele: A-7EWarum dieses Bsp.?

• Eines der ersten Architektur-Modelle überhaupt.

• Methodik und Architektur sind auch heute noch aktuell.

• Repräsentativ für den sehr großen und wichtigen Anwendungsbereich Embedded/RT-Systeme

– Aerospace– Automobil– Maschinensteuerung– Telekom-Switches




Beispiele: A-7ERandbedingungen

• relativ fixe Anforderungen, fixe Ressourcen

• nur ein Kunde, geringer Marktdruck

• extreme Zuverlässigkeit

• extrem lange Lebensdauer

• Echtzeitverarbeitung– dedizierte Hardware (nur Assembler)– 64k Speicher




Beispiele: A-7ESoftware / System

· Sensoren/Aktoren• Radar• Doppler-Radar• Trägheit• Staudruck• Höhenmesser• Waffenschächte/Relais

· In/Out• Head-Up-Display• Karten-Display• numerische Tastatur• alphanumerische Anzeige• Schalter• Anzeigelampen• Pieper

· Zu betrachten ist ein komplettes System, nicht nur die Software!




ZumnächstenBeispiel!




Beispiele: GoLife!Überblick

• Komplette Software-Ausstattung für eine Direkt-Versicherung (Lebensversicherungen).

• Verfremdet und zusammengetragen aus verschiedenen realen Projekten, an denen ich mitgearbeitet habe.

• Sehr ähnliche Projekte liefen bereits und laufen aktuell.




Beispiele: GoLife!Wieso dieses Bsp.?

• Ich kenne dieses Beispiel sehr gut.

• Diese Art System wird heute flächendeckend eingesetzt.

• Repräsentativ für den sehr großen und wichtigen Anwendungsbereich Office-Automation-Systeme.

– Versicherungen– Banken– ERP– Flugbuchung




Beispiele: GoLife!Anforderungen

• Organisatorisch– lange Lebensdauer– sehr viele Beteiligte

• Technisch– Legacies/Integration

– Thin-Client: Online-Betrieb!

– viele verschiedene Plattformen, Sprachen, DBs, Middlewares, ...

– Security

• Fachlich– großer Marktdruck

– Mehrere Mandanten und Gesellschaften

– Mehrere Sprachen

– Mehrere Währungen

– juristische Anforderungen

– komplexe, dynamische Geschäftsprozesse




Portal

Beispiele: GoLife!Architektur

Angebots-erstellung

Bestands-führung

In/Exkasso

Risiko-Prüfung

CRMDMS

Brief-schreibung

Call-CenterAnlage-verwaltung




Beispiele: GoLife!Architektur

Sach-bearbeiter

Kunde

Portal

Angebots-erstellung

Bestands-führung

In/Exkasso

Risiko-Prüfung

CRMDMS

Brief-schreibung

Call-CenterAnlage-verwaltung




Beispiele: GoLife!Stakeholder

• Architekt

• Kunde („Klient“)– Management, Fachabteilung, DV/IT

• Nutzer– Sachbearbeiter, Kunde, Controller

• Entwickler– Entwickler, Tester, QSB, Integrator, Domänenexperten,...

• Anbieter/Management– Projektleiter, Vorstand

• Dritte– Gesetzgeber, Datenschutzbeauftragter, Betriebsrat




ZumnächstenBeispiel!




Beispiele: SL45iÜberblick

• Sehr große Software-Architektur: „ca. 85% des Telefons sind Software“

• Momentan das high-end Produkt von Siemens

• Teil einer Produktfamilie

• Leider (bislang) sehr wenig technische Informationen verfügbar




Exkurs: Zielgruppenorientierung bei Samsung

3 Telefone: baugleich, aber verschiedene Produkte– SGH-A400

– “...in aktuellen Lippenstift-Farben...“– Ovulations-Kalender– Kalorien-Verbrauchsrechner– JPEG-Fotoalbum

– SGH-R300– Vorlesungskalender– MP3-Player– WWW-Seite mit Studienplatztausch und Jobbörse, MP3-Charts

– SGH-N300– Terminkalender, Outlook-kompatibel– Finanzrechner– MP3-Player als „Fremdsprachentrainer“




Beispiele: SL45iWieso dieses Bsp.?

• Unmittelbarer Bezug zur Lebenswelt:– nahezu jeder besitzt heute ein Mobiltelefon (wenn auch

meist eine Nummer kleiner).

• Sehr hohe kommerzielle Bedeutung, extreme Marktbedingungen.

• Repräsentativ für den sehr großen und wichtigen Anwendungsbereich der mobilen Endgeräte.

– Telefone– PDAs




• Funktionalität– Addressbuch, Notizbuch, Kalender/Terminverwaltung, Stoppuhr,

MP3-Player, Diktaphon, Mail-Client, Spiele, Währungs- und Finanzrechner, Taschenrechner, „Cocktailratgeber“

• Protokolle / Dienste– SMS, EMS, GSM, SPRS, WAP, Fax, POP3– Komfortdienste (Rufweiterleitung, Anruferanzeige,

Anklopfen, ...)

• Bedienbarkeit– Display- & Tastengröße, Menü- vs. Sprachsteuerung , Hilfe

• Abmaße / Gewicht, Standby- / Sprechzeit • Time to market

Beispiele: Siemens SL45iAnforderungen




Beispiele: Siemens SL45i

Anforderungskonflikte Bedien-

barkeit

Preis Standby- &

Sprechzeit

Gewicht &

Abmaße

Funktion-

alität

Funktion-

alität

Gewicht &

Abmaße

Standby- &

Sprechzeit

Preis

Bedien-

barkeit

Eingebaute JVM

Funktionalität dynamisch ladbar, für jeden Benutzer individuell




AuswertungderBeispiele




Beispiele: Wofür stehen sie?• A-7E

– System = Hardware + Software

• GoLife– Stakeholder– Konflikt zwischen ihnen

• SL45i– Anforderungen im Konflikt– Produktfamilien




Beispiele: Vergleich 1Nachbarsysteme

GoLife SL45i A7-E

in GUI Empfänger div. SensorenScanner Tastatur RadarCall-Center Mikrophon Schalter

out GUI LCD div. Aktoren Briefdruckstraße Sender Head-Up-Display

LautsprecherVibrationsalarm

mem verschiedene DBs „Multimedia Card“ 64k intern

peer Anlageverwaltung Funknetz & Dienste -




Beispiele: Vergleich 2Anforderungsprofile

FU

RP

SIS

O 9

126

GoLife! SL45 A-7E

Functionality ++ + +Usability + ++ -Reliability - + ++Performance +- +- ++Security + - ++Efficiency + +- +Maintainability + - ++Reusability + ++ --Time-to-market + ++ --Portability + - --Availability + - ++System Development + ++ ++




Beispiele: Vergleich 2Anforderungsprofile

Go!Life SL45A7E

Functionality ++ + +Efficiency + +- +Usability + ++ -Performance +- +- ++Reusability + ++ --Time-to-market + ++ --Reliability - + ++System Development -- ++ ++Portability + - --Security + - ++Maintainability + - ++Availability + - ++




Beispiele: Vergleich 3Stakeholder

Rolle GoLife SL45i A7-E

Nutzer Kunde Telefonierer PilotSachbearbeiter

Klient Versicherung Telefonierer US Navy

Anbieter FJA Siemens Naval SW Dev. ...

Entwickler Entwickler Entwickler Entwickler

Architekt Architekt Architekt Architekt

Dritte Datenschützer Mobilfunk- Ziel/GegnerBetriebsrat hysterikerGesetzgeber




Beispiele: Verleich 3 Stakeholder/Stakes

Kunde Anbieter Nutzer EntwicklerFunctionality ++ -- ++ ++Efficiency ++ + -- ++Usability - - ++ +Performance ++ - ++ +Reusability -- ++ -- ++Time-to-market ++ - -- +Reliability + - ++ +System Development ++ -- -- ++Portability - ++ -- ++Security ++ + -- ++Maintainability - - -- ++Availability ++ -- - -




Beispiele: Verleich 3 Stakeholder/Stakes

Kunde Anbieter Nutzer EntwicklerFunctionality ++ -- ++ ++Efficiency ++ + -- ++Usability - - ++ -Performance ++ - ++ +Reusability -- ++ -- ++Time-to-market ++ - -- +Reliability + - ++ +System Development ++ -- -- ++Portability ++ -- -- ++Security ++ + -- ++Maintainability - - -- ++Availability ++ -- - -




Beispiele: Vergleich 3Stakeholder/Stakes

Entwickler

Anbieter(Manager)

Nutzer

Klient

Architekt

moderiert &vermittelt

<- befragt informiert->

beauftragt-><- liefert

beauftra

gt->

<- b

erich

tet

kontro

lliert->




Stakeholder „Architekt“:Rolle• Der Architekt ist die Schnittstelle zwischen

– Kunde und Auftraggeber, und – Nutzer und Entwickler.

• Er moderiert und steuert die Interaktionen zwischen den Beteiligten.

• Letztlich ist daher der Architekt für die Befriedigung der Kundenwünsche verantwortlich.

• Und nicht nur für die Realisierung der Anforderungen!




Stakeholder „Architekt“:Anforderungen

• Ein Architekt braucht– umfassende Akzeptanz durch umfassende Kompetenz– hohes Maß an Moderations-&

Kommunikationsfähigkeit.

• Architekt kann nur empfehlen, nicht befehlen, daher relativ geringe Einwirkungsmöglichkeit. Gleichzeitig trägt er eine hohe Verantwortung:

• Riskant, aber reizvoll.




Architektur ... Stil:Nutzen von

Einschränkungenkeine

Ein-schränk-

ungen

viele

wenige... viele Exemplare

Stil {Form, Elements, Rationale}

Domänen-/Branchen-SWA

Produkt-familieSystem

z.B. FAA, VAA, IAA

z.B. SL45, SL45i, SE45, M45i, S35, C35





Einschränkungen· Stärkere Festlegung erlaubt:

• mehr methodische und Werkzeug Unterstützung (z.B. Programmiermodelle, Generatoren)

• leichtere Überprüfung/Begutachtung• stärkere Wiederverwendung

· und damit:• bessere Qualität• reduzierte Kosten• kürzere Produktzyklen (time-to-market)





EinschränkungenGesamtkosten

Lebensdauer, bzw. Anzahl Produktzyklen

SystemarchitekturProduktfamiliemit Stilkeine Architektur

Over-head




Architektur-Stil (Beispiele)

• Datenfluß– Stapelverarbeitung mit Datei-Puffer (Batch)– Unix-Pipes („Pipes-and-Filters“)

• Kontrollfluß– Prozedur-Aufruf, RPC, RMI, ...

• kooperierende Prozesse– Betriebssysteme

• shared memory– Blackboard– TP-Monitore/RDBMS

• Schichten– C/S-Systeme– Betriebssysteme




Grundbegriffe: Elemente 1/2

· Komponenten – Nicht im Sinne von COM, EJB, o.ä., sondern als

Architektur-Einheiten, also als Gegenstand von Entwurf, Wiederverwendung, Auftragsvergabe, Versionskontrolle, ...

· Port– Schnittstelle einer Komponente, evtl. Vertragsgrundlage

· Rolle– beschreibt Signatur und Verhalten

· Protokoll– Kollaboration von Rollen




Grundbegriffe: Elemente 2/2

· Konnektor– Verbindet Komponenten über ihre Ports– kann eigenes Verhalten haben– erfüllt Protokoll

· Konfiguration– Anordnung von Komponenten und Konnektoren

· StilStyle={Form, Elements, Rationale}

· Instanzen / Typen




Gliederung für heute

• Grundfragen– Was ist das, Software-Architektur? – Wozu sich damit beschäftigen?

• Grundbegriffe– Beispiele

– A-7E, GoLife!, SL45i

– System, Anforderung, Stakeholder– Stil– Elemente

• Semestervorschau




Einleitung– Architektur-Einheiten („Komponenten“)– Semantik-Formalismen (CSP, PN, ES, LTS)– Entwurfs-Notationen (UML, SARA)– Wright– Darwin– UML/AM (SARA, ROOM, UML/RT, SDL,...)– Elementare Methodiken– Konsistenz, Verifikation– Validation, Soft-FactorsRückschau

SemestervorschauÜberblick

Prozesse

ADLs

Grundlagen3

7

2Skip 8




SemestervorschauGrundlagen: Einheiten• Anforderungen:

– effektive & ökonomische Wiederverwendung– fachliche und technische Einheiten– Modellierungs- und Implementierungs-Komponenten– Einheiten als Gegenstände der Vertragsgestaltung

• Existierende Technologien– Business Objects– Corba Component Model / EJB (u.ä.)– UML Components

• Wie geht beides zusammen?




SemestervorschauGrundlagen: Semantik• Motivation: Konsistenz-Überprüfung

• Formalismen– CSP, Transitionssysteme, Traces– Petri-Netze, Event-Structures

• Äquivalenzen

• Vergleich der Formalismen:Wann ist welcher geeignet?




SemestervorschauGrundlagen: Notationen• Sollte ja eigentlich bekannt sein, aber...

• Gängige Notationen– UML– SARA, ROOM, UML/RT– UML/AM– Use Case Maps

• Syntax, Semantik, Pragmatik in Grundzügen




SemestervorschauADLs• Wright

– benannt nach Frank Lloyd Wright– erste wirklich formale ADL (CSP-Semantik)

• Darwin– Schwerpunkt dynamische Struktur (Evolution)– Pi-Kalkül-Semantik– SAA (Sw. Architect`s Assitant)

• UML/AM – eher aus der Praxis kommend– basiert auf meiner Diss– verschiedene Semantiken (z.B. PN, make, Java)




SemestervorschauProzeß: Einführung• Der Geschäftsprozeß der SW-Herstellung

• Der entscheidende Hebel zur Qualitätsverbesserung

• Methodik / Techniken– Von Geschäftsprozessen zu Anwendungsfällen– interaktiver GUI-Entwurf (Dialogsteuerung)– CRC-Karten




SemestervorschauProzeß: Analyse &

Validation· Modelle dienen zum Planen:

• Ist das Modell in sich stimmig?• Ist dies das richtige Modell?

· Themen• Ansatzpunkte• Auswahl von Äquivalenzen• informelle Analysetechniken: Begehung/Review




Semestervorschau: Ausblick

· Thematische Rückschau

· Reflektion• Was haben Sie während des Semesters

gelernt?

• Welche offenen Fragen gibt es?

• Wie könnte man sie vielleicht lösen?




Einleitung– Architektur-Einheiten („Komponenten“)– Semantik-Formalismen (CSP, PN, ES, LTS)– Entwurfs-Notationen (UML, SARA)– Wright– Darwin– UML/AM (SARA, ROOM, UML/RT, SDL,...)– Elementare Methodiken– Konsistenz, Verifikation– Validation, Soft-FactorsRückschau

SemestervorschauÜberblick

Prozesse

ADLs

Grundlagen3

7

2




Literatur (fürs ganze Semester)

· H. Störrle (2001)• Models of Software Architecture

· L. Bass/P. Clements/R. Kazman (1998)• Software Architecture in Practice

· OMGUnified Modeling Language




Literatur (zur Nachbereitung)

· D. Garlan• Software Architecture: A Roadmap

(Keynote Speech auf der ICSE 2000)

· P. Clements/L. Northrop• Software Architecture: An Executive Overview

(pp. 55-68 in: A.W. Brown Component Based SE )

· WWISA-Charta




Literatur (zur Vorbereitung)

· Technische Komponentenmodelle– EJB 2.0– 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)

· Google o.ä.: „Business Objects“




Aufgabe zum nächsten 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!




Schlußbemerkungen

· Fragen & Anregungen:[email protected]

· Weitere Informationen:www.pst.informatik.uni-muenchen.de/

lehre/WS0102/architektur/

· Nicht vergessen: VL am 23.10. entfällt!

1111 16.10.2001 Einführung VL Software Architektur-Modelle Dr. Harald Störrle Vorbereitung...

Documents

Transcript of 1111 16.10.2001 Einführung VL Software Architektur-Modelle Dr. Harald Störrle Vorbereitung...