Analyse von Middleware-Technologien bzgl. Performanz und ihrer Eignung für lose und eng gekoppelte verteilte Anwendungen

Die vorliegende Dissertation analysiert die Middleware- Technologien CORBA (Common Object Request Broker Architecture), COM/DCOM (Component Object Model/Distributed Component Object Model), J2EE (Java-2-Enterprise Edition) und Web Services (inklusive .NET) auf ihre Eignung bzgl. eng und lose gekoppelten verteilten Anwendungen. Zusätzlich werden primär für CORBA die dynamischen CORBA-Komponenten DII (Dynamic Invocation Interface), IFR (Interface Repository) und die generischen Datentypen Any und DynAny (dynamisches Any) im Detail untersucht. Ziel ist es, a. konkrete Aussagen über diese Komponenten zu erzielen, und festzustellen, in welchem Umfeld diese generischen Ansätze ihre Berechtigung finden. b. das zeitliche Verhalten der dynamischen Komponenten bzgl. der Informationsgewinnung über die unbekannten Objekte zu analysieren. c. das zeitliche Verhalten der dynamischen Komponenten bzgl. ihrer Kommunikation zu messen. d. das zeitliche Verhalten bzgl. der Erzeugung von generischen Datentypen und das Einstellen von Daten zu messen und zu analysieren. e. das zeitliche Verhalten bzgl. des Erstellens von unbekannten, d. h. nicht in IDL beschriebenen Datentypen zur Laufzeit zu messen und zu analysieren. f. die Vorzüge/Nachteile der dynamischen Komponenten aufzuzeigen, ihre Einsatzgebiete zu definieren und mit anderen Technologien wie COM/DCOM, J2EE und den Web Services bzgl. ihrer Möglichkeiten zu vergleichen. g. Aussagen bzgl. enger und loser Koppelung zu tätigen. CORBA wird als standardisierte und vollständige Verteilungsplattform ausgewählt, um die o. a. Problemstellungen zu untersuchen. Bzgl. seines dynamischen Verhaltens, das zum Zeitpunkt dieser Ausarbeitung noch nicht oder nur unzureichend untersucht wurde, sind CORBA und die Web Services richtungsweisend bzgl. a. Arbeiten mit unbekannten Objekten. Dies kann durchaus Implikationen bzgl. der Entwicklung intelligenter Softwareagenten haben. b. der Integration von Legacy-Applikationen. c. der Möglichkeiten im Zusammenhang mit B2B (Business-to-Business). Diese Problemstellungen beinhalten auch allgemeine Fragen zum Marshalling/Unmarshalling von Daten und welche Aufwände hierfür notwendig sind, ebenso wie allgemeine Aussagen bzgl. der Echtzeitfähigkeit von CORBA-basierten, verteilten Anwendungen. Die Ergebnisse werden anschließend auf andere Technologien wie COM/DCOM, J2EE und den Web Services, soweit es zulässig ist, übertragen. Die Vergleiche CORBA mit DCOM, CORBA mit J2EE und CORBA mit Web Services zeigen im Detail die Eignung dieser Technologien bzgl. loser und enger Koppelung. Desweiteren werden aus den erzielten Resultaten allgemeine Konzepte bzgl. der Architektur und der Optimierung der Kommunikation abgeleitet. Diese Empfehlungen gelten uneingeschränkt für alle untersuchten Technologien im Zusammenhang mit verteilter Verarbeitung.

Type Systems for Distributed Programs: Components and Sessions

Modern software systems, in particular distributed ones, are everywhere around us and are at the basis of our everyday activities. Hence, guaranteeing their cor- rectness, consistency and safety is of paramount importance. Their complexity makes the verification of such properties a very challenging task. It is natural to expect that these systems are reliable and above all usable. i) In order to be reliable, compositional models of software systems need to account for consistent dynamic reconfiguration, i.e., changing at runtime the communication patterns of a program. ii) In order to be useful, compositional models of software systems need to account for interaction, which can be seen as communication patterns among components which collaborate together to achieve a common task. The aim of the Ph.D. was to develop powerful techniques based on formal methods for the verification of correctness, consistency and safety properties related to dynamic reconfiguration and communication in complex distributed systems. In particular, static analysis techniques based on types and type systems appeared to be an adequate methodology, considering their success in guaranteeing not only basic safety properties, but also more sophisticated ones like, deadlock or livelock freedom in a concurrent setting. The main contributions of this dissertation are twofold. i) On the components side: we design types and a type system for a concurrent object-oriented calculus to statically ensure consistency of dynamic reconfigurations related to modifications of communication patterns in a program during execution time. ii) On the communication side: we study advanced safety properties related to communication in complex distributed systems like deadlock-freedom, livelock- freedom and progress. Most importantly, we exploit an encoding of types and terms of a typical distributed language, session π-calculus, into the standard typed π- calculus, in order to understand their expressive power.

RFID Transponders : Link between information and material flows. How reliable are identification procedures?

Along with the growing complexity of logistic chains the demand for transparency of informations has increased. The use of intelligent RFID-Technology offers the possibility to optimize and control all capacities in use, since it enables the identification and tracking of goods alongside the entire supply chain. Every single product can be located at any given time and a multitude of current and historical data can be transferred. The interaction of the flow of material and the flow of information between the various process steps can be optimized by using RFID-Technology since it guarantees that all required data is available at the right time and at the right place. The local accessibility and convertibility of data allows a flexible, decentralised control of logistic systems. As additional advantages of RFID-Components can be considered that they are individually writable and that their identification can be achieved over considerable distances even if there is no intervisibility between tag and reader. The use of RFID-Transponder opens up new potentials regarding process security, reduction of logistic costs or availability of products. These advantages depend on reliability of the identification processes. The undisputed potentials that are made accessible by the use of RFID-Elements can only be beneficial when the informations that are decentralised and attached to goods and loading equipment can be reliably retrieved at the required points. The communication between tag and reader can be influenced by different materials such as metal, that can disturbed or complicate the radio contact. The communications reliability is subject of various tests and experiments that analyse the effects of different filling materials as well as different alignments of tags on the loading equipment.

Offenes Baukastensystem zur effizienten Dimensionierung von Materialflusssystemen

Die optimale Gestaltung logistischer Systeme und Prozesse bekommt eine immer größere Bedeutung für die Wirtschaftlichkeit und Wettbewerbsfähigkeit von Unternehmen. Für Einzelkomponenten von Materi-alflusssystemen sind neben exakten analytischen Verfahren auch Näherungslösungen und Ersatzmodelle in Form von Polynomen, neuronalen Netzen oder zeitdiskreten Verfahren vorhanden, mit denen eine gute Nachbildung des Verhaltens dieser Komponenten möglich ist. Ziel des Baukastensystems ist es, für diese Vielzahl von Methoden mit ihren spezifischen Ein- und Aus-gangsgrößen eine übergeordnete, einheitliche Kommunikations- und Datenschnittstelle zu definieren. In einem grafischen Editor kann ein Modell eines Materialflusssystems aus solchen Bausteinen gebildet und parametriert werden. Durch Verbindungen zwischen den Bausteinen werden Informationen ausge-tauscht. Die Berechnungen der Bausteine liefern Aussagen zu Auslastungen, Warteschlangen bzw. Warte-zeiten vor den Bausteinen sowie Flussgrößen zur Beschreibung der Abgangströme. The optimal arrangement of logistical systems and operations gets an increased importance for the economicalness and competitiveness of enterprises. For individual components of material flow systems there are also existing approximate solutions and substitute models besides exact analytical calculations in the form of polynomials, neural nets or time-discrete analysis which allows a good analytical description of the behaviour of these components. It is aim of the module system to define a superordinate and unified communication and data interface for all of these variety of methods with her specific input and output quantities. By using a graphic editor, the material flow system can be modelled of such components with specified functions and parameters. Connections between the components allows exchange of information. The calculations of the components provide statements concerning utilization, queue size or waiting time ahead of the components as well as parameters for the description of the departure process. Materialflusssysteme sind Träger innerbetrieblicher Transportprozesse und elementarer Bestandteil logistischer Systeme. Die optimale Gestaltung logistischer Systeme und Prozesse bekommt eine immer größere Bedeutung für die Wirtschaftlichkeit und Wettbewerbsfähigkeit von Unternehmen. Die effiziente Dimensionierung von Materialflusssystemen ist für Planer, Hersteller und Betreiber solcher Anlagen von grundsätzlicher Bedeutung. Für viele bei der Planung materialflusstechnischer Anlagen auftretende Fragestellungen steht noch immer kein Berechnungsverfahren oder -werkzeug zur Verfügung, welches allen drei folgenden Anforderungen gleicherma-ßen gerecht wird: Die Handhabung soll einfach, unkompliziert und schnell sein. Die Berechnungsergebnisse sollen eine hohe Genauigkeit haben. Die Berechnung soll allgemein gültige Ergebnisse liefern. Dabei handelt es sich um Fragestellungen, die durchaus grundlegender Natur sind. Beispielsweise nach den (statistisch) zu erwartenden minimalen und maximalen Auftragsdurchlaufzeiten, nach dem Einfluss von Belas-tungsschwankungen auf die Anlagenleistung, nach vorzusehenden Puffern (Stauplätze) und Leistungsreserven (Auslastung). Für die oben genannten Aufgaben der Materialflussplanung stehen heute hauptsächlich drei Verfahren zur Verfügung (Abb. 1): Faustformeln (gekennzeichnet mit f) sind einfach aber ungenau. Das Systemverhalten von Materialfluss-komponenten beschreiben sie selten über den gesamten Bereich möglicher Betriebsbedingungen und Konfi-gurationen. Das Verhalten von gesamten Materialflusssystemen ist zu komplex, als dass es mit Faustformeln adäquat beschreibbar wäre. Bedienungstheoretische Ansätze erlauben die Beschreibung von Materialflusskomponenten (kleines b) sehr genau und sehr umfassend, soweit Standardmethoden und -modelle der Bedienungstheorie anwendbar sind. Ist diese Voraussetzung nicht gegeben, kann der Aufwand zur Modellbildung schnell erheblich werden. Die Beschreibung von Materialflusssystemen (großes B) als Bedienungsnetzwerke ist nur unter (zum Teil stark) vereinfachenden Annahmen möglich. Solche Vereinfachungen gehen zu Lasten von Genauigkeit und All-gemeingültigkeit der Aussagen. Die Methoden sind häufig sehr komplex, ihre Anwendung erfordert vertief-te Kenntnisse in der Statistik und Stochastik. Simulationsuntersuchungen liefern für Materialflusskomponenten (kleines s) und für Materialflusssysteme (großes S) gleichermaßen genaue Aussagen. Der für die Untersuchungen erforderliche Aufwand hängt dabei weit weniger von den Eigenschaften und der Größe des Systems ab, als es bei bedienungstheoretischen An-sätzen der Fall ist. Die Aussagen der Simulation sind nie universell. Sie betreffen immer nur ein System in einer bestimmten Konfiguration. Die Anwendung der Simulation erfordert Spezialsoftware und vertiefte Kenntnisse in der Modellierung und Programmierung. Verfahren, die genaue und allgemein gültige Aussagen über das Verhalten komplexer Materialflusssysteme liefern können, sind insbesondere in der Phase der Angebotserstellung bzw. in der Phase der Grobplanung von besonderer Wichtigkeit. Andererseits sind heute verfügbare Verfahren aber zu kompliziert und damit unwirt-schaftlich. Gerade in der Phase der Systemgrobplanung werden häufig Änderungen in der Struktur des Systems notwendig, welche z.B. beim Einsatz der Simulation zu erheblichem Änderungsaufwand am Modell führt. Oftmals können solche Änderungen nicht schnell genug ausgeführt werden. Damit bleiben in der Praxis oft erhebliche Planungsunsicherheiten bestehen. Der Grundgedanke des Baukastensystems besteht in der Modularisierung von Materialflusssystemen in einzelne Bausteine und Berechnungen zum Verhalten dieser Komponenten. Die betrachteten Module sind Materialfluss-komponenten, die eine bestimmte logistische Funktion in einer konstruktiv bzw. steuerungstechnisch bedingten, definierten Weise ausführen. Das Verhalten einer Komponente wird durch Belastungen (Durchsatz) und techni-sche Parameter (Geschwindigkeit, Schaltzeit o.ä.) beeinflusst und kann durch ein adäquates mathematisches Modell quantifiziert werden. Das offene Baukastensystem soll dabei vor allem einen konzeptionellen Rahmen für die Integration derartiger Modellbausteine bilden. Es umfasst neben der Bausteinmodularisierung die Problematik der Kommunikation zwischen den Bausteinen (Schnittstellen) sowie Möglichkeiten zur Visualisierung von Ergebnissen. Das daraus abgeleitete softwaretechnische Konzept berücksichtigt neben der einheitlichen Integration der zum Teil stark unterschiedlichen Berechnungsverfahren für einzelne Materialflusskomponenten auch einheitliche Definitionen zur Beschreibung von benötigten Eingangsparametern einschließlich der Randbedingungen (Defini-tionsbereich) und Plausibilitätskontrollen sowie zur Ergebnisbereitstellung. Äußerst wichtig war die Zielstellung, das System offen und erweiterbar zu gestalten: Prototypisch wurden zwar einzelne vorliegende Bausteine integ-riert, es ist aber jederzeit möglich, weitere Verfahren in Form eines Bausteines zu implementieren und in das Baukastensystem einzubringen. Die Ergebnisse der Berechnungen für ein einzelnes Element (Output) fließen zugleich als Input in das nachfol-gende Element ein: Genau wie im realen Materialflusssystem durch Aneinanderreihung einzelner fördertechni-scher Elemente der Materialfluss realisiert wird, kommt es im Baukasten durch Verknüpfung der Bausteine zur Übertragung der relevanten Informationen, mit denen der Fluss beschrieben werden kann. Durch die Weitergabe der Ergebnisse kann trotz Modularisierung in einzelne Bausteine das Verhalten eines gesamten Materialflusssys-tems bestimmt werden. Daher sind auch hier einheitliche Festlegungen zu Art und Umfang der Übergabeparame-ter zwischen den Bausteinen erforderlich. Unter einem Baustein soll ein Modell einer Materialflusskomponente verstanden werden, welches das Verhalten dieser Komponente beim Vorliegen bestimmter Belastungen beschreibt. Dieses Verhalten ist insbesondere gekennzeichnet durch Warteschlangen und Wartezeiten, die vor der Komponente entstehen, durch Auslastung (Besetztanteil) der Komponente selbst und durch die Verteilung des zeitlichen Abstand (Variabilität) des die Komponente verlassenden Stroms an Transporteinheiten. Maßgeblich bestimmt wird dieses Verhalten durch Intensität und Variabilität des ankommenden Stroms an Transporteinheiten, durch die Arbeitsweise (z.B. stetig / unstetig, stochastisch / deterministisch) und zeitliche Inanspruchnahme der Komponente sowie durch Steuerungsregeln, mit denen die Reihenfolge (Priorisierung / Vorfahrt) und/oder Dauer der Abarbeitung (z.B. Regalbediengerät mit Strategie „Minimierung des Leerfahrtan-teils“) verändert werden. Im Grunde genommen beinhaltet ein Baustein damit ein mathematisches Modell, das einen oder mehrere an-kommende Ströme von Transporteinheiten in einen oder mehrere abgehende Ströme transformiert (Abb. 2). Derartige Modelle gibt es beispielsweise in Form von Bedienmodellen ([Gnedenko1984], [Fischer1990 u.a.]), zeitdiskreten Modellen ([Arnold2005], [Furmans1992]), künstlichen neuronalen Netzen ([Schulze2000], [Markwardt2003]), Polynomen ([Schulze1998]). Die zu Grunde liegenden Verfahren (analytisch, simulativ, numerisch) unterscheiden sich zwar erheblich, genü-gen aber prinzipiell den genannten Anforderungen. Die Fixierung auf ein mathematisches Modell ist aber nicht hinreichend, vielmehr bedarf es für einen Baustein auch definierter Schnittstellen, mit denen der Informationsaustausch erfolgen kann (Abb. 3). Dazu zählen neben der einheitlichen Bereitstellung von Informationen über die ankommenden und abgehenden Materialströme auch die Berücksichtigung einer individuellen Parametrierung der Bausteine sowie die Möglichkeit zur Interaktion mit dem Bediener (Anordnung, Parametrierung und Visualisierung). Das offene Konzept erlaubt das eigenständige Entwickeln und Aufnehmen neuer Bausteine in den Baukasten. Dazu ergibt sich als weitere Anforderung die einfache Konfigurierbarkeit eines Bausteins hinsichtlich Identifika-tion, Aussehen und Leistungsbeschreibung. An einen Baustein innerhalb des Baukastensystems werden weiter-hin die folgenden Anforderungen gestellt: Jeder Baustein ist eine in sich abgeschlossene Einheit und kann nur über die Ein- und Ausgänge mit seiner Umgebung kommunizieren. Damit ist ausgeschlossen, dass ein Baustein den Zustand eines ande-ren Bausteins beeinflussen kann. Das führt zu den beiden Lokalitätsbedingungen: Es gibt keine �����bergeordnete Steuerung, die in Abhängigkeit vom aktuellen Systemzustand dispositive Entscheidungen (z.B. zur Routenplanung) trifft. Blockierungen in Folge von Warteschlangen haben keine Auswirkungen auf die Funktion an-derer Bausteine. Bausteine beinhalten in sich abgeschlossene Verfahren zur Dimensionierung einer Komponente (Klas-se) des Materialflusssystems (z.B. Einschleusung auf einen Sorter, Drehtisch als Verzweigungselement oder als Eckumsetzer). Dabei werden auf Grund von technischen Parametern, Steuerungsstrategien und Belastungsannahmen (Durchsatz, Zeitverteilungen) Ergebnisse ermittelt. Ergebnisse im Sinne dieses Bausteinkonzepts sind Auslastungen, Warteschlangen bzw. Wartezeiten vor dem Baustein sowie Flussgrößen zur Beschreibung des Abgangstroms. Als Beschreibung eignen sich sowohl einzelne Kennwerte (Mittelwert, Varianz, Quantile) als auch statische Verteilungsfunktionen. Die Lokalitätsbedingungen stellen Einschränkungen in der Anwendbarkeit des Baukastensystems dar: Systeme mit übergeordneten Steuerungsebenen wie Routenplanung oder Leerfahrzeugsteuerung, die Entscheidungen auf Grund der vorhandenen Transportaufträge und des aktuellen Systemzustands treffen (Fahrerlose Transportsys-teme, Elektrohängebahn), können mit dem Baukasten nicht bearbeitet werden. Diese auf Unstetigförderern basierenden Systeme unterscheiden sich aber auch in ihren Einsatzmerkmalen grundlegend von den hier betrach-teten Stetigförderersystemen. Das Problem der Blockierungen vorgelagerter Bereiche durch zu große Warteschlangen kann dagegen bereits mit dem Baukasten betrachtet und zumindest visualisiert werden. Dazu ist den Verbindungen zwischen den Bausteinen eine Kapazität zugeordnet, so dass durch Vergleich mit den berechneten Warteschlangenlängen eine generelle Einschätzung zur Blockierungsgefahr möglich wird: Ist die Streckenkapazität kleiner als die mittlere Warteschlange, muss von einer permanenten Blockierung ausgegangen werden. In diesem Fall kann der vorhergehende Baustein seine gerade in Bearbeitung befindli-che Transporteinheit nach dem Ende der „Bedienung“ nicht sofort abgeben und behindert damit auch seine weiteren ankommenden Transporteinheiten. Für die Transporteinheiten bedeutet das eine Verlustzeit, die auch nicht wieder aufgeholt werden kann, für das gesamte Transportsystem ist von einer Leistungsminde-rung (geringerer Durchsatz, größere Transport- / Durchlaufzeit) auszugehen. Da bei der Berechnung der Bausteine von einer Blockierfreiheit ausgegangen wird, sind die Berechnungser-gebnisse in aller Regel falsch. Ist die Streckenkapazität zwar größer als die mittlere Warteschlange, aber kleiner als beispielsweise das 90%-Quantil der Warteschlange, ist mit teilweisen Blockierungen (in dem Fall mit mehr als 10% Wahr-scheinlichkeit) zu rechnen. Dann tritt der o.g. Effekt nur zeitweise auf. Die Ergebnisse der Berechungen sind dann zumindest für einzelne Bausteine ungenau. In beiden Fällen wird das Problem erkannt und dem Anwender signalisiert. Es wird davon ausgegangen, dass die geplante Funktionalität und Leistungsfähigkeit des Materialflusssystems nur dann gewährleistet ist, wenn keine Blockierungen auftreten. Durch Änderung der Parameter des kritischen Bausteins, aber auch durch Änderung der Materialströme muss daher eine Anpassung vorgenommen werden. Erst bei Vorliegen der Blockierfreiheit ist die Voraussetzung der Lokalität der Berechnungen erfüllt. Die Berechnungsverfahren in den Bausteinen selbst können wegen der Modularisierung (Lokalität) sehr unter-schiedlicher Art sein. Dabei ist es prinzipiell möglich, die einzelnen Ergebnisse eines Bausteins mit verschiede-nen Verfahren zu ermitteln, insbesondere dann, wenn auf Grund eines eingeschränkten Definitionsbereichs der Eingangsparameter die Anwendung eines bestimmten Verfahrens nicht zulässig ist. Bausteine, die einen Materialfluss auf Grund äußerer, nicht aus dem Verhalten des Bausteins resultierende Einflüsse generieren (Quelle) oder verändern (Service-Station), sind durch eine Flussgröße  parametriert. Die Flussgröße ist eine statistische Verteilungsfunktion zur Beschreibung der Ankunfts- und Abgangsströme (Zwi-schenankunftszeiten). In der Praxis, insbesondere in der Planungsphase, ist aber eine solche Verteilungsfunktion meist nicht bekannt. Zudem erweist sich das Rechnen mit Verteilungsfunktionen als numerisch aufwändig. Untersuchungen in [Markwardt2003] haben gezeigt, dass eine Parametrisierung als Abstraktion über statistische Verteilungsfunktionen mit gleichen Erwartungswerten, Minima und Streuungen ausreichend genaue Ergebnisse liefert. Daher wird die Flussgröße beschrieben durch die Parameter Ankunftsrate (=Durchsatz), Mindestzeitabstand tmind und Variationskoeffizient c (als Maß für die Variabilität des Stroms). Zur Visualisierung der Ergebnisse kann die dreiparametrige Gammaverteilung zu Grunde gelegt werden, die eine gute Anpassung an reale Prozessverläufe bietet und durch die genannten Parameter eindeutig beschrieben ist: Weitere leistungsbestimmende Größen wie technische Parameter, Zeitbedarfe u.ä. werden als Parametertupel (k) der jeweiligen Klasse zugeordnet. So ist z.B. bei einer Einschleusung auf einen Sorter zu garantieren, dass der Strom auf der Hauptstrecke nicht angehalten wird. Das erfordert bei einer Einschleusung von der Nebenstrecke eine Lücke im Gutstrom auf der Hauptstrecke mit der Länge Mindestabstand und Fördergeschwindigkeit sind Parameter der ankommenden Förderstrecken, demnach ist lediglich die Größe ttr als Transferzeit ein leistungsbestimmender Parameter der Einschleusung. Förderstrecken stellen die Verbindungen zwischen den Bausteinen her und realisieren den eigentlichen Material-fluss durch das System. Die technische Realisierung kann dabei prinzipiell durch verschiedenartige Bauformen von Stetig- und Unstetigförderern erfolgen. Systeme, die aber vollständig auf der Basis von Unstetigförderern arbeiten wie fahrerlose Transportsysteme (FTS) oder Elektrohängebahn (EHB), werden im Rahmen des Baukas-tens nicht betrachtet, weil die Lokalitätsbedingungen nicht gelten und beispielsweise eine übergeordnete Sys-temsteuerung (Fahrzeugdisposition, Leerfahrtoptimierung) einen erheblichen Einfluss auf die Leistungsfähigkeit des Gesamtsystems hat. Förderstrecken im hier verwendeten Sinne sind Rollen-, Ketten-, Bandförderer oder ähnliches, deren maximaler Durchsatz im Wesentlichen durch zwei Parameter bestimmt wird: Fördergeschwindigkeit (vF) und Mindestab-stand zwischen den Transporteinheiten (smind). Der Mindestabstand ergibt sich aus der Länge der Transportein-heit in Transportrichtung (sx) und einem Sicherheitsabstand (s0), der für ein sicheres und gefahrloses Transportie-ren erforderlich ist. Die Mindestzeit tmind,S zwischen zwei Fördereinheiten auf einer Förderstrecke bestimmt sich demnach zu Ist das verbindende Förderelement nicht staufähig (nicht akkumulierend, z.B. Gurtbandförderer), so kann sich der Abstand zwischen den Fördergütern während des Förder- oder Transportvorgangs nicht verändern: Muss das Band angehalten werden, weil eine Abgabe an das nachfolgende Förderelement nicht möglich ist, bleiben alle Einheiten stehen. In diesem Fall ist es also nicht möglich, die Lücken im Transportstrom zu schließen, die bereits bei der Aufgabe auf das Förderelement entstehen. Für die Berechnung der Mindestzeit tmind,S bedeutet das, dass dann auch die Mindestzeit tmind,B des vorhergehenden Bausteins berücksichtigt werden muss. Die Mindestzeit des Streckenelements nach (6) bzw. (7) wird als einer der Parameter der Flussgröße zur Be-schreibung des am nachfolgenden Baustein ankommenden Stroms verwendet. Als Parameter der Förderstrecke werden neben der Fördergeschwindigkeit daher auch Angaben zum Transportgut (Abmessungen, Sicherheitsab-stand, Transportrichtung) benötigt. Es bot sich ferner an, eine Typisierung der Förderstrecken hinsichtlich ihrer technischen Realisierung (Rollenförderer, Kettenförderer, Bandförderer usw. mit zugeordneten Parametern) vorzunehmen, um den Aufwand für die Beschreibung der Förderstrecken gering zu halten. Weitere Parameter der Förderstrecken dienen der Aufnahme der Berechnungsergebnisse von vor- bzw. nachge-lagerten Bausteinen und beinhalten: die Länge der Warteschlange (einzelne Kenngrößen wie Mittelwert, 90%-, 95% bzw. 99%-Quantil oder - falls ermittelbar - als statistische Verteilung) die Wartezeit (ebenfalls Kenngrößen oder statistische Verteilung) die (Strecken-)Auslastung Variationskoeffizient für den Güterstrom Für die Darstellung des Materialflusses in einem System werden jeweils einzelne Materialfluss-Relationen betrachtet. Dabei wird angenommen, dass jede Relation an einer Quelle beginnt, an einer Senke endet, dabei mehrere Materialfluss-Komponenten (Bausteine) durchläuft und über den gesamten Verlauf in seiner Größe (Transportmenge) konstant bleibt. Einziger leistungsbestimmender Parameter einer Materialfluss-Relation ist die Transportmenge. Sie wird als zeitabhängige Größe angegeben und entspricht damit dem Durchsatz. Mindestabstand und Variationskoeffizient werden vom erzeugenden Baustein (Quelle) bestimmt, von den weiteren durchlaufenen Bausteinen verändert und über die Förderstrecken jeweils an den nachfolgenden Baustein übertragen. Die verbindenden Förderstrecken werden mit dem jeweiligen Durchsatz „belastet“. Bei Verbindungen, die von mehreren Relationen benutzt werden, summieren sich die Durchsätze, so dass sich unterschiedliche Strecken- und Bausteinbelastungen ergeben. Im Kontext des Baukastensystems werden Metadaten1 verwendet, um die in einem Baustein enthaltenen Infor-mationen über Anwendung, Verfahren und Restriktionen transparent zu machen. Ziel des Baukastensystems ist es je gerade, einfache und leicht handhabbare Berechnungsmodule für einen breiteren Anwenderkreis zur Verfü-gung zu stellen. Dazu sind Beschreibungen erforderlich, mit denen das Leistungsspektrum, mögliche Ergebnisse und Anwendungs- bzw. Einsatzkriterien dokumentiert werden. Aufgabe der Baustein-Bibliothek ist die Sammlung, Verwaltung und Bereitstellung von Informationen über die vorhandenen Bausteine. Damit soll dem Nutzer die Möglichkeit gegeben werden, für seine konkret benötigte Materialflusskomponente einen geeigneten Baustein zur Abbildung zu finden. Mit der Entwicklung weiterer Bausteine für ähnliche Funktionen, aber unterschiedliche Realisierungen (z. B. Regalbediengerät: einfach- oder doppeltiefe Lagerung, mit oder ohne Schnellläuferzone usw.) wächst die Notwendigkeit, die Einsatz- und Leis-tungsmerkmale des Bausteins in geeigneter Weise zu präsentieren. Die Baustein-Bibliothek enthält demnach eine formalisierte Beschreibung der vorhandenen und verfügbaren Bausteine. Die Informationen sind im Wesentlichen unter dem Aspekt einer einheitlichen Identifikation, Infor-mation, Visualisierung und Implementierung der unterschiedlichen Bausteine zusammengestellt worden. Einige der in der Baustein-Bibliothek enthaltenen Metadaten lassen sich durchaus mehreren Rubriken zuordnen. Identifikation und Information Ein Baustein wird durch eine eindeutige Ident-Nummer fixiert. Daneben geben Informationen zum Autor (Ent-wicklung und/oder Implementierung des Verfahrens) und eine Funktionsbeschreibung eine verbale Auskunft über den Baustein. Zusätzlich ist jeder Baustein einem bestimmten Typ zugeordnet entsprechend der Baustein-Klassifizierung (Bearbeiten, Verzweigen, Zusammenführen usw.), über den die Baustein-Auswahl eingegrenzt werden kann. Visualisierung Die Parameter für die Visualisierung beschreiben die Darstellung des Bausteins innerhalb des Baukastensystems (Form, Farbe, Lage der Ein- und Ausgänge des Bausteins, Icons). Implementierung Der Klassenname verweist auf die Implementierung des Bausteins. Zusätzlich benötigte Programm-Ressourcen (externe Bibliotheken wie *.dll , *.tcl o.ä.) können angegeben werden. Weiterhin sind Bezeichnungen und Erläuterungen der erforderlichen technischen Parameter für den Eingabedialog enthalten. Für die Förderstrecken wird ebenfalls eine formalisierte Beschreibung verwendet. Sie verweist jedoch nicht wie die Baustein-Bibliothek auf Software-Ressourcen, sondern enthält nur eine Reihe technischer Parameter, die für das Übertragungsverhalten der Förderstrecke eine Rolle spielen (Fördergeschwindigkeit, Arbeitsweise akkumu-lierend, Ausrichtung des Transportguts). Die Einträge lassen sich als Musterdatensätze (Template) für die Bau-stein-Verbindungen auffassen, um bestimmte, häufig vorkommende fördertechnische Lösungen diesen Verbin-dungen in einfacher Weise zuordnen zu können. Die Angaben sind aber im konkreten Anwendungsfall änderbar. Angaben zum Transportgut beschränken sich auf die Abmessungen der Transporteinheiten (Länge, Breite) und den erforderlichen Sicherheitsabstand (s0). Als Grundform wird von einer Standard-Euro-Palette (1200x800 mm) ausgegangen, es lassen sich aber auch Güter mit anderen Maßen hinzufügen. Die Angaben zum Transportgut werden in Verbindung mit den Parametern der Förderstrecken (Ausrichtung des Gutes längs oder quer) ausgewertet, so dass sich die jeweiligen Mindestabstände (Gleichung 6 bzw. 7) sowie der maximale Durchsatz Qmax als Grundlage für die Berechnung der Streckenauslastung bestimmen lassen. Das Gesamtkonzept des Baukastensystems ist in Abbildung 4 dargestellt. Es besteht im Wesentlichen aus drei Bereichen: Bausteinerstellung Bausteinverwaltung (Bibliotheken) Baukasten (Benutzeroberfläche) Dabei ist der Bereich der Bausteinerstellung nicht unmittelbarer Bestandteil der realisierten Lösung. Sie ist vielmehr die Quelle für die Bausteine, die über die jeweiligen Metadaten in einer Baustein-Bibliothek verwaltet und bereitgestellt werden. Die Verwaltung von Bausteinen und Förderstrecken ist die Umsetzung der Baustein-Bibliothek und (im erwei-terten Sinne) der Definitionen für die Förderstrecken. Der Modellbaukasten selbst stellt die Grafische Nutzeroberfläche dar (Abb. 11) und enthält den interaktiven, grafischen Modelleditor, die Auswahlelemente (Werkzeugkoffer bzw. -filter) für Bausteine und Förderstrecken, tabellarische Übersichten für alle Bausteine, Förderstrecken und Materialflussrelationen sowie Eingabedialoge für Bausteine, Förderstrecken und Materialflussrelationen. Die Entwicklung eines Modells mit dem Baukastensystem erfolgt prinzipiell in drei Schritten: Schritt eins umfasst die Anordnung und Definition der Bausteine. Der Modellbaukasten bietet die Möglich-keit, einen bestimmten Baustein direkt (z.B. Ausschleusung) oder unter Nutzung eines Bausteinfilters (z.B. alle Verzweigungselemente) auszuwählen und im grafischen Editor mittels Mausklick zu platzieren . An-schließend erfolgt im Dialog die notwendige Parametrierung des Bausteins. Dies beinhaltet sowohl die An-gaben zur Visualisierung (Drehung, Spiegelung) als auch die für die Dimensionierung erforderlichen techni-schen Parameter. Die für jeden Baustein benötigten Leistungsanforderungen (Durchsatz, lokale Transport-matrix) werden allerdings nicht direkt angegeben, sondern aus den Beziehungen zu den vor- und nachgela-gerten Bausteinen automatisch ermittelt (Übertragungsfunktion der Förderstrecken). Danach erfolgt in einem zweiten Schritt die Definition von Verbindung zwischen den Bausteinen (Förder-strecken): Das Erzeugen der Bausteinverbindungen ist ebenfalls ganz einfach zu realisieren. Nach Auswahl der zu Grunde liegenden Fördertechnik (z.B. Rollenförderer) wird durch Ziehen des Mauszeigers von einem nicht belegten Ausgang zu einem nicht belegten Eingang eines Bausteins die entsprechende Förderstrecke erzeugt. In einem abschließenden Dialog können die gewählten Voreinstellungen zum Transportgut, zum Förderertyp usw. bestätigt oder gegebenenfalls korrigiert werden. Außerdem kann die Kapazität der Förder-strecke definiert werden. Dabei geht es weniger um die Länge des Förderers als viel mehr um die Anzahl der vorgesehenen Puffer- oder Stauplätze im Zusammenhang mit den zu berechnenden Warteschlangenlän-gen. Abschließend wird im dritten Schritt der Materialfluss definiert: Ein Materialstrom ist jeweils eine Relation, die an einer Quelle beginnt, an einer Senke endet und dabei mehrere Bausteine durchläuft. Da die Förder-strecken zu diesem Zeitpunkt bereits definiert sein müssen, kann automatisch ein möglicher Weg zwischen Quelle und Senke gefunden werden. Ähnlich wie bei Routenplanungssystemen kann dabei durch zusätzliche Angabe von Zwischenpunkten (via) der automatisch vorgeschlagene Transportweg verändert und angepasst werden (Abb. 5). Nach Bestätigung des Transportweges und damit der unterwegs zu passierenden Bausteine erfolgt in einem Dialog die Parametrierung (Transportmenge pro Stunde) für diese Relation. Die Elemente des Transportweges (die benutzten Förderstrecken) werden mit dem entsprechenden Durchsatz „belastet“. Nach Abschluss der Modellierung kann die Berechnung ausgeführt werden. Im Ergebnis werden Kennzahlen bestimmt und im Baukasten in verschiedener Form visualisiert, um eine Bewertung der Ergebnisse vornehmen zu können. Eine Übersicht Fehlermeldungen listet die Problemelemente auf. Dabei wird die Schwere eines Problems farb-lich hervorgehoben: fataler Fehler (rot): entsteht z.B. bei Überlastung eines Bausteins – die geforderte Leistung für einen Bau-stein (und damit die des Gesamtsystems) kann nicht erbracht werden. lokaler Fehler (orange): entsteht z.B. bei permanenter Blockierung – die mittlere Warteschlange vor einem Baustein ist größer als dessen vorgesehene Kapazität. Warnung (hellgelb): bei teilweiser Blockierung – das 90%-Quantil der Warteschlange ist größer als die Ka-pazität der Förderstrecke, es ist daher zeitweise mit Blockierungen (und damit Behinderungen des vorherge-henden Bausteins) zu rechnen. Information (weiß): wird immer dann erzeugt, wenn Erwartungswerte für die Wartezeit oder Warteschlange mit einem G/G/1-Bedienmodell berechnet werden. Die Lösungen dieser Näherungsgleichungen sind im All-gemeinen nicht sehr genau, dienen aber als Abschätzung für die sonst fehlenden Kennwerte. Entsprechend der berechneten Auslastung werden die Bausteine im Modelleditor mit einer Farbabstufung von Grün nach Rot markiert, Bausteine und Förderstrecken leuchten rot bei Überlastung. Die dargestellten Ergebnisse im Modelleditor zu Bausteinen und Förderstrecken sind umschaltbar durch den Nutzer (Abb. 6). Je nach den in den Bausteinen hinterlegten Berechnungen sind jedoch nicht immer alle Kenn-größen verfügbar. Die Implementierung des Baukastensystems wurde mit Java (Release 1.5) vorgenommen. Für das Kernsystem wird dabei das in Abbildung 7 dargestellte Klassen-Konzept umgesetzt. Ausgehend von einer allgemeinen Klasse (Object3D) für Visualisierung von und Interaktionen mit grafischen Objekten wurden für Bausteine (AbstractNode) und Förderstrecken (Connection) die jeweiligen Klassen abgelei-tet. Für die Förderstecken ergibt sich dabei eine weitgehend einheitliche Beschreibungsform, die lediglich durch die Parametrierung (Vorlagen in der Förderstrecken-Bibliothek als XML-Datei) auf den konkreten Einsatz im Modell des Materialflusssystems angepasst werden muss. Anders verhält es sich mit den Bausteinen: Durch die mögliche Vielfalt von Bausteinen und den ihnen zu Grunde liegenden Berechnungsverfahren muss es auch eine Vielzahl von Klassen geben. Um jedoch für jeden belie-bigen Baustein den Zugriff (Bereitstellung von Eingangsdaten, Berechnung und Bereitstellung der Ergebnisse) in einer identischen Weise zu gewährleisten, muss es dafür eine nach außen einheitliche Schnittstelle geben. Die Java zu Grunde liegende objektorientierte Programmierung bietet mit dem Konzept der „abstrakten Klasse“ eine Möglichkeit, dies in einfacher Weise zu realisieren. Dazu wird mit AbstractNode quasi eine Vorlage entwi-ckelt, von der alle implementierten Baustein-Klassen abgeleitet sind. AbstractNode selbst enthält alle Methoden, mit denen Baustein-Daten übernommen oder übergeben, die jeweiligen Visualisierungen vorgenommen, die baustein-internen Verbindungen (lokale Transportmatrix) verwaltet und Ein- und Ausgänge mit den zugehörigen Förderstrecken verbunden werden. Die für den Aufruf der eigentlichen Berechnungen in den Bausteinen ver-wendeten Methoden sind deklariert, aber nicht implementiert (sogenannte abstrakte Methoden). Ein Baustein wird von AbstractNode abgeleitet und erbt damit die implementierten Methoden, lediglich die abstrakten Methoden, die die Spezifik des Bausteins ausmachen, sind noch zu implementieren. Um neue Bausteine zu erzeugen, wird Unterstützung in Form eines Bildschirmdialogs angeboten (Abb. 8). Danach sind die entsprechenden Angaben zu den Metadaten, zur Struktur und zur Visualisierung des Bausteins, die Eingangsparameter (Name und Erläuterung) sowie die berechenbaren Ergebnisse (z.B. Auslastung, Quantile der Warteschlangenlänge, aber keine Aussage zu Wartezeiten usw.) anzugeben. Nach Bestätigung der Daten und diversen Syntax- bzw. Semantik-Kontrollen wird der Baustein in der Bibliothek registriert, ein Sourcecode für den neuen Baustein generiert und kompiliert. Der Baustein selbst ist damit formal korrekt und kann sofort verwendet werden, liefert aber noch keine verwertbaren Ergebnisse, weil natürlich die Implementierung des Berechnungsverfahrens selbst noch aussteht. Das muss in einem zweiten Schritt im Rah-men der üblichen Software-Entwicklung nachgeholt werden. Dazu sind die Berechnungsverfahren zu implemen-tieren und die Bausteinschnittstellen zu bedienen. Der generierte Java-Code enthält in den Kommentaren eine Reihe von Hinweisen für den Programmierer, so dass sich problemlos die Schnittstellen des Bausteins program-mieren lassen (Abb. 9). In einem Beispiel werden ein Hochregallager (3 Regalbediengeräte) und zwei Kommissionierplätze durch ein Transportsystem verbunden. Mit der Einlastung von Kommissionieraufträgen werden im Simulationsmodell die entsprechenden Transportaufträge generiert und abgearbeitet (Abb. 10). Dabei können Systemzustände (z.B. Warteschlangen) protokolliert und statistisch ausgewertet werden. Ein entsprechendes Modell für den Baukasten ist in Abbildung 11 dargestellt. Der Vorteil des Baukastensystems liegt selbst bei diesem recht einfachen Beispiel im Zeitvorteil: Für Erstellung und Test des Simulationsmodells und anschließende Simulationsläufe und Auswertungen wird ein Zeitaufwand von ca. 4-5 Stunden benötigt, das Baukastenmodell braucht für Erstellung und korrekte Parametrierung weniger als 0,5 Stunden, die Rechenzeit selbst ist vernachlässigbar gering. Sollte im Ergebnis der Untersuchungen eine Änderung des Materialflusssystems notwendig werden, so führt das im Simulationsmodell teilweise zu erheblichen Änderungen (Abläufe, Steuerungsstrategien, Auswertungen) mit entsprechendem Zeitaufwand. Im Baukasten können dagegen in einfacher Weise zusätzliche Bausteine eingefügt oder vorhandene ersetzt werden durch Bausteine mit geänderter Funktion oder Steuerung. Strukturelle Änderungen am Materialflusssys-tem sind also mit deutlich geringerem Aufwand realisierbar. In [Markwardt2003] werden für mehrere Strukturen von Materialflusskomponenten Fehlerbetrachtungen über die Genauigkeit der mittels neuronaler Netze untersuchten Systeme gegenüber den Simulationsergebnissen vorge-nommen. Danach ergibt sich beispielsweise für das 90%-Quantil der Warteschlange eine Abweichung, die mit 90% Sicherheit kleiner als 0,3 Warteplätze ist. Bei den Variationskoeffizienten des Abgangsstroms betragen die absoluten Abweichungen mit 90% Sicherheit nicht mehr als 0,02 bis 0,05 (in Abhängigkeit vom betrachteten Baustein). Daraus wird die Schlussfolgerung abgeleitet, dass die durch Verknüpfung neuronaler Netze gewonne-nen Aussagen sehr gut mit statistischen Ergebnissen diskreter Simulation übereinstimmen und eine Planungssi-cherheit ermöglichen, die für einen Grobentwurf von Materialflusssystemen weit über die heute gebräuchlichen statischen Berechnungsverfahren hinausgehen. Im konkreten Beispiel wurde die Zahl der Pufferplätze vor den Kommissionierern (Work1 bzw. Work2) zu-nächst auf 3 begrenzt. Die Berechnung im Baukasten ergab dabei in beiden Fällen Fehlermeldungen mit dem Hinweis auf Blockierungen (Abb. 12, links). Diese bestätigten sich auch im Simulationsmodell (Abb. 12, rechts). Nach Vergr��ßerung der Pufferstrecken auf 7 Plätze ist die Blockierungsgefahr auf ein vertretbares Minimum reduziert, und die mit dem Baukasten berechneten Kenngrößen können durch die Simulation prinzipiell bestätigt werden. it dem offenen Baukastensystem ist eine schnelle, einfache, sichere und damit wirtschaftlichere Dimensionie-rung von Materialflusssystemen möglich. Für den Anwender sind sofort statistisch abgesicherte und ausreichend genaue Ergebnisse ohne aufwändige Berechnungen verfügbar, womit sich die Planungsqualität erhöht. Besonde-re Anforderungen an Hard- und Software sind dabei nicht erforderlich. Für die Dimensionierung der einzelnen Bausteine stehen Informationen aus der Bedienungstheorie, Simulati-onswissen und numerische Verfahren direkt und anwendungsbereit zur Verfügung. Es erlaubt eine deutlich vereinfachte Berechnung von statistischen Kenngrößen wie Quantile (statistische Obergrenzen) der Pufferbelegung, Auslastung von Einzelelementen und mittlere Auftragsdurchlaufzeit bei gleichzeitig erhöhter Genauigkeit. Ferner ist das Baukastensystem offen für eine Erweiterung um neue Bausteine, die neue oder spezielle fördertechnische Elemente abbilden oder zusätzliche Informationen liefern können. Da auch komplexe Materialflusssysteme immer wieder aus einer begrenzten Anzahl unterschiedlicher Kompo-nenten bestehen, können durch die Verknüpfung der Einzelbausteine auch Gesamtsysteme abgebildet werden. Die Verknüpfung der Bausteine über eine einheitliche Schnittstelle erlaubt Aussagen über das Verhalten der Gesamtanlage. Bei Einsatz des Baukastensystems sind in einer solchen Verknüpfung jederzeit Parameterände-rungen möglich, deren Folgen sofort sichtbar werden. Die Zeit bis zum Vorliegen gesicherter, ausreichend genauer Ergebnisse wird dadurch drastisch verkürzt. Damit erwächst Variantenuntersuchungen bereits in frühen Planungsphasen neues Potential und kann zum entscheidenden Wettbewerbsvorteil werden.

A documentation generator for (C)LP systems

We describe lpdoc, a tool which generates documentation manuals automatically from one or more logic program source files, written in Ciao, ISO-Prolog, and other (C)LP languages. It is particularly useful for documenting library modules, for which it automatically generates a rich description of the module interface. However, it can also be used quite successfully to document full applications. A fundamental advantage of using lpdoc is that it helps maintaining a true correspondence between the program and its documentation, and also identifying precisely to what versión of the program a given printed manual corresponds. The quality of the documentation generated can be greatly enhanced by including within the program text assertions (declarations with types, modes, etc. ...) for the predicates in the program, and machine-readable comments. One of the main novelties of lpdoc is that these assertions and comments are written using the Ciao system asseriion language, which is also the language of communication between the compiler and the user and between the components of the compiler. This allows a significant synergy among specification, debugging, documentation, optimization, etc. A simple compatibility library allows conventional (C)LP systems to ignore these assertions and comments and treat normally programs documented in this way. The documentation can be generated interactively from emacs or from the command line, in many formats including texinfo, dvi, ps, pdf, info, ascii, html/css, Unix nroff/man, Windows help, etc., and can include bibliographic citations and images, lpdoc can also genérate "man" pages (Unix man page format), nicely formatted plain ASCII "readme" files, installation scripts useful when the manuals are included in software distributions, brief descriptions in html/css or info formats suitable for inclusión in on-line Índices of manuals, and even complete WWW and info sites containing on-line catalogs of documents and software distributions. The lpdoc manual, all other Ciao system manuals, and parts of this paper are generated by lpdoc.

A system for automatically generating documentation for (C)LP programs

We describe lpdoc, a tool which generates documentation manuals automatically from one or more logic program source files, written in ISO-Prolog, Ciao, and other (C)LP languages. It is particularly useful for documenting library modules, for which it automatically generates a rich description of the module interface. However, it can also be used quite successfully to document full applications. A fundamental advantage of using lpdoc is that it helps maintaining a true correspondence between the program and its documentation, and also identifying precisely to what version of the program a given printed manual corresponds. The quality of the documentation generated can be greatly enhanced by including within the program text assertions (declarations with types, modes, etc.) for the predicates in the program, and machine-readable comments. One of the main novelties of lpdoc is that these assertions and comments are written using the Ciao system assertion language, which is also the language of communication between the compiler and the user and between the components of the compiler. This allows a significant synergy among specification, documentation, optimization, etc. A simple compatibility library allows conventional (C)LP systems to ignore these assertions and comments and treat normally programs documented in this way. The documentation can be generated in many formats including texinfo, dvi, ps, pdf, info, html/css, Unix nroff/man, Windows help, etc., and can include bibliographic citations and images. lpdoc can also generate “man” pages (Unix man page format), nicely formatted plain ascii “readme” files, installation scripts useful when the manuals are included in software distributions, brief descriptions in html/css or info formats suitable for inclusion in on-line indices of manuals, and even complete WWW and info sites containing on-line catalogs of documents and software distributions. The lpdoc manual, all other Ciao system manuals, and parts of this paper are generated by lpdoc.

Contribution to multiuser videoconferencing systems based on cloud computing

Multi-user videoconferencing systems offer communication between more than two users, who are able to interact through their webcams, microphones and other components. The use of these systems has been increased recently due to, on the one hand, improvements in Internet access, networks of companies, universities and houses, whose available bandwidth has been increased whilst the delay in sending and receiving packets has decreased. On the other hand, the advent of Rich Internet Applications (RIA) means that a large part of web application logic and control has started to be implemented on the web browsers. This has allowed developers to create web applications with a level of complexity comparable to traditional desktop applications, running on top of the Operating Systems. More recently the use of Cloud Computing systems has improved application scalability and involves a reduction in the price of backend systems. This offers the possibility of implementing web services on the Internet with no need to spend a lot of money when deploying infrastructures and resources, both hardware and software. Nevertheless there are not many initiatives that aim to implement videoconferencing systems taking advantage of Cloud systems. This dissertation proposes a set of techniques, interfaces and algorithms for the implementation of videoconferencing systems in public and private Cloud Computing infrastructures. The mechanisms proposed here are based on the implementation of a basic videoconferencing system that runs on the web browser without any previous installation requirements. To this end, the development of this thesis starts from a RIA application with current technologies that allow users to access their webcams and microphones from the browser, and to send captured data through their Internet connections. Furthermore interfaces have been implemented to allow end users to participate in videoconferencing rooms that are managed in different Cloud provider servers. To do so this dissertation starts from the results obtained from the previous techniques and backend resources were implemented in the Cloud. A traditional videoconferencing service which was implemented in the department was modified to meet typical Cloud Computing infrastructure requirements. This allowed us to validate whether Cloud Computing public infrastructures are suitable for the traffic generated by this kind of system. This analysis focused on the network level and processing capacity and stability of the Cloud Computing systems. In order to improve this validation several other general considerations were taken in order to cover more cases, such as multimedia data processing in the Cloud, as research activity has increased in this area in recent years. The last stage of this dissertation is the design of a new methodology to implement these kinds of applications in hybrid clouds reducing the cost of videoconferencing systems. Finally, this dissertation opens up a discussion about the conclusions obtained throughout this study, resulting in useful information from the different stages of the implementation of videoconferencing systems in Cloud Computing systems. RESUMEN Los sistemas de videoconferencia multiusuario permiten la comunicación entre más de dos usuarios que pueden interactuar a través de cámaras de video, micrófonos y otros elementos. En los últimos años el uso de estos sistemas se ha visto incrementado gracias, por un lado, a la mejora de las redes de acceso en las conexiones a Internet en empresas, universidades y viviendas, que han visto un aumento del ancho de banda disponible en dichas conexiones y una disminución en el retardo experimentado por los datos enviados y recibidos. Por otro lado también ayudó la aparación de las Aplicaciones Ricas de Internet (RIA) con las que gran parte de la lógica y del control de las aplicaciones web comenzó a ejecutarse en los mismos navegadores. Esto permitió a los desarrolladores la creación de aplicaciones web cuya complejidad podía compararse con la de las tradicionales aplicaciones de escritorio, ejecutadas directamente por los sistemas operativos. Más recientemente el uso de sistemas de Cloud Computing ha mejorado la escalabilidad y el abaratamiento de los costes para sistemas de backend, ofreciendo la posibilidad de implementar servicios Web en Internet sin la necesidad de grandes desembolsos iniciales en las áreas de infraestructuras y recursos tanto hardware como software. Sin embargo no existen aún muchas iniciativas con el objetivo de realizar sistemas de videoconferencia que aprovechen las ventajas del Cloud. Esta tesis doctoral propone un conjunto de técnicas, interfaces y algoritmos para la implentación de sistemas de videoconferencia en infraestructuras tanto públicas como privadas de Cloud Computing. Las técnicas propuestas en la tesis se basan en la realización de un servicio básico de videoconferencia que se ejecuta directamente en el navegador sin la necesidad de instalar ningún tipo de aplicación de escritorio. Para ello el desarrollo de esta tesis parte de una aplicación RIA con tecnologías que hoy en día permiten acceder a la cámara y al micrófono directamente desde el navegador, y enviar los datos que capturan a través de la conexión de Internet. Además se han implementado interfaces que permiten a usuarios finales la participación en salas de videoconferencia que se ejecutan en servidores de proveedores de Cloud. Para ello se partió de los resultados obtenidos en las técnicas anteriores de ejecución de aplicaciones en el navegador y se implementaron los recursos de backend en la nube. Además se modificó un servicio ya existente implementado en el departamento para adaptarlo a los requisitos típicos de las infraestructuras de Cloud Computing. Alcanzado este punto se procedió a analizar si las infraestructuras propias de los proveedores públicos de Cloud Computing podrían soportar el tráfico generado por los sistemas que se habían adaptado. Este análisis se centró tanto a nivel de red como a nivel de capacidad de procesamiento y estabilidad de los sistemas. Para los pasos de análisis y validación de los sistemas Cloud se tomaron consideraciones más generales para abarcar casos como el procesamiento de datos multimedia en la nube, campo en el que comienza a haber bastante investigación en los últimos años. Como último paso se ideó una metodología de implementación de este tipo de aplicaciones para que fuera posible abaratar los costes de los sistemas de videoconferencia haciendo uso de clouds híbridos. Finalmente en la tesis se abre una discusión sobre las conclusiones obtenidas a lo largo de este amplio estudio, obteniendo resultados útiles en las distintas etapas de implementación de los sistemas de videoconferencia en la nube.

Estudio preliminar acerca del uso de protocolos y actos comunicativos FIPA en el sistema COMPUTAPLEX

Este trabajo corresponde con la implementación de componentes software dentro de la Plataforma COMPUTAPLEX, la cual tiene como objetivo facilitar a los investigadores la realización de tareas del proceso experimental de ingeniería de software. Uno de los aportes a esta plataforma tecnológica corresponde con el desarrolló de los componentes necesarios para la recuperación de datos experimentales disponibles en diversas fuentes de datos, para ello se hizo uso de un mecanismo capaz de unificar la extracción de información de MySQL, ficheros excel y ficheros SPSS. Con ello diferentes grupos de investigación asociados pueden compartir y tener acceso a repositorios experimentales que se mantienen tanto de manera local como externa. Por otra parte, se ha realizado un estudio de la tecnología de agentes en la que se describe sus definiciones, lenguajes de comunicación, especificación FIPA, JADE como implementación FIPA y parser XML. Además para este trabajo se ha definido e implementado una ontología de comunicación entre agentes, la misma que fue diseñada en la herramienta Protégé. En lo que se refiere al desarrollo de componentes se hizo uso de una amplía variedad de tecnologías que incluye lenguaje de programación Java, framework JADE para el desarrollo de agentes, librería JENA para manejo de ontologías, librería SAXParser para lectura de archivos XML y patrón de diseño Factory. Finalmente se describe la metodología de trabajo utilizada en el proyecto, la cual por medio de la realización de varios ciclos iterativos permitió obtener prototipos que poco a poco fueron cubriendo las necesidades del producto software.----ABSTRACT---- This work relates to the implementation of software components within the platform Computaplex, which aims to enable researchers to conduct experimental software engineering process tasks. One of the contributions to this platform technology corresponds to the development of components which are necessary for the recovery of experimental data available in different data sources, to archive this goal a mechanism able to unify the extraction of information from MySQL, Excel and SPSS files was made. Therefore, associated research groups can share and access experimental repositories that remain both locally and externally. Moreover, it has been conducted a study of agent technology in its definition is described, languages communication, FIPA, JADE and FIPA implementation and XML parser. In addition to this work, it has been defined and implemented an ontology for communication between agents, the same as was designed in the Protégé tool. In what refers to the development of components, a wide range of technologies have been made which includes Java programming language, framework JADE for agent development, JENA library for handling ontologies, SAXParser for reading XML files and Factory design pattern. Finally, describing the work methodology used in this project, which through the implementation of several iterative cycles allowed to obtain prototypes were gradually meeting the needs of the software product.

Contributions to the Resilience Management in the Internet of Things

El auge del "Internet de las Cosas" (IoT, "Internet of Things") y sus tecnologías asociadas han permitido su aplicación en diversos dominios de la aplicación, entre los que se encuentran la monitorización de ecosistemas forestales, la gestión de catástrofes y emergencias, la domótica, la automatización industrial, los servicios para ciudades inteligentes, la eficiencia energética de edificios, la detección de intrusos, la gestión de desastres y emergencias o la monitorización de señales corporales, entre muchas otras. La desventaja de una red IoT es que una vez desplegada, ésta queda desatendida, es decir queda sujeta, entre otras cosas, a condiciones climáticas cambiantes y expuestas a catástrofes naturales, fallos de software o hardware, o ataques maliciosos de terceros, por lo que se puede considerar que dichas redes son propensas a fallos. El principal requisito de los nodos constituyentes de una red IoT es que estos deben ser capaces de seguir funcionando a pesar de sufrir errores en el propio sistema. La capacidad de la red para recuperarse ante fallos internos y externos inesperados es lo que se conoce actualmente como "Resiliencia" de la red. Por tanto, a la hora de diseñar y desplegar aplicaciones o servicios para IoT, se espera que la red sea tolerante a fallos, que sea auto-configurable, auto-adaptable, auto-optimizable con respecto a nuevas condiciones que puedan aparecer durante su ejecución. Esto lleva al análisis de un problema fundamental en el estudio de las redes IoT, el problema de la "Conectividad". Se dice que una red está conectada si todo par de nodos en la red son capaces de encontrar al menos un camino de comunicación entre ambos. Sin embargo, la red puede desconectarse debido a varias razones, como que se agote la batería, que un nodo sea destruido, etc. Por tanto, se hace necesario gestionar la resiliencia de la red con el objeto de mantener la conectividad entre sus nodos, de tal manera que cada nodo IoT sea capaz de proveer servicios continuos, a otros nodos, a otras redes o, a otros servicios y aplicaciones. En este contexto, el objetivo principal de esta tesis doctoral se centra en el estudio del problema de conectividad IoT, más concretamente en el desarrollo de modelos para el análisis y gestión de la Resiliencia, llevado a la práctica a través de las redes WSN, con el fin de mejorar la capacidad la tolerancia a fallos de los nodos que componen la red. Este reto se aborda teniendo en cuenta dos enfoques distintos, por una parte, a diferencia de otro tipo de redes de dispositivos convencionales, los nodos en una red IoT son propensos a perder la conexión, debido a que se despliegan en entornos aislados, o en entornos con condiciones extremas; por otra parte, los nodos suelen ser recursos con bajas capacidades en términos de procesamiento, almacenamiento y batería, entre otros, por lo que requiere que el diseño de la gestión de su resiliencia sea ligero, distribuido y energéticamente eficiente. En este sentido, esta tesis desarrolla técnicas auto-adaptativas que permiten a una red IoT, desde la perspectiva del control de su topología, ser resiliente ante fallos en sus nodos. Para ello, se utilizan técnicas basadas en lógica difusa y técnicas de control proporcional, integral y derivativa (PID - "proportional-integral-derivative"), con el objeto de mejorar la conectividad de la red, teniendo en cuenta que el consumo de energía debe preservarse tanto como sea posible. De igual manera, se ha tenido en cuenta que el algoritmo de control debe ser distribuido debido a que, en general, los enfoques centralizados no suelen ser factibles a despliegues a gran escala. El presente trabajo de tesis implica varios retos que conciernen a la conectividad de red, entre los que se incluyen: la creación y el análisis de modelos matemáticos que describan la red, una propuesta de sistema de control auto-adaptativo en respuesta a fallos en los nodos, la optimización de los parámetros del sistema de control, la validación mediante una implementación siguiendo un enfoque de ingeniería del software y finalmente la evaluación en una aplicación real. Atendiendo a los retos anteriormente mencionados, el presente trabajo justifica, mediante una análisis matemático, la relación existente entre el "grado de un nodo" (definido como el número de nodos en la vecindad del nodo en cuestión) y la conectividad de la red, y prueba la eficacia de varios tipos de controladores que permiten ajustar la potencia de trasmisión de los nodos de red en respuesta a eventuales fallos, teniendo en cuenta el consumo de energía como parte de los objetivos de control. Así mismo, este trabajo realiza una evaluación y comparación con otros algoritmos representativos; en donde se demuestra que el enfoque desarrollado es más tolerante a fallos aleatorios en los nodos de la red, así como en su eficiencia energética. Adicionalmente, el uso de algoritmos bioinspirados ha permitido la optimización de los parámetros de control de redes dinámicas de gran tamaño. Con respecto a la implementación en un sistema real, se han integrado las propuestas de esta tesis en un modelo de programación OSGi ("Open Services Gateway Initiative") con el objeto de crear un middleware auto-adaptativo que mejore la gestión de la resiliencia, especialmente la reconfiguración en tiempo de ejecución de componentes software cuando se ha producido un fallo. Como conclusión, los resultados de esta tesis doctoral contribuyen a la investigación teórica y, a la aplicación práctica del control resiliente de la topología en redes distribuidas de gran tamaño. Los diseños y algoritmos presentados pueden ser vistos como una prueba novedosa de algunas técnicas para la próxima era de IoT. A continuación, se enuncian de forma resumida las principales contribuciones de esta tesis: (1) Se han analizado matemáticamente propiedades relacionadas con la conectividad de la red. Se estudia, por ejemplo, cómo varía la probabilidad de conexión de la red al modificar el alcance de comunicación de los nodos, así como cuál es el mínimo número de nodos que hay que añadir al sistema desconectado para su re-conexión. (2) Se han propuesto sistemas de control basados en lógica difusa para alcanzar el grado de los nodos deseado, manteniendo la conectividad completa de la red. Se han evaluado diferentes tipos de controladores basados en lógica difusa mediante simulaciones, y los resultados se han comparado con otros algoritmos representativos. (3) Se ha investigado más a fondo, dando un enfoque más simple y aplicable, el sistema de control de doble bucle, y sus parámetros de control se han optimizado empleando algoritmos heurísticos como el método de la entropía cruzada (CE, "Cross Entropy"), la optimización por enjambre de partículas (PSO, "Particle Swarm Optimization"), y la evolución diferencial (DE, "Differential Evolution"). (4) Se han evaluado mediante simulación, la mayoría de los diseños aquí presentados; además, parte de los trabajos se han implementado y validado en una aplicación real combinando técnicas de software auto-adaptativo, como por ejemplo las de una arquitectura orientada a servicios (SOA, "Service-Oriented Architecture"). ABSTRACT The advent of the Internet of Things (IoT) enables a tremendous number of applications, such as forest monitoring, disaster management, home automation, factory automation, smart city, etc. However, various kinds of unexpected disturbances may cause node failure in the IoT, for example battery depletion, software/hardware malfunction issues and malicious attacks. So, it can be considered that the IoT is prone to failure. The ability of the network to recover from unexpected internal and external failures is known as "resilience" of the network. Resilience usually serves as an important non-functional requirement when designing IoT, which can further be broken down into "self-*" properties, such as self-adaptive, self-healing, self-configuring, self-optimization, etc. One of the consequences that node failure brings to the IoT is that some nodes may be disconnected from others, such that they are not capable of providing continuous services for other nodes, networks, and applications. In this sense, the main objective of this dissertation focuses on the IoT connectivity problem. A network is regarded as connected if any pair of different nodes can communicate with each other either directly or via a limited number of intermediate nodes. More specifically, this thesis focuses on the development of models for analysis and management of resilience, implemented through the Wireless Sensor Networks (WSNs), which is a challenging task. On the one hand, unlike other conventional network devices, nodes in the IoT are more likely to be disconnected from each other due to their deployment in a hostile or isolated environment. On the other hand, nodes are resource-constrained in terms of limited processing capability, storage and battery capacity, which requires that the design of the resilience management for IoT has to be lightweight, distributed and energy-efficient. In this context, the thesis presents self-adaptive techniques for IoT, with the aim of making the IoT resilient against node failures from the network topology control point of view. The fuzzy-logic and proportional-integral-derivative (PID) control techniques are leveraged to improve the network connectivity of the IoT in response to node failures, meanwhile taking into consideration that energy consumption must be preserved as much as possible. The control algorithm itself is designed to be distributed, because the centralized approaches are usually not feasible in large scale IoT deployments. The thesis involves various aspects concerning network connectivity, including: creation and analysis of mathematical models describing the network, proposing self-adaptive control systems in response to node failures, control system parameter optimization, implementation using the software engineering approach, and evaluation in a real application. This thesis also justifies the relations between the "node degree" (the number of neighbor(s) of a node) and network connectivity through mathematic analysis, and proves the effectiveness of various types of controllers that can adjust power transmission of the IoT nodes in response to node failures. The controllers also take into consideration the energy consumption as part of the control goals. The evaluation is performed and comparison is made with other representative algorithms. The simulation results show that the proposals in this thesis can tolerate more random node failures and save more energy when compared with those representative algorithms. Additionally, the simulations demonstrate that the use of the bio-inspired algorithms allows optimizing the parameters of the controller. With respect to the implementation in a real system, the programming model called OSGi (Open Service Gateway Initiative) is integrated with the proposals in order to create a self-adaptive middleware, especially reconfiguring the software components at runtime when failures occur. The outcomes of this thesis contribute to theoretic research and practical applications of resilient topology control for large and distributed networks. The presented controller designs and optimization algorithms can be viewed as novel trials of the control and optimization techniques for the coming era of the IoT. The contributions of this thesis can be summarized as follows: (1) Mathematically, the fault-tolerant probability of a large-scale stochastic network is analyzed. It is studied how the probability of network connectivity depends on the communication range of the nodes, and what is the minimum number of neighbors to be added for network re-connection. (2) A fuzzy-logic control system is proposed, which obtains the desired node degree and in turn maintains the network connectivity when it is subject to node failures. There are different types of fuzzy-logic controllers evaluated by simulations, and the results demonstrate the improvement of fault-tolerant capability as compared to some other representative algorithms. (3) A simpler but more applicable approach, the two-loop control system is further investigated, and its control parameters are optimized by using some heuristic algorithms such as Cross Entropy (CE), Particle Swarm Optimization (PSO), and Differential Evolution (DE). (4) Most of the designs are evaluated by means of simulations, but part of the proposals are implemented and tested in a real-world application by combining the self-adaptive software technique and the control algorithms which are presented in this thesis.

Software architecture implementation based on OpenSim

One of the objectives of the European Higher Education Area is the promotion of collaborative and informal learning through the implementation of educational practices. 3D virtual environments become an ideal space for such activities. On the other hand, the problem of financing in Spanish universities has led to the search for new ways to optimize available resources. The Technical University of Madrid requires the use of laboratories which due to their dangerousness, duration or control of the developed processes are difficult to perform in real life. For this reason, we have developed several 3D laboratories in virtual environment. The laboratories are built on open source platform OpenSim. In this paper it is exposed the use of the OpenSim platform for these new teaching experiences and the new design of the software architecture. This architecture requires the adaptation of the platform to the needs of the users and the different laboratories of our University. We will explain the structure of the implemented architecture and the process of creating and configuring it. The proposed architecture is decentralized, each laboratory is housed in different an educational center. The architecture adds several services, among others, the creation and management of users automated, communication between external services and platforms in different program languages. Therefore, we achieve improving the user experience and rising the functionalities of laboratories.

Dificultades en el aprendizaje del diseño de software orientado a objetos: un estudio cualitativo longitudinal

Las compañías de desarrollo de software buscan reducir costes a través del desarrollo de diseños que permitan: a) facilidad en la distribución del trabajo de desarrollo, con la menor comunicación de las partes; b) modificabilidad, permitiendo realizar cambios sobre un módulo sin alterar las otras partes y; c) comprensibilidad, permitiendo estudiar un módulo del sistema a la vez. Estas características elementales en el diseño de software se logran a través del diseño de sistemas cuasi-descomponibles, cuyo modelo teórico fue introducido por Simon en su búsqueda de una teoría general de los sistemas. En el campo del diseño de software, Parnas propone un camino práctico para lograr sistemas cuasi-descomponibles llamado el Principio de Ocultación de Información. El Principio de Ocultación de Información es un criterio diferente de descomposición en módulos, cuya implementación logra las características deseables de un diseño eficiente a nivel del proceso de desarrollo y mantenimiento. El Principio y el enfoque orientado a objetos se relacionan debido a que el enfoque orientado a objetos facilita la implementación del Principio, es por esto que cuando los objetos empiezan a tomar fuerza, también aparecen paralelamente las dificultades en el aprendizaje de diseño de software orientado a objetos, las cuales se mantienen hasta la actualidad, tal como se reporta en la literatura. Las dificultades en el aprendizaje de diseño de software orientado a objetos tiene un gran impacto tanto en las aulas como en la profesión. La detección de estas dificultades permitirá a los docentes corregirlas o encaminarlas antes que éstas se trasladen a la industria. Por otro lado, la industria puede estar advertida de los potenciales problemas en el proceso de desarrollo de software. Esta tesis tiene como objetivo investigar sobre las dificultades en el diseño de software orientado a objetos, a través de un estudio empírico. El estudio fue realizado a través de un estudio de caso cualitativo, que estuvo conformado por tres partes. La primera, un estudio inicial que tuvo como objetivo conocer el entendimiento de los estudiantes alrededor del Principio de Ocultación de Información antes de que iniciasen la instrucción. La segunda parte, un estudio llevado a cabo a lo largo del período de instrucción con la finalidad de obtener las dificultades de diseño de software y su nivel de persistencia. Finalmente, una tercera parte, cuya finalidad fue el estudio de las dificultades esenciales de aprendizaje y sus posibles orígenes. Los participantes de este estudio pertenecieron a la materia de Software Design del European Master in Software Engineering de la Escuela Técnica Superior de Ingenieros Informáticos de la Universidad Politécnica de Madrid. Los datos cualitativos usados para el análisis procedieron de las observaciones en las horas de clase y exposiciones, entrevistas realizadas a los estudiantes y ejercicios enviados a lo largo del período de instrucción. Las dificultades presentadas en esta tesis en sus diferentes perspectivas, aportaron conocimiento concreto de un estudio de caso en particular, realizando contribuciones relevantes en el área de diseño de software, docencia, industria y a nivel metodológico. ABSTRACT The software development companies look to reduce costs through the development of designs that will: a) ease the distribution of development work with the least communication between the parties; b) changeability, allowing to change a module without disturbing the other parties and; c) understandability, allowing to study a system module at a time. These basic software design features are achieved through the design of quasidecomposable systems, whose theoretical model was introduced by Simon in his search for a general theory of systems. In the field of software design, Parnas offers a practical way to achieve quasi-decomposable systems, called The Information Hiding Principle. The Information Hiding Principle is different criterion for decomposition into modules, whose implementation achieves the desirable characteristics of an efficient design at the development and maintenance level. The Principle and the object-oriented approach are related because the object-oriented approach facilitates the implementation of The Principle, which is why when objects begin to take hold, also appear alongside the difficulties in learning an object-oriented software design, which remain to this day, as reported in the literature. Difficulties in learning object-oriented software design has a great impact both in the classroom and in the profession. The detection of these difficulties will allow teachers to correct or route them before they move to the industry. On the other hand, the industry can be warned of potential problems related to the software development process. This thesis aims to investigate the difficulties in learning the object-oriented design, through an empirical study. The study was conducted through a qualitative case study, which consisted of three parts. The first, an initial study was aimed to understand the knowledge of the students around The Information Hiding Principle before they start the instruction. The second part, a study was conducted during the entire period of instruction in order to obtain the difficulties of software design and their level of persistence. Finally, a third party, whose purpose was to study the essential difficulties of learning and their possible sources. Participants in this study belonged to the field of Software Design of the European Master in Software Engineering at the Escuela Técnica Superior de Ingenieros Informáticos of Universidad Politécnica de Madrid. The qualitative data used for the analysis came from the observations in class time and exhibitions, performed interviews with students and exercises sent over the period of instruction. The difficulties presented in this thesis, in their different perspectives, provided concrete knowledge of a particular case study, making significant contributions in the area of software design, teaching, industry and methodological level.

A molecular mechanism for signaling between seven-transmembrane receptors: evidence for a redistribution of G proteins

Although activation of one seven-transmembrane receptor can influence the response of a separate seven-transmembrane receptor, e.g., the phenomenon of synergism, the underlying mechanism(s) for this signaling process is unclear. The present study investigated communication between two receptors that exhibit classical synergism, e.g., human platelet thrombin and thromboxane A2 receptors. Activation of thrombin receptors caused an increase in ligand affinity of thromboxane A2 receptors. This effect (i) was shown to be specific, since a similar increase in ligand affinity was not caused by ADP or A23187; (ii) did not require cytosolic components, e.g., kinases, proteases, phosphatases, etc., because it occurred in isolated platelet membranes; (iii) was G protein-mediated because it was blocked by an Gαq C terminus antibody; and (iv) was associated with a net increase in Gαq coupling to thromboxane A2 receptors. Collectively, these data provide evidence that seven-transmembrane receptors that share a common Gα subunit can communicate with each other via a redistribution of their G proteins. Thus, activation of thrombin receptors increases Gαq association with thromboxane A2 receptors thereby shifting them to a higher affinity state. This signaling phenomenon, which modulates receptor-ligand affinity, may serve as a molecular mechanism for cellular adaptive processes such as synergism.

JRNL: Journal Retention and Needs Listing — A Software Tool for Managing Print Journal Archives

The Journal Retention and Needs Listing (JRNL) program: 1) allows libraries to expose lists of print journals for which they have made retention commitments; 2) express needs (or gaps) in their holdings; and 3) communicate offers to fill the gaps in other participating libraries’ holdings. Multiple library consortia and their member libraries use JRNL to facilitate communication between library staff to identify holding commitments, fill gaps, and guide deselection decisions. JRNL is commonly developed and governed by the participating consortia. Currently, those consortia are the Florida Academic Repository (FLARE), the Association of Southeastern Research Libraries (ASERL)/Washington Research Library Consortium (WRLC), and the Western Regional Storage Trust (WEST).

The Virtual Interactive Relationship Between BIM Project Teams: Effective Communication to aid Collaboration in the Design Process

Building Information Modelling (BIM) provides a shared source of information about a built asset, which creates a collaborative virtual environment for project teams. Literature suggests that to collaborate efficiently, the relationship between the project team is based on sympathy, obligation, trust and rapport. Communication increases in importance when working collaboratively but effective communication can only be achieved when the stakeholders are willing to act, react, listen and share information. Case study research and interviews with Architecture, Engineering and Construction (AEC) industry experts suggest that synchronous face-to-face communication is project teams’ preferred method, allowing teams to socialise and build rapport, accelerating the creation of trust between the stakeholders. However, virtual unified communication platforms are a close second-preferred option for communication between the teams. Effective methods for virtual communication in professional practice, such as virtual collaboration environments (CVE), that build trust and achieve similar spontaneous responses as face-to-face communication, are necessary to face the global challenges and can be achieved with the right people, processes and technology. This research paper investigates current industry methods for virtual communication within BIM projects and explores the suitability of avatar interaction in a collaborative virtual environment as an alternative to face-to-face communication to enhance collaboration between design teams’ professional practice on a project. Hence, this paper presents comparisons between the effectiveness of these communication methods within construction design teams with results of further experiments conducted to test recommendations for more efficient methods for virtual communication to add value in the workplace between design teams.

An approach to specifying software frameworks

A framework is a reusable design that requires software components to function. To instantiate a framework, a software engineer must provide the software components required by the framework. To do this effectively, the framework-component interfaces must be specified so the software engineer knows what assumptions the framework makes about the components, and so the components can be verified against these assumptions. This paper presents an approach to specifying software frameworks. The approach involves the specification of the framework’s syntax, semantics, and the interfaces between the framework and its components. The approach is demonstrated with a simple case study.