PreprintPDF Available

Komposition und Interoperabilität von IT-Systemen - Entwurf vom 9.1.2021

Authors:
Preprints and early-stage research may not have been peer reviewed yet.

Abstract

In diesem Artikel diskutiere ich Interoperabilität von berechenbaren Systemen mithilfe des mathematischen Konzepts der Komposition. Die zentrale Vorstellung ist, dass Systeme durch Interaktion komponieren und diese Komposition mathematisch als Operator, also als Funktion auf Systemen beschreibbar ist. Daraus ergibt sich der Begriff des Interface eines Systems, als Zusammenfassung aller seiner auf die Komposition bezogenen Angaben, auf natürliche Art und Weise ebenso wie der Begriff der Komponente als eines Systems, das für eine bestimmte Komposition konstruiert wurde. Ich unterscheide zwei grundsätzlich verschiedene Kompositionen von Systemen. Zunächst die hierarchische Komposition, die Systeme als Ganzes erfasst und zur Bildung von Supersystemen führt. Sie basiert auf den Kompositionsregeln berechenbarer Funktionen und führt zu den Interfaces der Operationen (+Events) sowie zu Komponentenhierarchien. Demgegenüber steht eine zweite Form der Komposition, die Systeme nur partiell im Sinne einer Projektion erfasst und zu vergleichsweise loser Kopplung führt, mit dem Interface der Protokolle. Damit sind Interfaces, die Operationen repräsentieren, per Definitionem nur für hierarchische Kompositionen geeignet und keine wesentliche Hilfe in der Darstellung netzwerkartiger ''horizontaler'' Interaktionen. Um die Anwendbarkeit des Kompositionskonzepts zu demonstrieren, werden verschiedene System-, Interface- und Komponentenmodelle aus der Literatur diskutiert, u.a. das Komponentenmodell verteilter Objekte, sowie die Interfacekonzepte von SOA und REST.
f, g :NN
h=fg
h(n) = f(g(n))
S1,...,Sn
CS
Sges =CS(S1,...,Sn).
E(Sges)
Sges CS
CEE(Sges)CE(E(S1), . . . , E (Sn))
E(CS(S1,...,Sn)) = CE(E(S1), . . . , E(Sn))
Fn
n
g1, . . . , gnFmhFnf=
h(g1, . . . , gn)
gFnhFn+2 aNnbN
fFn+1 f(a, 0) = g(a)f(a, b + 1) =
h(a, b, f (a, b))
µ g Fn+1 ab g(a, b)=0
µ µb[g(a, b) = 0] b g(a, b) = 0
f(a) = µb[g(a, b) = 0]
µ
A A0
CA B
S=C(A,B)A A0
S=C(A0,B)
A0A
A v A0C0
A0B S0=C0(A0,B)
S v S 0
C0A
S=C0(A,B)AC0
S=C(A0,B)A A0
CA0C
A B
S=C(A,B)
A0
A
f
q(t0)
out(t0)=fint(q(t), in(t))
fext(q(t), in(t))
(in, out, q) : TI×O×Q T
I, O, Q
f
t0t
S1S2S3
Sges fges (x)=2x+ 5
Sges
S1S2S3
Sges fges (x) = 2x+ 5
S1S2
S3Sges
S1
int s2(int n) {return(2*n);}
int s3(int n) {return(n+5);}
int s(int n) {return(s3(s2(n)));}
S1
RiP
P=CP rot
R(R1,...,Rn)
Z1
Z2
C
p i q
o p i/o
q
QZ1,2/C ={away, wait, bridge}
IZ1,2={go}
OCOZ1,2={arrived, left}
IC
away arrived
wait
go
lef t
q(t0) = fint(in(t), q(t))
out(t) = fext(in(t), q(t))
http://
docs.oasis-open.org/soa-rm/v1.0/
http://www.w3.org/TR/wsdl20/
ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
In the last decade, a large number of different software component models have been developed, with different aims and using different principles and technologies. This has resulted in a number of models which have many similarities, but also principal differences, and in many cases unclear concepts. Component-based development has not succeeded in providing standard principles, as has, for example, object-oriented development. In order to increase the understanding of the concepts and to differentiate component models more easily, this paper identifies, discusses, and characterizes fundamental principles of component models and provides a Component Model Classification Framework based on these principles. Further, the paper classifies a large number of component models using this framework.
Article
In this article, we introduce a classification of system interactions to guide the discourse on their interfaces and interoperability. It is based on a simple, but nevertheless complete classification of system interactions with respect to information transport and processing. Information transport can only be uni- or bidirectional and information processing is subclassified along the binary dimensions of state, determinism and synchronicity. For interactions with bidirectional information flow we are able to define a criterion for a layered structure of systems: we name a bidirectional interaction ”horizontal” if all interacting systems behave the same with respect to state, determinism and synchronicity and we name it “vertical” — providing a semantic direction — if there is a behavioral asymmetry between the interacting systems with respect to these properties. It is shown that horizontal interactions are essentially stateful, asynchronous and nondeterministic and are described by protocols. Vertical interactions are essentially top-down-usage, described by object models or operations, and bottom-up-observation, described by anonymous events. The interaction classification thereby helps to better understand the significant relationships that are created between interacting discrete systems by their interactions and guides us on how to talk about discrete systems, their interfaces and interoperability. To show its conceptual power, we apply the interaction classification to assess several other architectural models, communication technologies and so called software design or architectural styles like SOA and REST.
Article
Software reuse is finally here but comes with risks.
Article
Is there a science of system design? Just like any other design activity, system design is partly an art. However, mathematical theories and computer automation can help, and are even essential for designing complex systems reliably and economically. Until today, the plethora of different types of systems has resulted in a fragmented space of theories and tools. The advent of cyber-physical systems, which are by definition multidisciplinary, has urged researchers to rethink systems and system design, with model-based methods gaining acceptance. This paper describes some of the challenges in the domain, expanding on the key principle of compositionality.
Article
Some observations are made concerning the process of developing complex systems. A broad class of systems, termed reactive, is singled out as being particularly problematic when it comes to finding satisfactory methods for behavioral description. In this paper we recommend the recently proposed statechart method for this purpose. Moreover, it is observed that most reactive systems cannot be developed in a linear stepwise fashion, but, rather, give rise to a two-dimensional development process, featuring behavioral aspects in the one dimension and implementational ones in the other. Concurrency may occur in both dimensions, as orthogonality of states in the one and as parallelism of subsystems in the other. A preliminary approach to working one’s way through this “magic square” of system development is then presented. The ideas described herein seem to be relevant to a wide variety of application areas.
Conference Paper
Computer science is largely about computation. Many kinds of computing devices have been described, some abstract and some very concrete. Among them are: • Automata, including Turing machines, Moore machines, Mealy machines, pushdown automata, and cellular automata. • Computer programs written in a programming language. • Algorithms written in natural language and pseudocode. • von Neumann computers. • BNF grammars. • Process algebras such as CCS. Computer scientists collectively suffer from what I call the Whorfian syndrome the confusion of language with reality. Since these devices are described in different languages, they must all be different. In fact, they are all naturally described as state machines.