Design: Referenzarchitektur betriebliche

Transcrição

6. Design-Phase:
Referenzarchitektur
betriebliche
Informationssysteme
Softwaretechnik
(CNAM)
Wintersemester 2011 / 2012
Prof. Dr. Bernhard Humm
Hochschule Darmstadt, FB Informatik
1
Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012
Einordnung in den gesamten Kurs
1. Einführung
2. Analyse: Anforderungen und Anwendungsfälle
3. Analyse: Datenmodell
4. Analyse: Dialoge
5. Design: Architektur-Grundlagen
6. Design: Referenzarchitektur betriebliche Informationssysteme
7. Design: Querschnittsthemen und Muster
8. Programmierung
9. Test, Einführung, Qualitätsmanagement
10. Projektmanagement
11. Vorgehensmodelle
2
Agenda

Motivation
Motivation
Referenzarchitektur
Anwendungskern
Persistenz und Transaktion
Authentifizierung und Autorisierung
Client-Architektur
Literatur und Kontrollfragen
Beispiel für den Nutzen von Referenzarchitekturen:
Migration einer Portalplattform
Services der Laufzeit
… weitere ...
Portal
Laufzeit
Management
EntwicklungszeitServices
Benutzerschnittstelle
Entwicklung
Querschnittliche Portaldienste
ATG Portal
… weitere ...
Portal
Portal
(ATG Portal)
Inhaltspflege
Content
Management
Personalisierung
(ATG Portal)
Oracle
Inhaltssteuerung
Documentum
(CMS)
Personalisierung
Transformation
Komposition
CMS
(Documentum (1))
Kommunikation und Sicherheit
Dokumentenmanagement
Oracle
Documentum (2)
… weitere ...
Portalnahe AL-Komponenten
Backend AL-Komponenten
Dokumenten-management
Ist-Plattform
4
… weitere ...
Soll-Plattform
Agenda
Motivation

Referenzarchitektur
Referenzarchitektur
Anwendungskern
Client-Architektur
Schichtenarchitektur für betriebliche Informationssysteme: Quasar (Qualitäts-Software-Architektur)
cd Quasar Architecture
«Abstract T Component»
«A Component»
Client Management
Dialog
 Trennung von A- und
T-Software auf der
Komponenten-ebene
Präsentation
 Identifikation der
wesentlichen
technischen
Komponenten
Application Kernel
Facade
Alternatives
Anwendungslogik
Datenzugriff
6
Application
Component
Authorization
 Festlegung der
Abhängigkeiten
Alternatives
6
«A Component»
Transaction
Persistence
Quelle: Capgemini sd&m Research
Agenda
Motivation
Referenzarchitektur

Anwendungskern
Anwendungskern
Client-Architektur
Referenzarchitektur für betriebliche Informationssysteme
Quasar (Qualitäts-Software-Architektur)
«A Component»
Client Management
Dialog
Präsentation
Anwendungslogik
Application Kernel
Facade
Alternatives
«A Component»
Application
Component
Authorization
Datenzugriff
Alternatives
Transaction
8
Persistence
Referenzarchitektur Anwendungskern
Client
Anwendungskern
A-Fall 1.1
A-Fall 1.2
A-Fall 1.3
A-Komponente 1
A-Komponente
A-Fall
A-Fall 2.1
A-Fall 2.2
A-Fall 3.1
A-Fall 3.2
A-Fall 3.3
A-Fall 2.3
A-Verwalter
+
A-Entitätstypen
A-Komponente 2
9
A-Verwalter
+
A-Entitätstypen
AEntitätsverwalter
A-Entität
A-Verwalter
+
A-Entitätstypen
A-Datentyp
A-Verwalter
+
A-Entitätstypen
A-Komponente 3
edassaF-K WA
-sgnudnewnA
nrek
3.1 llaF-A
2.1 llaF-A
1.1 llaF-A
1 etnenopmoK-A
3.3 llaF-A
2.3 llaF-A
1.3 llaF-A
2.2 llaF-A
1.2 llaF-A
3.2 llaF-A
A-Entitäten
Idee
retlawreV-A
+
nepytstätitnE-A
Außensicht
Innensicht
• Stellen Objekte der
realen Welt dar, z. B.
Konto, Kunde, Auftrag
• Lesender /
schreibender Zugriff auf
Attribute
• Attribute, typisiert als ADatentypen
• Entsprechen dem
Datenmodell:
wesentliche Objekte
des Informationssystems
• Einfache
Geschäftslogik, z.B.
Konsistenzprüfung,
Statusverwaltung,
Externalisierung
• Implementierung von
Konsistenzprüfung,
Statusverwaltung,
Externalisierung etc.
• Sind autonom; haben
einen Schlüssel (Id)
10
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
3 etnenopmoK-A
• Sind persistent
10
retlawreV-A
+
nepytstätitnE-A
• Unterscheidung
zwischen Typen
(Klassen) und Objekten
(Instanzen)
2 etnenopmoK-A
Beispiel für A-Entitätstyp: Invoice
A-Entitätsklasse
public class Invoice {
private int id;
private Account account;
private int amount;
private Date invoiceDate;
private Date dueDate;
private InvoiceStatus status;
private String subject;
Invoice() {}
Attribute
Konstruktoren
Einfache Geschäftslogik, z.B.
Statusverwaltung
public boolean isOverdue() {...}
...
}
11
11
Implementierung von Assoziationen (1/3)
Customer
1
*
Order
Alternativen:
1.
Customer kennt nichts von Orders und umgekehrt (zumindest nicht über direkte
Referenz). Order enthält eindeutige CustomerId. Der Nutzer interpretiert die CustomerID
2.
Order referenziert einen Customer
3.
Customer referenziert eine Collection von Orders
4.
(2) und (3): Bidirektionale Referenzen
12
12
 Alternative #1:
class Customer {
String customerID;
class Order {
…
private String customerId;
// not aware of orders
public String getCustomerId(){
return customerId;
}
…
}
}
 Nutzer greift auf die CustomerId mittels get-Methode zu
 Anschließend kann er über einen Verwalter mittels der Id auf das Customer Objekt
zugreifen
13
13
 Stellt fachlichen Fremdschlüssel dar
 Alternative #4:
class Customer {

private List<Order> orders;
…
public List getOrders() {

return orders.clone();
}
}
class Order {
private Customer customer;
…
public Customer getCustomer() {
return customer;
}
}
 Alternativen #2 - #4 koppeln eng
 10 eng gekoppelte Klassen sind in Ordnung – 100 eng gekoppelte Klassen sind eine
Katastrophe!
 Keine enge Kopplung zwischen Komponenten
14
14
edassaF-K WA
-sgnudnewnA
nrek
3.1 llaF-A
2.1 llaF-A
1.1 llaF-A
1 etnenopmoK-A
3.3 llaF-A
2.3 llaF-A
1.3 llaF-A
2.2 llaF-A
1.2 llaF-A
3.2 llaF-A
A-Datentypen
Idee
retlawreV-A
+
nepytstätitnE-A
Außensicht
• A-Datentypen:
Instanziierung und
Zugriff auf Wert (meist
immutable)
• Spezifiziert durch
Wertebereich incl.
Validitätsprüfung
• T-Datentypen durch
Programmiersprache
bereitgestellt, z.B.
Integer
Innensicht
 Typen:
• Skalar, z.B. ISBN 
Klasse mit
Prüfmethoden
• Zusammengesetzt, z.B.
Adresse  Klasse mit
Attributen
• Aufzählung, z.B.
CustomerType  enum
• Beispiele: Date,
Address, Money
15
15
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
3 etnenopmoK-A
• Kleinste
Informationseinheiten
des Informationssystems
• Nur Werte; kein
Schlüssel (Id)
retlawreV-A
+
nepytstätitnE-A
2 etnenopmoK-A
Beispiel A-Datentyp: InvoiceStatus
public enum InvoiceStatus {
OPEN, CLOSED
}
16
16
edassaF-K WA
-sgnudnewnA
nrek
3.1 llaF-A
2.1 llaF-A
1.1 llaF-A
1 etnenopmoK-A
3.3 llaF-A
2.3 llaF-A
1.3 llaF-A
2.2 llaF-A
1.2 llaF-A
3.2 llaF-A
A-Entitätsverwalter
Idee
• Entitätsübergreifende
Zugriffs-Logik für einen
oder mehrere
zusammengehörige
A-Entitätstypen
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
3 etnenopmoK-A
Außensicht
Innensicht
• Create…()
• Meist zustandslos
• Find…By…()
• Verbindet mit der
Datenbank
• delete…()
• Implementiert Queries
• Implementieren
Lebenszyklus: anlegen,
suchen, ändern,
löschen (CRUD)
• Beispiele:
CustomerManager,
OrderManager
17
17
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
2 etnenopmoK-A
Beispiel A-Entitätsverwalter: CustomerManager
Entitätsverwalter-Klasse
public class CustomerManager {
Anlegen
public Customer newCustomer() {...}
public Customer newCustomer(String name, String address) {...}
public Customer findCustomerById(int id) {...}
public Collection<Customer> findCustomerByName(String name) {...}
public Collection<Customer> findCustomerByAddress(String address) {...}
}
18
18
Suchen
edassaF-K WA
-sgnudnewnA
nrek
3.1 llaF-A
2.1 llaF-A
1.1 llaF-A
1 etnenopmoK-A
3.3 llaF-A
2.3 llaF-A
1.3 llaF-A
2.2 llaF-A
1.2 llaF-A
3.2 llaF-A
A-Service und Transfer-Objekte
Idee
• Exportierte
KomponentenSchnittstellen und ihre
Implementierung
• Stellen Geschäftsfunktionalität bereit
• Orientieriert an den
Anwendungsfällen der
Spezifikation
• Beispiel: sendInvoice
Außensicht
• Lose gekoppelt:
• Parameter und
Rückgabe
ausschließlich
Datentypen oder
Transfer-Objekte –
i.d.R. keine Referenzen
auf Entitäten
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
3 etnenopmoK-A
Innensicht
• Erhält A-Entitäten und
von den AEntitätsverwaltern
• Arbeitet auf A-Entitäten
und transformiert in
Transfer-Objekte
• Transfer-Objekte sind
Kopien der Werte von
Entitäten
19
19
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
2 etnenopmoK-A
Beispiel A-Service Interface:
Accounting
A-Service Interface
public interface Accounting {
public InvoiceRecord sendInvoice(
int accountId,
String subject,
int amount);
}
Geschäftsmethoden
20
20
Beispiel Transfer-Objekt:
InvoiceRecord
Transfer-Objekt Klasse
public class InvoiceRecord {
Keine Referenzen auf Entities
private int id;
private int accountId;
private int amount;
private Date invoiceDate;
A- und T-Datentypen
private Date dueDate;
private String invoiceStatus;
private String subject;
}
21
21
edassaF-K WA
-sgnudnewnA
nrek
3.1 llaF-A
2.1 llaF-A
1.1 llaF-A
1 etnenopmoK-A
3.3 llaF-A
2.3 llaF-A
1.3 llaF-A
2.2 llaF-A
1.2 llaF-A
3.2 llaF-A
A-Komponenten
Idee
• Wesentliche Einheit des
Entwurfs, der Planung
und der
Implementierung
• Bündeln fachlich
zusammengehörende
Geschäftslogik
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
3 etnenopmoK-A
Außensicht
• Schnittstellen der AServices
• Factories zum
Erzeugen der
Komponenten
Innensicht
• In Java meist
implementiert als
Packages
• Implementierung der AServices,
A-Entitätsverwalter, AEntitäten und
A-Datentypen
22
22
retlawreV-A
+
nepytstätitnE-A
retlawreV-A
+
nepytstätitnE-A
2 etnenopmoK-A
Beispiel: Online-Shop
Sales
Stock
CustomerManagement
Accounting
ProductManagement
23
23
dependency
Beispiel Package-Struktur
Anwendung
Komponente
A-Entitäten
A-Datentypen
com.xyz.shop.accounting.entity
com.xyz.shop.accounting.type
com.xyz.shop.accounting.manager
com.xyz.shop.accounting.manager.impl
com.xyz.shop.accounting.service
com.xyz.shop.accounting.service.impl
Schnittstellen AEntitätsverwalter
Implementierung AEntitätsverwalter
Schnittstellen
A-Services
Implementierung
A-Services
24
24
Beispiel:
Komponenten der A-Architektur einer Bibliothek
Ausleihe
Bestandsführung
Kundenverwaltung
Gebühren
Titelkatalog
kennt
25
«A Component»
Client Management
Dialog
Application Kernel
Facade
Alternatives
«A Component»
Application
Component
Authorization
Alternatives
Transaction
26
Persistence
Anwendungskern-Fassade im Detail
cmp Application Kernel Facade
Mehrwert-Dienste:
«A Component»
Dialog
NameService
 Entfernter Zugriff
 SitzungsVerwaltung
(Parallelität)
A_UseCase_1' A_UseCase_n'
Administration
 Transaktionen
Application Kernel Facade
TechnicalConfiguration
SystemsManagement
 Autorisierung
 Fehlerbehandlung
ExceptionHandler
 …
A_UseCase_1
A_UseCase_n
TransactionManager
«Abstract T Compo...
Transaction
27
«A Component»
Application Component
Anwendungskern-Fassade
Idee
 hält den AWK frei von
Technik
Außensicht
exportiert
 steuert die
Transaktionen (ASteuerung)
 Schnittstellen für
Dialoge und
Nachbarsysteme (z. B.
mit RMI, Web-Services)
möglicherweise:
importiert
 authentifiziert die
Aufrufer
 rein fachliche
Schnittstellen
 autorisiert die Zugriffe
 operative
Berechtigungs-Sst:
„darf der das?“
 komponiert den
Anwendungskern
 Schnittstelle zur
Steuerung einer
T-Transaktion
28
Innensicht
 transformiert zwischen
Schnittstellen „nach
oben“ und
Schnittstellen „nach
unten“
 viel R-Code
 möglichst wenig
A-Code durch
Delegation an den AWK
 prüft Berechtigungen
 öffnet und schließt
Transaktionen
Beispiel: Aufruf eines A-Falls mit Transaktion
sd inv oke use case w ith transaction
Client
Transaction
Application
«interface»
«interface»
«interface»
«interface»
NameService
A_UseCase_1'
TransactionManager
A_UseCase_1
Client
findUseCase(useCaseName) :UseCase
someMethod(arguments)
beginTransaction() :Transaction
someMethod(arguments)
commitTransaction(transaction)
29
Agenda
Motivation
Referenzarchitektur
Anwendungskern

Persistenz
Transaktion
Persistenz
undund
Transaktion
Client-Architektur
«A Component»
Client Management
Dialog
Präsentation
Application Kernel
Facade
Alternatives
Anwendungslogik
Datenzugriff
Application
Component
Authorization
Alternatives
Transaction
31
«A Component»
Persistence
Persistenz und Transaktion im Detail
class Persistence, Transaction
«A Component»
Application
Component
TransactionalPool
TransactionManager
QueryAdministration
Transaction
Persistence
ModelAdministration
TransactionResource
SystemsManagement
SystemsManagement
32
Persistenzmanagement
Idee
Außensicht
Innensicht
 persistiert Objekte
exportiert
 sehr kompliziert
 versteckt die relationale
Welt (und SQL) vor
dem AWK
 TransaktionsRessource (meist XAfähig)
 daher nur selber bauen,
wenn kein Produkt
verfügbar
 versteckt die DBZugriffstechnik (z. B.
JDBC) vor dem AWK
 O/R-Mapper
 stellt die ObjektIdentität sicher
importiert
 DB-Zugriff (z. B. JDBC)
 Optimierungen
- Caching
- Connection-Pool
33
Abbildung von Klassen auf Tabellen
 Klasse  Tabelle
 Objekt  Zeile
 Attribut  Spalte
 Datentypen der Programmiersprache  DB-Datentypen
Klasse Customer
Attribute:
name: String
firstName: String
address: String
...
Tabelle CUSTOMER
NAME
FIRSTNAME ADDRESS
Methoden:
getName()
setName()
...
34
Abbildung von 1:n Beziehungen:
Assoziation  Fremdschlüssel-Beziehung
Bestellung
*
bestellDatum
gesamtPreis
BestellPosition
menge
Bestellung
OID bestellDatum gesamtPreis
Pizza
name
preis
BestellPosition
OID bestellungOID pizzaOID menge
Fremdschlüssel
35
Abbildung von Vererbung:
3 Varianten
1. Typisierte Partitionierung
Person
OID
name
gehalt
startDatum
umsatz
objTyp
2. Horizontale Partitionierung
Person
Kunde
{abstract}
OID
name
umsatz
name
Angestellter
OID
Angestellter
gehalt
startDatum
name
gehalt
startDatum
Kunde
umsatz
3. Vertikale Partitionierung
Person
OID
name
objTyp
Kunde
OID (FS)
36
umsatz
Angestellter
OID (FS)
gehalt
startDatum
Transaktionsmanagement
Idee
 ermöglicht
Transaktionen über
mehrere Ressourcen
Außensicht
Innensicht
exportiert
 sehr kompliziert
 Schnittstelle zur
Steuerung einer TTransaktion (begin,
commit, rollback)
 daher nur selber bauen,
wenn kein Produkt
verfügbar
importiert
 beliebig viele
TransaktionsRessourcen (meist XAfähig: begin, prepare,
commit, rollback)
 XA-fähiges
Transaktionsmanagement nie selber
bauen!
 beliebig viele
Transaktionsbeteiligte
(beforeCompletion,
afterCompletion)
37
Transaktionen: Alles oder Nichts
Commit
Transaktion
Transaktion
Crash
Rollback
38
Transaktionen: ACID
Beispiel: Konzertkartenverkauf:
1) Karte für Sitzplatz im Konzert drucken
2) Betrag vom Konto abbuchen
Atomarität: Entweder werden die Karte gedruckt und der Betrag abgebucht oder
nichts von beidem (Alle Änderungen = Einheit)
Consistenz: Der Datenbestand ist vor und nach dem Verkauf konsistent (z.B.
Sitzplatz belegt, Geld abgebucht)
Isolation: Zwei parallel arbeitende Ticketverkäufer beeinflussen sich nicht während
des Verkaufs – die Daten sind isoliert
Dauerhaftigkeit: Am Ende der Transaktion sind die vorgenommenen Änderungen
gespeichert (sie überleben einen Systemabsturz)
39
Fachliche und technische Transaktionen
Fachliche Transaktion

Fachlicher Ablauf mit mehreren zusammengefassten Aktionen, der z.B. mit OK bestätigt und mit ABBRECHEN verworfen
wird

Kurz (Sekunden) oder sehr lang (Minuten, Stunden, Tage)

Beispiel: Konzertkartenverkauf
Technische Transaktion

Transaktion auf der Datenbank

Meist sehr kurz (je nach Zugriffsstrategie)

Lesen oder alle Änderungen schreiben
Start: Karte Verkaufen
OK
Fachliche Transaktion
Technische Transaktionen
40
Abbildung fachlich  technisch
Pessimistische Transaktionsstrategie
 Anwendung lädt Datensatz aus DB
Kunde 4711
 Datensatz ist gesperrt
Client 1
Client 2
 Andere Clients blockieren, wenn sie
lesen/schreiben wollen
 Konflikte können nicht auftreten
 Deadlocks sind möglich
KundenTabelle
ID
Nachname Vorn.
4711 Mustermann Marta
41
Abbildung fachlich  technisch
Optimistische Transaktionsstrategie
Kunde 4711
2
Kunde 4711
1
Client 1
Client 2
 Jedes Geschäftsobjekt bekommt
einen Versionszähler oder
Zeitstempel
 Datensatz ist nicht gesperrt
 Andere Clients können lesen und
schreiben
Konflikt
 Konflikte werden über
Versionsvergleich erkannt
KundenTabelle
ID
Nachname Vorn. Vers.
4711 Mustermann Marta
42
2
Beispiel: Einfügen einer Entität mit Transaktion
sd insert
Application
Transaction
Persistence
«interface»
«interface»
«interface»
TransactionManager
TransactionalPool
:TransactionResource
Application
beginTransaction() :Transaction
new
«interface»
A_Entity
insert(object) :UID
43
Agenda
Motivation
Referenzarchitektur
Anwendungskern

Authentifizierung
und Autorisierung
Authentifizierung
und Autorisierung
Client-Architektur
«A Component»
Client Management
Dialog
Präsentation
Anwendungslogik
Datenzugriff
Alternatives
«A Component»
Application
Component
Authorization
Alternatives
Transaction
45
Application Kernel
Facade
Persistence
Worum geht es?
 Hallo! Kennen wir uns?
Authentication
 Was möchtest Du tun?
Darfst Du das überhaupt?
Authorization
46
Aufgaben der Authentifizierung und Autorisierung
 Verwaltung von …
– Benutzerdaten:
– “Gerd Müller arbeitet in der Buchhaltung.”
User Administration
– Berechtigungsdaten:
– “Buchhalter dürfen Kontendaten lesen.”
Authorization Administration
 Nutzen der …
– Authentifizierung:
– “Ist das wirklich Gerd Müller, der gerade
versucht sich anzumelden?”
Authentication
– Autorisierung:
– „Darf Gerd Müller Sepp Mayers Kontendaten
lesen?”
47
Authorization
Authentifizierung und Autorisierung im Detail
cmp Authorization
ResourceDefinition
«A Component»
Application
Component
Authorization
UserAdministration
Authentication
AuthorizationAdministration
Authorization
SystemsManagement
48
Beispiel: Authentifizierung und Autorisierung
sd authenticate and authorize
Application
Authorization
«interface»
«interface»
«interface»
ResourceDefinition
Authentication
Authorization
Application
User:= authenticate(username,password)
boolean:= mayPerform(resource,operation,user)
String:= getResourceName(resource)
49
Agenda
Motivation
Referenzarchitektur
Anwendungskern

Client-Architektur
Client-Architektur
«A Component»
Client Management
Dialog
Präsentation
Anwendungslogik
Datenzugriff
Alternatives
«A Component»
Application
Component
Authorization
Alternatives
Transaction
51
Application Kernel
Facade
Persistence
Client: alle Arten von Benutzerschnittstellen
 Graphische
Benutzerschnittstellen (GUI)
und textuelle
Benutzerschnittstellen (TUI)
 Web-basiert (Internet-Portal)
und nativ (z.B. Java Swing)
 Verteilt (Client / Server) und
lokal (Fat Client)
52
Statische Aspekte eines Client
Window
Menu
Edit field
Subdialog
Label
Text field
Button
Panel
Scroll bar
53
Dynamische Aspekte eines Client
Dialogsteuerung,
Workflow
Datendarstellung
Internationalisierung
Validierung von
Nutzereingaben
Aktionen
ausführen
Zustandsverwaltung
54
Client Technologien
Clients
Hohe
Komplexität
mit hoher Komplexität
Clients mit geringer
Niedrige Komplexität
WebDynPro-Client
.NET client
ActiveX
Web client (ohne Scripting)
RCP client
Flash client
Web 2.0 client
Win32 client
Java Swing client
55
Java Applet
Terminal client
Dialog
 Ein Dialog ist eine aus Nutzersicht sinnvolle Einheit von UI-Elementen und ihrer
Funktionalität
 Ein Dialog unterstützt einen oder mehrere Anwendungsfälle
 Ein Dialog kann Unterdialoge haben
Zwei Fenster, ein Dialog
Ein Fenster, mehrere
Dialoge
56
cmp Client
«TI Component»
GUI Library
«A Component»
Dialog
«A Component»
DialogFrame
«A Component»
Presentation
Administration
Referenzarchitektur
Client im Detail
Presentation
DialogManager
EventManager
Dialog
DataManager
«A Component»
DialogKernel
SystemsManagement
DialogKernel
NameService
A_UseCase_1' A_UseCase_n'
57
Beispiel: Ausführung eines A-Falls
sd perform application use case
User
GUI Library
«interface»
Presentation
ActionListener
VisualRepresentation
Dialog Kernel
«interface»
«interface»
«interface»
«interface»
Presentation
Ev entManager
DataManager
A_UseCase_1'
User
press button
fireActionEvent()
trigger(event)
some A use case method
UID := Pool.insert(value)
update()
Object := fetch(key)
update()
58
Agenda
Motivation
Referenzarchitektur
Anwendungskern
Client-Architektur

Literatur
Kontrollfragen
Literatur
undund
Kontrollfragen
Literatur
 Johannes Siedersleben: Moderne Softwarearchitektur.
dpunkt-Verlag 2004
 Johannes Siederlseben et. al: Quasar: Die sd&m
Standardarchitektur (Download von meiner Home Page)
 Martin Haft, Bernhard Humm, Johannes Siedersleben:
The Architect’s Dilemma – Will Reference Architectures
Help? (Download von meiner Home Page)
 Martin Haft, Bernd Olleck: Komponentenbasierte ClientArchitektur. Informatik Spektrum 30-3-2007, S. 143-158,
Springer-Verlag 2007 (Download von SpringerOnline –
kostenfrei vom h_da Campus aus)
60
Kontrollfragen
 Was sind Referenzarchitekturen? Wozu dienen sie?
 Skizzieren Sie die wesentlichen Elemente der Referenzarchitektur für betriebliche
Informationssysteme
 Wie sollte der Anwendungskern aufgebaut sein?
 Wozu ist die Anwendungskern-Fassade gut?
 Wozu dient die Persistenz? Wie wird sie verwendet? Wie werden Klassen auf Tabellen
abgebildet?
 Wozu dienen Transaktionen? Wie werden sie verwendet? Welche Arten von Transaktionen
existieren? Welche Transaktionsstrategien existieren?
 Wozu dient Authentifizierung und Autorisierung? Wie wird sie verwendet?
 Was sind Clients? Wie sollten sie aufgebaut sein?
61

Design: Referenzarchitektur betriebliche

Transcrição

Documentos relacionados

Ad-hoc-Betreuung an der Waldspirale in Darmstadt

3 66 88 99 Centralstation/Im Carree/Darmstadt

Eisenbahnmuseum Darmstadt Kranichstein Vernissage am

IT-Architektur im Großen

dem Hessischen Landesamt für Umwelt und Geologie

Antrag für Einzelpersonen - Verein der Karlsruher Software

Kinobesuch in Darmstadt

5 Jahre TKD DA2 - Traditional Taekwon

L iebfrauen - Pfarrei Liebfrauen Darmstadt