V Mods 01

Vorlesung
Modulare und On-Demand-Systeme
PD Dr. Sebastian Schlauderer
Lehrstuhl für Wirtschaftsinformatik,

insb. Industrielle Informationssysteme
Otto-Friedrich-Universität Bamberg
sebastian.schlauderer@uni-bamberg.de
Vorlesung Modulare und On-Demand Systeme | WiSe 23/24 | PD Dr. Sebastian Schlauderer 1
Organisatorisches
Veranstaltungsübersicht
Vorlesung
Datum Zeit Raum Thema
18.10.2023 Mi 08:15-09:45 WE5/04.004 Motivation und Einführung
25.10.2023 Mi 08:15-09:45 WE5/04.004 Komponentenorientierte Systeme
26.10.2023 Do 10:15-11:45 WE5/04.014 Entwicklungsparadigmen und komponentenorientierte Zerlegung
01.11.2023 Allerheiligen (entfällt)
08.11.2023 Mi 08:15-09:45 WE5/04.004 Cloud Computing und Software-Services
15.11.2023 Mi 08:15-09:45 WE5/04.004 Komponentenmärkte und Ökonomie der Software-Märkte
22.11.2023 Mi 08:15-09:45 WE5/04.004 Ableitung von Komponenten
20.12.2023 Mi 08:15-09:45 WE5/04.004 Spezifikation von Komponenten
27.12.2023 vorlesungsfrei (Weihnachtspause)
03.01.2024 vorlesungsfrei (Weihnachtspause)
10.01.2024 Mi 08:15-09:45 WE5/04.004 Gastvortrag
17.01.2024 Mi 08:15-09:45 WE5/04.004 Gastvortrag
07.02.2024 Mi 08:15-09:45 WE5/04.004 Vorstellung Studienleistung + Fragestunde
Änderungen vorbehalten
Organisatorisches
Organisatorisches I
 Dozent
 PD Dr. Sebastian Schlauderer
 Sprechstunde nach Voranmeldung
 sebastian.schlauderer@uni-bamberg.de
 Übungsleiter
 Maximilian Raab
 Sprechstunde nach Vereinbarung
 maximilian.raab@uni-bamberg.de
 Sekretariat
 Hedwig Alt
 info.iis@uni-bamberg.de
 Kommunikationskanäle
 Internet: www.uni-bamberg.de/iis
 VC: Kurs IIS-MODS-M (WS23/24)
 Online-Veranstaltungsraum (Vorlesung + Übung): https://e-learning2.iis.uni-bamberg.de/rooms/1c7-3py-yqe-7a9
Organisatorisches
Organisatorisches II
 Lehrkonzept
Vorlesungseinheiten erfolgen zu den wöchentlichen Vorlesungsterminen im Raum WE5/04.004
Übungsaufgaben zum Selbststudium im Anschluss an die Vorlesung im VC
Übungseinheiten erfolgen zu den wöchentlichen Übungsterminen im Raum WE5/04.014 (Start am
02.11.2023)
 Termine
Vorlesung: Mi. 8:15 – 09:45 Uhr (WE5/04.004 + Online-Veranstaltungsraum)
Übung: Do. 10:15 – 11:45 Uhr (WE5/04.014 + Online-Veranstaltungsraum)
 Unterlagen
Skript und Übungsblätter werden im VC zum Download gestellt
 Prüfung
schriftliche Klausur (open book), 90 Minuten, 6 ECTS-Punkte
Organisatorisches
Literaturempfehlungen
 Klaus Turowski: Fachkomponenten:

Komponentenbasierte betriebliche
Anwendungssysteme. Shaker Verlag, Aachen
2003.
 Peter Buxmann, Heiner Diefenbach Thomas Hess:
Die Softwareindustrie: Ökonomische Prinzipien,
Strategien, Perspektiven
 A. Benlian: Software-as-a-Service:
Anbieterstrategien, Kundenbedürfnisse und
Wertschöpfungsstrukturen
1. Motivation und Einführung
Lernziele
 Wurzeln und Triebfedern für modulare Systeme verstehen
 Definition des Begriffs „Komponente“ geben können
 Web Services und Komponenten abgrenzen können
 Vor- und Nachteile der Komponenten- und Service-Orientierung beschreiben können
1. Motivation
Wurzeln und Triebfedern
 Betriebliche Systeme als Integrierte Systeme

Funktionsumfang von ERP-Systemen wächst beständig
Ziel: Unternehmensweite Anwendungssysteme
 Entwicklung neuer Technologien

Neue Benutzungsschnittstellen (Mobile Geräte)
Neue Geschäftsprozesse (Integration mobiler Geräte)
 Wandel zur Informationsgesellschaft

Durchdringung aller Unternehmensbereiche mit IuK-Technologie
Flexible Integration entlang der Wertschöpfungskette
 Betriebliche Systeme als kritischer Erfolgsfaktor

Schnelle Verfügbarkeit (Time to Market, Anpassungen)
1. Motivation
Probleme in der Softwareentwicklung

 Externe Einflüsse
Einbindung von Benutzern in den Entwicklungsprozess
 Anzahl der Benutzergruppen steigt
(Anwender, Designer, Programmierer)
 Intensität der Einbindung ist hoch
Technischer Fortschritt
 Schnelle Abfolge von Releases
 Moore'sches Gesetz
immer noch gültig
Verfügbarkeit und
Wissensstand der Entwickler
 Qualifizierungskrise
 Konsequenzen
Neue Abläufe sind erforderlich
Anwender müssen explizit mit eingebunden und unterstützt werden
1. Motivation
Probleme in der Softwareentwicklung

 Interne Einflüsse
Software ist von Natur aus ein Metaprodukt
 Konstruktionsplan, Modell
 Parametrisierbar, skalierbar, mehrfach instanziierbar
 Benötigt zur Ausführung Hardware und eine Laufzeitumgebung
Nicht das Produkt selbst, sondern nur ein Konstruktionsplan des Produktes wird verkauft
 Auswirkungen
Programme nur vom Entwickler selbst zu verstehen
Keine Wiederverwendung möglich
Arbeitsteilige Fertigung sehr erschwert
 Konsequenzen
Projekte sind häufig zu spät und zu teuer
Ergebnisse sind nicht immer adäquat
1. Motivation
Die Welt ist komponentenorientiert aufgebaut
https://www.volkswagen.de/de/modelle-und-konfigurator/id3.html#CONFIGURE
1. Motivation
Die Welt ist komponentenorientiert aufgebaut
https://new.siemens.com/global/de/produkte/antriebstechnik.html
1. Motivation
Problemlösungsansätze
 Prozedurale Programmierung
Modularisierung
Kapselung
Lose Kopplung
 Objektorientierte Programmierung
Verbindung von Datenstrukturen und Methoden
Vererbung
 Komponenten
 Services
1. Motivation
Software-Industrialisierung
 Die Softwarebranche befindet sich in einer Phase der Industrialisierung
 Betrachtung der Ähnlichkeiten und Unterschiede mithilfe der
Erfahrungen aus der klassischen Industrie
 Typische Konsequenzen der Industrialisierung:
Kommoditisierung
(Zwang zur) Innovation
Um Dienstleistungen erweiterte Produkte
Verändertes Management
Veränderte Infrastruktur
Konzentration (Fusionen, Merger)
[Quelle: Taubner, D.: Software-Industrialisierung. In: Informatik Spektrum Band 28 (2005) Heft 4, S. 292-296]
1. Motivation
Software-Industrialisierung
 Software-Industrialisierung
Die Entstehung und Ausbreitung der Software-Entwicklung mit industriellen Mitteln (industrielle
Produktion von Software)
Typische Mittel klassischer Industrie werden auf die Softwarebranche übertragen
Klassische Industrie Softwarebranche
Massenproduktion Softwareproduktion
Arbeitsteilung, Fließband Zerlegung der Arbeit, Vorgehen
Spezialisierung Spezialisierung
Rationalisierung Rationalisierung
Automatisierung Werkzeuge, MDA
Kontinuierliche Verbesserung ISO900x, CMMI Level 5
Standardisierung Standardisierung (IP, J2EE, …)
Plattformstrategie (z.B. Automobilindustrie) z.B. Common IT-Platform
Modulkomponenten (z.B. Automobilindustrie) komponentenbasierte Architektur
Verringerung der Fertigungstiefe Outsourcing
Nutzung globaler Märkte Nutzung globaler Märkte
Globale Nutzung von Lohngefälle Offshoring
CMMI: capability maturity model integration, IP: internet protocol, ISO: international standards organization, J2EE: Java 2 Platform Enterprise Edition,
MDA: model driven architecture,
[Quelle: Taubner, D.: Software-Industrialisierung. In: Informatik Spektrum Band 28 (2005) Heft 4, S. 292-296]
1. Motivation
Analogie Halbleiterindustrie
 Disaggregation der Wertschöpfungskette aufgrund zunehmender Produktkomplexität
 Zwei Generationen neuer Design-Tools verändern die Verbindungen in der

Wertschöpfungskette
 ASIC (Application-Specific Integrated Circuit)
 Kunden- bzw. anwendungsspezifisch entwickelte integrierte Schaltung
 Je nach ASIC-Technologie wird bereits ab relativ geringen Stückzahlen ein Kostenvorteil erzielt
 EDA (Electronic Design Automation)
 Werkzeugunterstützung für den Entwurf von Schaltkreisen
 Komplexere Systeme werden möglich
 Weniger Expertenwissen nötig
 Disaggregierte Marktteilnehmer sind effizienter als integrierte Marktteilnehmer
1. Motivation
Entwicklung der Halbleiterindustrie

Core-Design Architekturdesign Chipdesign Produktion Design-Tools
ab 1970 Fully vertically integrated
Fairchild, TI, IBM
Neue komplexere Produkte führen zu einer Aufteilung in Upstream Design (bis Architektur) und
Fertigung; das Chipdesign ist eng mit der Produktion verzahnt;
ab 1980
ASIC design ASIC vendor
ATGT LSI
Elektronische Design-Werkzeuge ermöglichen die Automation des Chip-Designs (EDA);

benötigtes Produktionswissen ist in den EDA-Tools enthalten; “Foundry” fokussiert die
Produktion, “Fabless company” spezialisiert sich auf den gesamten Design-Prozess
ab 1990 Foundry

Fabless company EDA-Tools
Xilinx, Altora
TSMC, Anam
Standardisierte Funktionsbausteine führen zum Entstehen von Electronic Libraries und

bewirken eine Trennung zwischen Core-Design und Architecture-Design
ab 1995 Chipless company System level integrator ISI,

Foundry EDA-Tools
ARM, DSP, Rambus NSC
1. Motivation
Kosteneinsparungen
 Durch Spezialisierung auf die Phasen Architekturdesign und Chipdesign erreichte Einsparungen
 Designaufwand (Mannmonate)
 - 35%
 Designkosten
 - 40%
 Time to Market
 - 60%
 Qualität (Anzahl Redesigns)
 - 55%
[Quelle: Competitive Seminconductor Manufactoring Program, U.C. Berkeley 1997]
1. Motivation
Herausforderungen betrieblicher Anwendungen
 Unternehmen stehen vor ähnlichen Herausforderungen

Globalisierung: Steigender Wettbewerbsdruck
Individualisierung: Häufige Änderungen im Geschäftsumfeld
Neue technische Möglichkeiten: Wachsende Anwendungskomplexität
 Erfolgsfaktoren der Anwendungsentwicklung

Druck zur Kostensenkung und Straffung der Entwicklungsprozesse
Hohe Anwendungs- und Entwicklungskomplexität
Flexible Anpassung von Anwendungen erforderlich
 Maßnahme: Disaggregation der Entwicklungsarbeit

Zerlegung von Problemen in Bausteine
Verteilte Entwicklung
Zukauf von Fertigteilen
1. Motivation
Gründe für Komponenten- / Service-Orientierung
 Komplexitätsreduktion
Produktivitätssteigerung durch Spezialisierung
Innovation durch Spezialisierung
Mikroökonomische Skaleneffekte
 Wiederverwendbarkeit
Geringere Entwicklungskosten
Konzentration auf Kombination zur Nutzensteigerung
Skaleneffekte durch erweiterten Einsatzbereich
1. Motivation
Serviceorientierung als aktuelles Thema
https://marketresearchposts.com/2020/07/31/massive-growth-in-software-as-a-service-
saas-market-set-to-witness-huge-growth-by-2026-ibm-oracle-microsoft-fujitsu-google/
https://www.prnewswire.com/news-releases/global-software- https://www.statista.com/statistics/510333/worldwide-public-cloud-software-as-a-service/
as-a-service-saas-market-report-2020-market-was-valued-at-
134-44-bn-in-2018-and-is-expected-to-grow-to-220-21-bn-at-
a-cagr-of-13-1-through-2022--300970629.html
1. Motivation
Definition Komponente
 Allgemein
Bestandteil eines Ganzen
 Speziell in der Informatik

Eine Komponente (component) ist ein wiederverwendbarer, abgeschlossener und vermarktbarer
Softwarebaustein, der Dienste über eine wohldefinierte Schnittstelle zu Verfügung stellt und in zur Zeit
der Entwicklung in nicht unbedingt vorhersehbaren Kombinationen mit anderen Komponenten
einsetzbar ist
1. Motivation
Services und Komponenten
 Gemeinsamkeiten
Komponenten und Services sind in zuvor nicht vorhergesehener Kombination mit anderen Software-
Artefakten wiederverwendbar
Dienste werden über wohldefinierte Schnittstellen angeboten
Beide verbergen die Implementierung (Kapselung)
 Unterschiede
Wiederverwendet wird der Dienst (physisch), nicht das Artefakt (logisch)
Unterschiedliche Bezahlmodelle: Pay per Use, Pay per Licence
Komponenten werden als Software-Artefakte physisch ausgeliefert, bei Services wird nur eine
Schnittstellenspezifikation weitergegeben
Die Wiederverwendung von Services kann zur Laufzeit (dynamisch) erfolgen, da keine Artefakte zu
installieren sind
1. Motivation
Services und Komponenten
 Services als Anwendungsbausteine

Services stellen spezialisierte Dienste für den Aufruf bereit
Verwendung ähnelt der von Programmbibliotheken
 Services können in einem Katalog gesucht werden
 Schnittstellenbeschreibung ermöglicht Einbindung in die eigene Anwendung
 Aber: Services sind komplexer als einfache Programmroutinen!
 Services als laufende Bausteine

Services laufen bereits auf der Plattform eines Anbieters
Services sind sofort aufrufbar
Daraus ergeben sich spezifische Vor- und Nachteile
 Eigene technische Infrastruktur kann reduziert werden
 Abhängigkeit von der technischen Zuverlässigkeit des Anbieters
 Abhängigkeit von der Integrität des Anbieters (Umgang mit Daten etc.)
 Gezahlt wird ggf. nur für die Nutzung
1. Motivation
Service-orientierte Architekturen (SOA)
 Services
bieten klar definierte Funktionalität
sind abgeschlossen und unabhängig
Service Broker
können dynamisch gefunden werden (Service Registry)
sind komponierbar
Finden Veröffentlichen
 Verträge
 Rollen Service Requester Service Provider
(Service Subscriber) (Service Publisher)
Service Provider Binden
Service Requester
Service Broker (optional)
 Find-Bind-Execute Paradigma
1. Motivation
Web Services
 Web Services als Technologie

zur Realisierung service-orientierter Architekturen
basieren auf Standardprotokollen für das Auffinden, Binden und den Aufruf
 Technologie zur Verbindung verteilter Anwendungen

Nutzen etablierte Konzepte verteilter Systeme
Basieren auf Internet-Technologien (HTTP, TCP/IP)
Nutzen XML für den Austausch von Daten und den Funktionsaufruf (Prozedurfernaufruf)
 Lösen vorangehende Technologien zur Realisierung verteilter

Anwendungen ab
Weiterentwicklung von Konzepten wie CORBA
Aber: Verwendung von Internet-Technologien erzeugt Overhead
1. Motivation
Definitionen Web Service

 Web Services are modular, self-describing applications that can be published, located, and invoked from
anywhere. They are based on ubiquitous and open Internet Standards [Web Services Professional]
 A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being
defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other
software agents using XML based messages exchanged via internet-based protocols. [W3C]
 Web services is an esoteric data exchange technology that has mostly been used as a platform for connecting
information infrastructures within companies. [Jini Development Platform]
 Web-Services sind eigenständige Software-Komponenten, die bei einem

Anbieter installiert sind und Dienste für den Aufruf durch Dritte bereitstellen.
Die bereitgestellten Dienste werden durch XML Artefakte definiert,
beschrieben und unter Verwendung von Internet-Technologien aufgerufen.
1. Motivation
Vorteile der Komponenten- / Service-Orientierung

 Komponenten und Services
Können einzeln und unabhängig voneinander vermarktet werden
Haben eine wohldefinierte Schnittstelle zu ihrer Umwelt
Können beliebig mit anderen Komponenten kombiniert werden
Können an die spezifischen Bedürfnisse des einzelnen Unternehmens angepasst werden
Unterstützen eine bestimmte Menge von betrieblichen Aufgaben
Können kostengünstig zu einem (Gesamt-) Anwendungssystem kombiniert werden
Sind unabhängig von Programmiersprache und Entwicklungsumgebung kombinierbar
 Services
Können sofort eingesetzt werden (Hosting erfolgt durch den Anbieter)
Lassen sich nach Bedarf skalieren (Beschaffung von Verarbeitungskapazität)
1. Motivation
Strategieentwicklung
 Zweck der Informationsmanagement- Strategie
 Auf Grundlage der strategischen Unternehmensziele wird eine Informatik-Strategie entwickelt um die
Voraussetzung für eine strategische Maßnahmenplanung zu schaffen
 Strategische Richtungen
 Momentum Strategie
 Grundlegende Änderungen an den Informationssystemen nicht erforderlich
 Aggressive Strategie
 Technologie-Entwicklung wird aktiv vorangetrieben
 Moderate Strategie
 Mischung aus Momentum- und aggressiver Strategie
 Pilotprojekte auf Basis von strategischen Situationsanalysen
 Defensive Strategie
 Zurückdrängen des Einflusses von IuK-Technologien im Unternehmen
[Quelle: Heinrich, L.: Informationsmanagement. 5. Aufl., Oldenburg-Verlag, München 1996]
1. Motivation
Optionen der Informationsmanagement-Strategie
Unternehmensspezifität hoch
mittel
niedrig
niedrig mittel hoch
strategische Bedeutung
• Reiner Fremdbezug (Standard-Anwendungssoftware)

• Fremdbezug, intern unterstützt (Anpassung)
• Koordinierter Einsatz von internen und externen
Aufgabenträgern
• Eigenentwicklung, extern unterstützt (Auslagerung)
• Reine Eigenentwicklung
1. Motivation
Vision von ERP-Systemen
Informationsbedarf einer Unternehmung Business Components

Integrierte
Informations-
systeme
ERP Software
Anpassung der Business Components

ERP Software
1. Motivation
Make-and-buy-Strategie
 ERP-Systeme
Enterprise Ressource Planning - Systeme
Rückgrat komponentenorientierter betrieblicher Anwendungssysteme
Breite Marktakzeptanz
Offene Schnittstellen
Anpassungsbedarf ist auf Betriebsspezifika und Branchenspezifika beschränkt
 Auswechseln einzelner Komponenten

Proprietäre Lösungen für geschäftskritische Bereiche - Wettbewerbsvorteil
Kauf entsprechend spezialisierter Lösungen
1. Motivation
Differenzierung trotz Standardisierung
1. Motivation
Nachfrageseite
Vorteile Nachteile
Bedarfsgerechte Beschaffung Ggf. komplizierte und teure
Anpassung
Verbesserte Möglichkeit der Unklare Verantwortlichkeiten bei

Anpassung, höhere Flexibilität zusammengesetzten Systemen
Nutzung der Kernkompetenzen Zusätzlicher Aufwand für

der Hersteller Komposition gegenüber
vorintegrierten Systemen
Geringere Abhängigkeit vom

Hersteller
Wettbewerb, ggf. Käufermärkte
Integration von Altsystemen
Bessere Vergleichbarkeit
1. Motivation
Angebotsseite
Vorteile Nachteile
Höhere Softwarequalität Verringerte Abhängigkeit der
Kunden (Kundenbindung)
Kürzere Time-to-Market Höherer Wettbewerb
Bedienung spezieller Käufermärkte bei verbreiteten

Marktsegmente Komponenten
Reduzierung Entwicklungs- und Standardisierungsaufwand

Wartungskosten
Geringere Kompliziertheit
Geringeres Entwicklungsrisiko
Geringere Markteintrittsbarrieren

V Mods 01

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

V Mods 01

Hochgeladen von

Copyright:

Verfügbare Formate

Vorlesung

Modulare und On-Demand-Systeme

PD Dr. Sebastian Schlauderer

Lehrstuhl für Wirtschaftsinformatik,

 Klaus Turowski: Fachkomponenten:

 Definition des Begriffs „Komponente“ geben können

 Web Services und Komponenten abgrenzen können

 Vor- und Nachteile der Komponenten- und Service-Orientierung beschreiben können

Wurzeln und Triebfedern

 Betriebliche Systeme als Integrierte Systeme

 Entwicklung neuer Technologien

 Wandel zur Informationsgesellschaft

 Betriebliche Systeme als kritischer Erfolgsfaktor

Probleme in der Softwareentwicklung

Probleme in der Softwareentwicklung

Die Welt ist komponentenorientiert aufgebaut

Die Welt ist komponentenorientiert aufgebaut

 Zwei Generationen neuer Design-Tools verändern die Verbindungen in der

 Disaggregierte Marktteilnehmer sind effizienter als integrierte Marktteilnehmer

Entwicklung der Halbleiterindustrie

ab 1970 Fully vertically integrated

Fairchild, TI, IBM

Elektronische Design-Werkzeuge ermöglichen die Automation des Chip-Designs (EDA);

ab 1990 Foundry

Standardisierte Funktionsbausteine führen zum Entstehen von Electronic Libraries und

ab 1995 Chipless company System level integrator ISI,

[Quelle: Competitive Seminconductor Manufactoring Program, U.C. Berkeley 1997]

Herausforderungen betrieblicher Anwendungen

 Unternehmen stehen vor ähnlichen Herausforderungen

 Erfolgsfaktoren der Anwendungsentwicklung

 Maßnahme: Disaggregation der Entwicklungsarbeit

Gründe für Komponenten- / Service-Orientierung

Serviceorientierung als aktuelles Thema

 Speziell in der Informatik

Services und Komponenten

Services und Komponenten

 Services als Anwendungsbausteine

 Services als laufende Bausteine

Service-orientierte Architekturen (SOA)

 Web Services als Technologie

 Technologie zur Verbindung verteilter Anwendungen

 Lösen vorangehende Technologien zur Realisierung verteilter

Definitionen Web Service

 Web-Services sind eigenständige Software-Komponenten, die bei einem

Vorteile der Komponenten- / Service-Orientierung

Optionen der Informationsmanagement-Strategie

niedrig mittel hoch

• Reiner Fremdbezug (Standard-Anwendungssoftware)

Vision von ERP-Systemen

Informationsbedarf einer Unternehmung Business Components

Anpassung der Business Components

 Auswechseln einzelner Komponenten

Differenzierung trotz Standardisierung

Verbesserte Möglichkeit der Unklare Verantwortlichkeiten bei

Nutzung der Kernkompetenzen Zusätzlicher Aufwand für

Geringere Abhängigkeit vom

Wettbewerb, ggf. Käufermärkte

Integration von Altsystemen

Kürzere Time-to-Market Höherer Wettbewerb

Bedienung spezieller Käufermärkte bei verbreiteten

Reduzierung Entwicklungs- und Standardisierungsaufwand

Das könnte Ihnen auch gefallen