<?xml version="1.0" encoding="UTF-8"?><rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel rdf:about="http://dl.gi.de/handle/20.500.12116/39445">
<title>Modellierung 2001 (LNI P001)</title>
<link>http://dl.gi.de/handle/20.500.12116/39445</link>
<description/>
<items>
<rdf:Seq>
<rdf:li rdf:resource="http://dl.gi.de/handle/20.500.12116/30727"/>
<rdf:li rdf:resource="http://dl.gi.de/handle/20.500.12116/30725"/>
<rdf:li rdf:resource="http://dl.gi.de/handle/20.500.12116/30726"/>
<rdf:li rdf:resource="http://dl.gi.de/handle/20.500.12116/30723"/>
</rdf:Seq>
</items>
<dc:date>2026-07-21T13:27:55Z</dc:date>
</channel>
<item rdf:about="http://dl.gi.de/handle/20.500.12116/30727">
<title>Eine Orthosprache zur natürlichsprachlichen Beschreibung von dynamischen Objektmodellen</title>
<link>http://dl.gi.de/handle/20.500.12116/30727</link>
<description>Eine Orthosprache zur natürlichsprachlichen Beschreibung von dynamischen Objektmodellen
Sandmann, Carina
Engels, Gregor; Oberweis, Andreas; Zündorf, Albert
Die 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.
</description>
<dc:date>2001-01-01T00:00:00Z</dc:date>
</item>
<item rdf:about="http://dl.gi.de/handle/20.500.12116/30725">
<title>COSIMAC – Ein Referenzmodell zur Gefechtssimulation</title>
<link>http://dl.gi.de/handle/20.500.12116/30725</link>
<description>COSIMAC – Ein Referenzmodell zur Gefechtssimulation
Hofmann, Marko
Engels, Gregor; Oberweis, Andreas; Zündorf, Albert
Referenzmodelle 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.
</description>
<dc:date>2001-01-01T00:00:00Z</dc:date>
</item>
<item rdf:about="http://dl.gi.de/handle/20.500.12116/30726">
<title>Dependency charts as a means to model inter-scenario dependencies – Depicting and managing dependencies between scenarios</title>
<link>http://dl.gi.de/handle/20.500.12116/30726</link>
<description>Dependency charts as a means to model inter-scenario dependencies – Depicting and managing dependencies between scenarios
Ryser, Johannes; Glinz, Martin
Engels, Gregor; Oberweis, Andreas; Zündorf, Albert
Scenarios/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.
</description>
<dc:date>2001-01-01T00:00:00Z</dc:date>
</item>
<item rdf:about="http://dl.gi.de/handle/20.500.12116/30723">
<title>Modeling and implementation of multirate control applications with TargetLink</title>
<link>http://dl.gi.de/handle/20.500.12116/30723</link>
<description>Modeling and implementation of multirate control applications with TargetLink
Homburg, Carsten
Engels, Gregor; Oberweis, Andreas; Zündorf, Albert
The software development for embedded systems is increasingly being done with the help of simulation tools and block diagram specifications. MATLAB, Simulink, and Stateflow are well accepted products in this area [Ma00]. Production code generators like TargetLink [Ds00] are used to turn such graphical specifications of real-time control algorithms into a highly efficient, readable and reliable C code that fits into an Electronic Control Unit (ECU). When this technique was first introduced, users started with pilot projects to gain experience with automatic code generation. The model covered only relatively small parts (features) of the whole control system, for example, the idle speed control of an engine. Typically, there was only a single sample rate, and the code was generated for each operating system task separately. The users had to integrate the auto-generated code into the existing real-time kernel on their ECUs manually. This contribution presents the TargetLink approach to the modeling and implementation of multirate Simulink models [KST01]: The function developer creates a Simulink/Stateflow model containing all the features that have to be implemented. This model concentrates on the control algorithms; implementation aspects are not taken into ac- count. In the next step the control algorithms have to be implemented. The functional model is automatically converted into a TargetLink implementation model. This conversion process is bidirectional. TargetLink provides a special block set for the specification of implementation aspects. The software engineer can make all the settings for the implementation within the blocks. Finally, production-ready code including the RTOS configuration for the OSEK [Os00] real-time operating system family is automatically generated out of the TargetLink implementation model. The presented approach is based on quasi-standards in the automotive industry (i.e., Simulink, OSEK, C). The Simulink block diagram as the modeling basis holds all the necessary information from top-level function development down to the ECU implementation, providing a system specification that is executable in all development phases. Task separation and inter-task communication can be specified with the help of special blocks for operating system support. This allows full integration of the OSEK configuration tools and the Simu link/TargetLink model.
</description>
<dc:date>2001-01-01T00:00:00Z</dc:date>
</item>
</rdf:RDF>
