Auflistung Modellierung 2001 (LNI P001) nach Erscheinungsdatum
1 - 10 von 18
Treffer pro Seite
Sortieroptionen
- KonferenzbeitragDomänenmodellierung und Information-Brokering(Modellierung 2001, 2001) Nick, AchimDie Informationsschwemme im WWW und die steigende Bedeutung von Information als Produktionsfaktor motivieren die Notwendigkeit für Information-Brokering. Information- Broker vermitteln zwischen Informationsanbietern und Informationskonsumenten. Broker’s Lounge ist eine Umgebung die den gesamten Information-Brokeringprozeß unterstützt. Zentraler Qualitätsfaktor für Information-Brokering ist ein Domänenmodell. Das Domänenmodell beschreibt die Inhalte, mit denen der Broker handelt und ist unterteilt in Typen- und Inhaltsebene. Dies erlaubt die Anpassung des Domänenmodells an verschiedene Domänen. Das Domänenmodell kann durch die Einführung von Kategorien und Kategoriesystemen weiter strukturiert werden. Kategorien klassifizieren Konzepte. Konzepte sind die Informationen, an denen die Informationskonsumenten interessiert sind und mit denen der Broker handelt. Die Kategorisierung (von Konzepten) erleichtert die Abbildung konkreter Kundeninteressen auf das Domänenmodell. Die Verantwortlichkeiten für das Domänenmodell können in die Administration der Typenebene, die Administration der Kategorien und die Kategorisierung und Erstellung von Konzepten aufgeteilt werden.
- KonferenzbeitragOffene Systemplattformen in heterogenen Automatisierungssystemen für die Prozeßmodellierung(Modellierung 2001, 2001) Langer, Michael; Vogel, Birgit; Heidepriem, JürgenDie Betreiber von Produktionsanlagen aller Branchen sind aus wirtschaftlichen Gründen vielfach gezwungen, hochwertige Automatisierungssysteme einzusetzen. Es entsteht hierbei Bedarf nach Werkzeugen, die es gestatten, komplexe Produktionsabläufe auf Rechnern abzubilden und mit Hilfe mathematischer Modelle die Prozessführung zu optimieren. Um in der industriellen Anwendung breiten Einsatz zu ermöglichen, müssen trotz der Vielzahl der Methoden z.B. aus dem Bereich der Computational Intelligence (CI) und der zunehmenden Komplexität der abzubildenden Prozesse, Softwarewerkzeuge eingesetzt werden, die es ermöglichen, individuelle mathematische Lösungsansätze mit vertretbarem Aufwand umzusetzen. Die Möglichkeit zur schnellen Durchführung von Datenanalyse, Modellbildung, Simulation und anschließender Optimierung sind ebenso Kernforderung wie die leichte Integration des Modellrechners in ein heterogenes Netzwerk. Das Softwaresystem MATLAB/ SIMULINK1 kommt dieser Forderug nach und gestattet es, auf einer Plattform betriebssystemunabhängig mit Hilfe unterschiedlichster Tool- boxen komplexe Prozesse abzubilden. Dieser Beitrag beschreibt die Modellierung von chemischen-, physikalischen- und metallurgischen Vorgängen beim Sintern von Eisenerzen und deren Einflußnahme auf qualitätsbestimmende Zielgrößen mit Hilfe eines Neuro-Fuzzy Inferenz Systems mit dem Ziel die Betriebsführung an einer Bandsinteranlage zu optimieren. Der Sinterprozeß steht hier stellvertretend für eine Klasse von stark totzeitbehafteten Prozessen bei denen eine kontinuierliche Qualitätsüberwachung nicht möglich ist. Weitere Musterprozesse dieser Klasse sind Drehrohröfen in der Kalk- und Zementindustrie, die Span- und Faserplattenherstellung in der Holzindustrie, Pflanzen-Wachstumsprozesse in Gewächshäusern und zahlreiche weitere industrielle Prozesse. Die für den Sinterprozeß exemplarisch vorgestellten Modellierungsmethoden auf der offenen Systemplattform Matlab/ Simulink sind auch auf Prozesse dieser Klasse anwendbar.
- KonferenzbeitragNew type checking rules for OCL expressions(Modellierung 2001, 2001) Schürr, AndyThe Object Constraint Language OCL is an integral part of UML, the Unified Modeling Language standard. It has been added to Rational’s UML core as a logic-based sublanguage for the definition of integrity constraints (invariants) on class diagrams as well as for the definition of pre- and postconditions of operations. Despite of the fact that OCL is called a statically typed language its type checking rules are not precisely (enough) defined in the UML standard version 1.3. Furthermore, they have certain deficiencies concerning the treatment of collection manipulating operations. This paper sketches three different approaches for the definition of modified OCL type checking rules. These proposals are based on our experiences with the design of a rather similar constraint language that is part of the graph transformation language PROGRES.
- KonferenzbeitragAutomatische Prozessmodellgenerierung mit SpearmintTM/EPG basierend auf dem Referenzmodell des ISO/IEC TR 15504 Standards(Modellierung 2001, 2001) Hamann, Dirk; Becker-Kornstaedt, UlrikeWesentliche Komponenten bei Prozessverbesserungspro- grammen sind Prozessmodelle. Obwohl Assessments (beispielsweise gemäß dem Referenzmodell des ISO/IEC TR 15504) oft der Auslöser für Prozessverbesserungsprogramme sind, geht die in den Assessments gesammelte Information verloren und steht nicht mehr zur Erstellung von Prozessmodellen zur Verfügung. Dies hat im wesentlichen zwei Gründe: Zum einen gibt es generell kaum Werkzeugunterstützung bei der Durchführung von Assessments. Zum anderen fehlt die Möglichkeit, diejenigen Informationen die für die Assessments bereits erfasst wurden, konsistent zur Erstellung von Prozessmodellen zu verwenden. Der vorliegende Beitrag stellt einen integrierten Ansatz vor, der zum einen die Durchführung von Assessments unterstützt und zum anderen ermöglicht, die Ergebnisse des Assessment weiterhin zur Erstellung von Prozessmodellen mittels Prozessmodellierungswerkzeug zu nutzen.
- KonferenzbeitragEine Orthosprache zur natürlichsprachlichen Beschreibung von dynamischen Objektmodellen(Modellierung 2001, 2001) Sandmann, CarinaDie Kommunikation zwischen Software-Entwickler und Anwender ist für das Gelingen eines Softwareprojektes entscheidend. Dabei besteht im Allgemeinen das Problem, dass die vom Entwickler angefertigten Spezifikationen für den Anwender nicht verständlich sind. Im Rahmen dieses Beitrags wird ein Ansatz vorgestellt, wie die sprachliche Lücke zwischen Software-Entwickler und Anwender durch den Einsatz einer reglementierten Sprache, einer sog. Orthosprache, geschlossen werden kann. Dabei handelt es sich um eine normierte Fachsprache, die auf der Umgangssprache basiert und so eine hohe Benutzerakzeptanz erreicht. Am Beispiel der objektorientierten Verhaltensmodellierung mit Statecharts wird eine Orthogrammatik entwickelt, die geeignete Satzbildungsregeln zur Erstellung orthosprachlicher Aussagen über das Verhalten von Objekten enthält.
- KonferenzbeitragCOSIMAC – Ein Referenzmodell zur Gefechtssimulation(Modellierung 2001, 2001) Hofmann, MarkoReferenzmodelle werden als Hilfsmittel bei der Modellbildung für Simulationssysteme immer wichtiger. Sie verheißen eine schnellere und kostengünstigere Modellherstellung. Mit dem Gefechtssimulationssystem (GSS) COSIMAC (Combat Simulation System with Automated Control) wurde der Versuch gemacht, Vorgaben für militärische Simulationssysteme zu entwickeln. Im Mittelpunkt dieser Vorgaben steht ein Schichtenkonzept für die Modellierung konkreter Objekte (Waffensysteme), des Geländes und der militärischen Führungsstrukturen. Die Vorgaben beruhen im Wesentlichen auf der Trennung der Modellierung technischer Aspekte eines Gefechtes und seiner Führung (Steuerung). Im COSIMAC-Projekt wird die Entwicklung von Modellen angestrebt, die zur Untersuchung der brisanten Frage dienen, inwieweit menschliche militärische Führer zukünftig durch Automaten ersetzt werden können. In diesem Beitrag wird der statische An- teil des COSIMAC-Referenzmodells vorgestellt.
- KonferenzbeitragDependency charts as a means to model inter-scenario dependencies – Depicting and managing dependencies between scenarios(Modellierung 2001, 2001) Ryser, Johannes; Glinz, MartinScenarios/use cases have gained wide-spread use over the last couple of years. In software engineering they are mainly used to capture requirements and specify a system. Many software engineering approaches, most notably the UML (Unified Modeling Language [RJB99]), use some notion of scenario to support requirements elicitation and to provide a means for improved communication between software engineers, customers and users, and for enhanced user integration in the software development process. Yet prominent and renowned approaches like the UML lack a concept for modeling dependencies and relations between scenarios and offer only little support for the description and management of scenarios and of inter-scenario relationships. However, dependencies between scenarios are common, in fact dependencies between scenarios occur in any software development project of reasonable size. The existence of dependencies among scenarios needs to be perceived, acknowledged and accepted, they have to be captured and modeled to fully specify and better understand the system, and their impact on system modeling, on design, implementation and on testing needs to be recognized. In this paper we argue that dependencies among scenarios play too important a role in the software development process to omit them from system models and not to consciously consider them in analysis, design and testing. Therefore, we introduce a new kind of chart and a notation to model dependencies among scenarios. We discuss briefly the reasons why a new kind of chart is needed. An example of a dependency chart is presented.
- KonferenzbeitragModelling and simulation of a material flow system(Modellierung 2001, 2001) Nickel, Ulrich A.; Niere, Jörg
- KonferenzbeitragApplicability of the Object Constraint Language (OCL) in commercial software development for vehicle routing and scheduling software(Modellierung 2001, 2001) Wendorff, PeterModels are important artefacts that support human understan- ding and communication. Often software development involves specialists from a variety of fields, e.g. mathematicians, engineers, economists, software designers, and programmers. This may result in different models, and communication accross discipline boundaries requires to establish links between these models. In this paper we investigate this issue in the case of software development for vehicle routing and scheduling software. We concentrate on three artefacts: a mathematical specification of requirements, an object-oriented software design, and program code written in Java. Obviously these artefacts do not exist in isolation during software development. We demonstrate how the Object Constraint Language can be used to establish links between these three artefacts.
- KonferenzbeitragModellierung in der Ausbildung (von Mathematikern / Informatikern?) – Positionspapier(Modellierung 2001, 2001) Knauer, Ulrich