WO2004090756A2 - Verfahren und anordnung zur performanzvorhersage eines informationstechnischen systems - Google Patents

Verfahren und anordnung zur performanzvorhersage eines informationstechnischen systems Download PDF

Info

Publication number
WO2004090756A2
WO2004090756A2 PCT/EP2004/001168 EP2004001168W WO2004090756A2 WO 2004090756 A2 WO2004090756 A2 WO 2004090756A2 EP 2004001168 W EP2004001168 W EP 2004001168W WO 2004090756 A2 WO2004090756 A2 WO 2004090756A2
Authority
WO
WIPO (PCT)
Prior art keywords
prototype
performance
flow structure
program flow
code
Prior art date
Application number
PCT/EP2004/001168
Other languages
English (en)
French (fr)
Other versions
WO2004090756A3 (de
Inventor
Andreas Hennig
Anja Hentschel
James Tyack
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2004090756A2 publication Critical patent/WO2004090756A2/de
Publication of WO2004090756A3 publication Critical patent/WO2004090756A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design

Definitions

  • the invention relates to a method and an arrangement in which the performance, that is to say, for example, the response time, the capacity, the scalability and the overload tolerance, of an information technology system (IT system) is predicted.
  • IT system information technology system
  • the object on which the invention is based is now to avoid the disadvantages mentioned above and to provide a method and an arrangement for early and as reliable as possible performance prediction for IT systems / products, "early" here already meaning in the design phase.
  • the invention essentially consists in the fact that reliable tests are already carried out in the design phase by automatically generating a comprehensive performance prototype in the real target environment of the system.
  • the System design in a special notation, for example in UML, enriched with important performance information.
  • a generator program then automatically generates the source code of the components involved, which are then transferred to the respective target platforms and systems and activated there (deployment).
  • the generated prototypes correspond to the future system at least in terms of behavior, resource load and performance - but not necessarily in terms of the content of the system responses.
  • test scenarios can be optionally generated with which the finished prototype system can be tested.
  • the main advantage of the invention lies in the automatic, fast, flexible, efficient and consistent generation of a comprehensive prototype, which would be impossible with manual prototypes. This enables an early and integrated design of hardware and software and thus reduces the risks costs and time of a certain system / product development.
  • FIG. 1 shows an overview picture to explain the invention
  • FIG. 2 shows an image to explain the simulation of a workflow in a network computer
  • FIG. 3 shows a code example belonging to FIG. 2
  • FIG. 4 shows a representation to explain a corresponding client-server communication and to emulate the corresponding workflow in the server
  • FIG. 5 shows a model of a more complicated communication scenario to further explain the method according to the invention
  • Figure 6 is a table for a more detailed explanation of characteristic load programs.
  • FIG. 1 shows an overall view to explain the
  • a model M in a given notation provides an input variable for a prototype generator PG, which in turn generates prototype codes 1, 2 ... n for different platforms with the help of program learners for resource consumption types RVA, which then
  • Application servers AS or servlet machines SE are deployed (deployed), which in turn may access databases DB.
  • the prototype generator PG can optionally also generate load test scenarios LTS with test client computers TC in order to simulate a load situation with, for example, a plurality of user computers which have a respective user profile.
  • the method and the arrangement according to the invention can advantageously be used to simulate and evaluate, for example, data network applications, this being an “in vivo” simulation, ie a combination of components that have already been implemented and simulated ”and wherein the simulation takes place on real hardware or in the real environment.
  • this being an “in vivo” simulation, ie a combination of components that have already been implemented and simulated ”and wherein the simulation takes place on real hardware or in the real environment.
  • the parts generated by the prototype generator PG which simulate parts that are not yet available, are indicated by hatching.
  • the notation of the model is ideally done in standard modeling tools of software development, on the one hand to use their possibilities and distribution, and on the other hand to be integrated into the development process.
  • the notation should be simple and intuitive enough to be used in the normal software development process without much effort. At the same time the relevant performance information can be clearly stored.
  • Modeling languages for example SDL or MSC, would also be suitable.
  • a "workflow" based notation is used, i.e. Processes are defined and simulated, not necessarily internal decision algorithms.
  • An intermediate code can be generated in Java from the UML representation, for example via XML (extensible markup language), which is then converted into the corresponding target platform.
  • the notation and the generator PG should advantageously be able to determine the performance information from tools from different manufacturers and the contents of the notation must be merged from different diagrams and represented in a single code fragment.
  • SQL database, EJB, Perl used, which, for example, interact in four typical sequences (workflows) with 12 steps each, three times four behavior instructions with up to 12 steps must be generated. These in turn must be able to use three times three calling methods (protocols), for example SJB-> database, database EB, EJB-> Perl. , , all with full Support for sending and receiving inquiries and sending and receiving replies.
  • the method according to the invention must be expandable, since here 5 possibilities of degrees of freedom become known only with the specific application, for example a new type of component or resource. This applies to both the code generation, for example.
  • NET is required for deployment, e.g. an additional 0 installation on a Websphere application server and for load test scenarios, e.g. an additional load test using load test frameworks (e.g. Jprobe) is required.
  • the resource consumption for example the CPU requirement, must 5 via hardware platforms, e.g. PCs, workstations and mainframes, operating systems, e.g. Unix, Windows and variants as well as software platforms such as Websphere, WebLogic, Jboss as application server or Oracle, DB / 2 , mySQL as a database, can be used consistently and re-created 0.
  • hardware platforms e.g. PCs, workstations and mainframes
  • operating systems e.g. Unix, Windows and variants as well as software platforms such as Websphere, WebLogic, Jboss as application server or Oracle, DB / 2 , mySQL as a database
  • the behavior patterns and resource requirements must be mapped and the necessary flexibility must be available so that> 5 different target platforms and technologies can be generated.
  • Such technologies are for example J2EE, JSP, ASP, http.
  • FIG. 3 shows a corresponding code example for FIG. 2, steps S3 and S ⁇ shown in FIG. 2 being recognizable in the code by corresponding if queries for these steps and, for example, in addition to the CPU load of 10 seconds, for example. here is a simulation of html communication in step S3.
  • FIG. 4 shows communication between an http client computer C and a server S which works, for example, with JSP, a method dpl_process communicating in the server with a method call_in and a method ret_out, the method call_in with the method wf- 'step for the respective workflow step, which in turn communicates with a method use_resource for resource utilization, which is based on program elements PE for a
  • Resource consumption type RVA accesses, communicates and whereby the method wf-step connects with a method call_out, which enables a connection to another server NS.
  • the method wf_step is completely generated from the model, the other methods usually have to be cannot be regenerated in each case and can therefore be combined in a library
  • FIG. 5 shows an example with a more complicated communication process, in which a browser makes an http request to a JAVA server page JSP1 (logical sequence number is 1.1), which in turn (Sequence number 1.1.1) calls another JAVA server page JSP2, whereupon the JAVA server page JSP1 receives results from the JAVA server page JPS2 and then (sequence number 1.1.2) makes another call to the JAVA server page JSP2.
  • the JAVA server page JSP2 then carries out a survey of a SQL server mySQL and receives a result from it.
  • the JAVA server page JSPl receives a second set of results from the JAVA server page JSP2, whereupon the JAVA server page JSPl delivers results to the browser.
  • a corresponding process takes place with every browser call, possibly also several processes of the same or different types at the same time. In each stage, the respective server module generally adds or changes parameters and calls program elements PE accordingly. Likewise, in everyone
  • Level resources used according to the specifications e.g. CPU
  • network communication with specified volume and type carried out.
  • Program elements PE for resource consumption types RVA here called benchmarks, are shown.
  • a default program element can be specified in the event that no suitable load program can be selected.
  • the supplied or transferred parameters may be interpreted differently by these program elements.
  • the invention makes it possible to consistently record information of the entire system / product and thus create a basis for the automatic generation.
  • the invention allows a flexible change in the usage behavior, for example new, more or different users, a change in the process behavior, for example component A calls component C instead of B, and
  • Resource requirements for example more or less computing
  • the method according to the invention is flexible and fully expandable with regard to components, e.g. number, type, communication connection and nesting, with regard to processes, e.g. iterations, branching, concurrency, synchronization, 5 conditions, time measurement points, variants of resource requirements each
  • Step etc. regarding resource types, e.g. CPU, time, main memory, disk storage, network bandwidth, external devices, etc., regarding communication protocols, e.g. TCP / IP, http, SOAP, RMI, IIOP, SQL, regarding 10 communication types, e.g. synchronously or asynchronously and with regard to target platforms, for example J2EE, JSP, ASP, CGI, CORBA, .NET, Oracle, computers under Unix or Windows.
  • communication protocols e.g. TCP / IP
  • http e.g. synchronously or asynchronously and with regard to target platforms, for example J2EE, JSP, ASP, CGI, CORBA, .NET, Oracle, computers under Unix or Windows.
  • the automatic generation of the prototypes and the L5 automatic deployment enable a fast and efficient creation of requirement-specific, consistent and comprehensive prototypes, a quick adaptation to new design variants or restrictions of the environment. Finally, it is possible to test the designs on the! 0 real system without having to restrict yourself to extrapolations. In addition, support is provided in the creation / preparation of subsequent load tests based on the specifications of the design.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung besteht im Wesentlichen darin, dass bereits in der Entwurfsphase zuverlässige Tests durch eine automatische Generierung eines umfassenden Performanz-Prototypen in der realen Zielumgebung des Systems erfolgt. Dazu wird der Systementwurf in einer speziellen Notation, beispielsweise in UML, um wichtige Performanzinformation bereichert. Ein Generatorprogramm generiert dann automatisch den Quellcode der beteiligten Komponenten, die dann auf die jeweiligen Zielplattformen und -systeme übertragen und dort aktiviert (Deployment) werden. Zusätzlich können Testszenarien generiert werden, mit denen das fertige Prototypsystem getestet werden kann. Der Hauptvorteil der Erfindung liegt in der automatischen, schnellen, flexiblen, effizienten und konsistenten Generierung eines umfassenden Prototypen, was mit manuellen Prototypen unmöglich wäre. Dies ermöglicht einen frühzeitigen und integrierten Entwurf von Hard- und Software und verringert damit die Risiken Kosten und Zeit einer bestimmten System-/Produktentwicklung.

Description

Beschreibung
Verfahren und Anordnung zur Performanzvorhersage eines informationstechnischen Systems
Die Erfindung betrifft ein Verfahren und eine Anordnung bei der die Performanz, also beispielsweise die Antwortzeit, die Kapazität, die Skalierbarkeit und die Überlasttoleranz , eines informationstechnischen Systems (IT-Systems) vorhergesagt wird.
Eine solche Performanzvorhersage wird momentan beispielsweise auf der Basis von Benchmarking und manuellen Prototypen versucht. Beim Benchmarking werden mit Hilfe von standardisierten Messungen "übliche" Aktivitäten auf realer Hardware durchgeführt, um verschiedene Plattformen vergleichen zu können. Damit können Aussagen zum relativen Performanzvorteil verschiedener Plattformen getroffen aber kaum absolute Werte für spezifische Anwendungen ermittelt werden. Überdies entsprechen standardisierte Benchmarks zwangsläufig nicht dem Ablauf- und Belastungsverhalten des geplanten Systems/Produkts , liefern also nur Basismaterial für Hochrechnungen. Bei manueller Prototypentwicklung werden Aspekte des zu realisierenden Systems/Produkts ausgewählt und implementiert und können dann auf Lastverhalten in Tests beobachtet werden. Üblicherweise steht dabei jedoch die funktionale Machbarkeit im Vordergrund, die Prototypen sind auch aus Komplexitäts- und Zeitgründen zwangsweise auf einige wenige Aspekte beschränkt. Da insbesondere bei großen informationstechnischen Systemen/Produkten die Performanz typischerweise aber auch durch die Interaktion verschiedenster Komponenten in unterschiedlichsten Nutzungsszenarien beeinflusst wird, ist das Risiko, wichtige Effekte bei manuellen Prototypen zu übersehen, sehr groß. Der Aufwand für eine manuelle Implementierung verschiedener
Nutzungsszenarien oder Design-Alternativen ist in der Regel nicht vertretbar. Nachteilig bei der manuellen Prototypentwicklung ist ebenfalls die hohe Entwicklungsdauer und die Gefahr von Fehlern und Inkonsistenzen.
Größere IT-Systeme oder Produkte haben fast immer und in zunehmendem Maße Performanz als wesentliches
Qualitätskriterium. Allerdings beeinflusst eine Vielzahl der Implementierungs- und Konfigurationsmöglichkeiten des Systems/Produkts an sich aber auch der zugrunde liegenden Hard- und Softwarekomponenten die Performanz des Systems zum Teil erheblich. Deren Auswirkungen auf das Gesamtsystem ist nach Fertigstellung - durch Lasttests messbar, was für Konzepte, Systemdesign, Kauf- und Installationsplanung inakzeptabel spät im Entwicklungszyklus wäre. Eine erwünschte parallele Entwicklung von Hardware, Software und Installation ist damit unmöglich, ebenso eine qualitäts- oder kostenoptimierte Planung oder Entwicklung unter Berücksichtigung von Performanz . Darüber hinaus werden Performanzprobleme, die die Funktionalität des Gesamtsystems gefährden, unter Umständen nicht rechtzeitig erkannt.
Die der Erfindung zugrunde liegende Aufgabe besteht nun darin, die oben genannten Nachteile zu vermeiden und ein Verfahren und eine Anordnung zur frühzeitigen und möglichst zuverlässigen Performanzvorhersage für IT-Systeme/Produkte anzugeben, wobei "frühzeitig" hier bereits in der Entwurfsphase bedeutet.
Diese Aufgabe wird hinsichtlich des Verfahrens durch die Merkmale des Patentanspruchs 1 und hinsichtlich der Anordnung durch die Merkmale des Patentanspruchs 5 in erfinderischer Weise gelöst. Die weiteren Ansprüche betreffen bevorzugte Ausgestaltungen des erfindungscjemäßen Verfahrens.
Die Erfindung besteht im Wesentlichen darin, dass bereits in der Entwurfsphase zuverlässige Tests durch eine automatische Generierung eines umfassenden Performanz-Prototypen in der realen Zielumgebung des Systems erfolgt. Dazu wird der Systementwurf in einer speziellen Notation, beispielsweise in UML, um wichtige Performanzinformation bereichert. Ein Generatorprogramm generiert dann automatisch den Quellcode der beteiligten Komponenten, die dann auf die jeweiligen Zielplattformen und -Systeme übertragen und dort aktiviert (Deployment) werden. Die generierten Prototypen entsprechen zumindest hinsichtlich des Verhaltens, der Resourcenbelastung und der Performanz dem zukünftigen System - nicht notwendigerweise jedoch hinsichtlich der Inhalte der Systemantworten. Zusätzlich können optional Testszenarien generiert werden, mit denen das fertige Prototypsystem getestet werden kann. Der Hauptvorteil der Erfindung liegt in der automatischen, schnellen, flexiblen, effizienten und konsistenten Generierung eines umfassenden Prototypen, was mit manuellen Prototypen unmöglich wäre. Dies ermöglicht einen frühzeitigen und integrierten Entwurf von Hard- und Software und verringert damit die Risiken Kosten und Zeit einer bestimmten System-/Produktentwicklung.
Die Erfindung wird nachfolgend anhand von in den Zeichnungen dargestellten Beispielen näher erläutert. Dabei zeigt
Figur 1 ein Übersichtsbild zur Erläuterung der Erfindung,
Figur 2 ein Bild zur Erläuterung der Nachbildung eines Arbeitsablaufs in einem Netzrechner,
Figur 3 ein zur Figur 2 gehöriges Codebeispiel,
Figur 4 eine Darstellung zur Erläuterung einer entsprechenden Client-Server-Kommunikation und der Nachbildung des entsprechenden Arbeitsablaufes im Server,
Figur 5 ein Modell eines komplizierteren Kommunikationsszenarios zur weiteren Erläuterung des erfindungsgemäßen Verfahrens und Figur 6 eine Tabelle zur näheren Erläuterung von charakteristischen Lastprogrammen .
Figur 1 zeigt eine Gesamtdarstellung zur Erläuterung der
Erfindung, bei der ein Modell M in einer gegebenen Notation eine Eingangsgröße für einen Prototypgenerator PG liefert, der seinerseits Prototypcodes 1, 2 ... n für verschiedene Plattformen mit Hilfe von Programmelernenten für Ressourcenverbrauchsarten RVA erzeugt, die dann auf
Applikationsserver AS oder Servletmaschinen SE ausgesetzt (deployed) werden, die ihrerseits ggf. auf Datenbanken DB zugreifen.
Darüber hinaus kann der Prototypgenerator PG optional auch Lasttestszenarien LTS mit Test-Client-Rechnern TC erzeugen, um eine Belastungssituation mit beispielsweise mehreren Benutzerrechnern, die ein jeweiliges Benutzerprofil aufweisen, zu simulieren.
Durch das erfindungsgemäße Verfahren und die erfindungsgemäße Anordnung kann mit Vorteil eine Simulation und Bewertung von bspw. Datennetz-Applikationen erfolgen, wobei es sich hier um eine „In-vivo"-Simulation, d. h. eine Kombination aus bereits implementierten und simulierten Komponenten handelt"und wobei die Simulation auf realer Hardware bzw. im realen Umfeld erfolgt. In Figur 1 sind die durch den Prototyp-Generator PG generierten Teile, die noch nicht vorhandene Teile simulieren, schraffiert angedeutet.
Die Notation des Modells erfolgt dabei idealerweise in Standardmodellierungswerkzeugen der Softwareentwicklung, zum einen um deren Möglichkeiten und Verbreitung zu nutzen, zum anderen um in den Entwicklungsprozess eingebunden zu werden. Die Notation soll dabei einfach und intuitiv genug sein, um im normalen Software-Entwicklungsprozess ohne viel Mehraufwand verwendet werden zu können. Gleichzeitig müssen die relevanten Performanzinfor ationen eindeutig hinterlegt werden können.
Wegen Verbreitung und Akzeptanz ist die UML (Unified Modelling Language) die naheliegende Wahl, andere
Modellierung sprachen, zum Beispiel SDL oder MSC, wären aber ebenfalls geeignet. Um das erfindungsge äße Verfahren möglichst frühzeitig einsetzen zu können, wird eine "Workflow" -basierte Notation verwandt, d.h. es werden Abläufe definiert und nachgebildet, nicht notwendigerweise interne Entscheidungsalgorithmen. Aus der UML-Darstellung kann bspw. über XML (extensible markup language) ein Zwischencode in Java erzeugt werden, der dann in die entsprechende Zielplattform konvertiert wird.
Die Notation und der Generator PG sollte vorteilhafterweise in der Lage sein, die Performanzinformationen aus Tools verschiedener Hersteller ermitteln zu können und die Inhalte der Notation müssen aus verschiedenen Diagrammen zusammengeführt und in einem einzigen Codefragment repräsentiert werden können.
Es können dabei sehr verschiedene Situationen auftreten, wie beispielsweise: - Dass die Verhaltensmuster zweiter typischer Abläufe in ' einer einzigen Komponente integriert werden müssen. Dass die Komponenten verschiedener Zielplattformen, zum Beispiel eine Datenbank, EJB, Perl , .NET, miteinander in der erwünschten Form interagieren können müssen. - Werden zum Beispiel drei Typen von Komponenten, (eine
SQL Datenbank, EJB, Perl ) verwendet, die bspw. in vier typischen Abläufen (workflows) ä 12 Schritte interagieren, müssen drei mal vier Verhaltensanweisungen mit bis zu 12 Schritten generiert werden. Diese müssen wiederum drei mal drei Aufrufverfahren (Protokolle) verwenden können, zum Beispiel SJB->Datenbank, Datenbank- EB, EJB->Perl . . . , alle jeweils mit voller Unterstützung der Absendung und Empfang der Anfragen sowie der Absendung und Empfang der Antworten.
Das erfindungsgemäße Verfahren muss erweiterbar sein, da hier 5 Möglichkeiten der Freiheitsgrade erst mit dem konkreten Anwendungsfall bekannt werden, zum Beispiel ein neuer Komponenten- oder Ressourcentyp. Dies trifft sowohl für die Codegenerierung, bspw. wird zusätzlich Code in . NET benötigt, für das Aussetzen (Deployment) , bspw. wird eine zusätzliche 0 Installation auf einem Websphere-Application-Server und für Lasttestszenarien, zum Beispiel wird ein zusätzlicher Lasttest durch Lasttestframeworks (z.B. Jprobe) nötig, zu._
Der Ressourcenverbrauch, zum Beispiel der CPU-Bedarf, muss 5 über Hardwareplattfor en, bspw. PCs, Workstations und Mainframes, Betriebssystemen, bspw. Unix, Windows und Varianten sowie Softwareplattformen, wie Websphere, WebLogic, Jboss als Applikationsserver oder Oracle, DB/2, mySQL als Datenbank, hinweg konsistent verwendet und nachgestellt 0 werden .
Für eine automatische Generierung der Perfor anz-Prototypen müssen die Verhaltensmuster und Ressourcenbedarfe abgebildet und muss die nötige Flexibilität vorhanden sein, damit >5 verschiedene Zielplattformen und Technologien generiert werden können. Solche Technologien sind beispielsweise J2EE, JSP, ASP, http .
Das Deployment, also die automatische Installation und ι0 Aktivierung der Prototypen, muss auf verschiedene Plattformen möglich sein, und gegebenenfalls individuelle Zugangs- und Aktivierungsmethoden erlauben. Für das Deployment sind Zugriffs-, Hochlade- und Typ-Informationen sowie gegebenenfalls auch einzelne manuelle Schritte, zum Beispiel 5 ein Neustart, erforderlich. In Figur 2 ist ein Arbeitsablauf wf_step mit einem Client- Rechner A und einem Server-Rechner B dargestellt, wobei der Rechner A zunächst ein Anfrage fl an den Rechner B sendet und im Rechner B durch die entsprechend annotierten Parameter eine CPU-Belastung von bspw. 10 Sekunden (spe . req. cpu=10s) durch ein entsprechend aufgerufenes Programmelement PE für eine Ressourcenverbrauchsart RVA bewirkt und danach ein Übergang zurück auf den Rechner A mit Rückmeldung ggf. veränderter Parameter erfolgt .
In Figur 3 ist ein entsprechendes Code-Beispiel zu Figur 2 gezeigt, wobei die in Figur 2 gezeigten Schritte S3 und Sβ im Code durch entsprechende if-Abfragen für dies Schritte erkennbar sind und beispielsweise neben der CPU-Belastung von bspw. 10 Sekunden bspw. hier noch eine Simulation den html- Kommunikation im Schritt S3 erfolgt.
In Figur 4 ist eine Kommunikation zwischen einem http-Client- Rechner C und einem Server S, der beispielsweise mit JSP arbeitet, gezeigt, wobei im Server eine methode dpl_prozess mit einer Methode call_in und einee Methode ret_out kommuniziert, wobei die Methode call_in mit der Methode wf- ' step für den jeweiligen Arbeitsfluss-Schritt, kommuniziert, die wiederum mit einer Methode use_resource für Resourcenauslastung, die auf Programmelemente PE für eine
Ressourcenverbrauchsart RVA zugreift, kommuniziert und wobei dei Methode wf-step mit einer methode call_out in Verbindung tritt, die eine Verbindung mit einem weiteren Server NS ermöglicht. Die Methode wf_step wird dabei vollständig aus dem Modell generiert, die anderen Methoden müssen i.d.R. nicht jeweils neu generiert werden und können daher in einer Bibliothek zusammengefasst werden
In Figur 5 ist ein Beispiel mit einem komplizierteren Kommunikationsablauf dargestellt, bei dem ein Browser eine http-Anfrage zu einer JAVA- Serverpage JSPl (logische Sequenznummer ist 1.1) durchführt, der seinerseits (Sequenznummer 1.1.1) eine weiteren JAVA- Serverpage JSP2 aufruft, worauf die JAVA- Serverpage JSPl Ergebnisse von der JAVA- Serverpage JPS2 erhält und daraufhin (Sequenznummer 1.1.2) einen weitere Aufrufe an die JAVA- Serverpage JSP2 durchführt. Die JAVA- Serverpage JSP2 führt daraufhin eine Befragung eines SQL-Servers mySQL durch und erhält ein Ergebnis von diesem. Die JAVA- Serverpage JSPl erhält von der JAVA- Serverpage JSP2 eine zweite Menge von Ergebnissen worauf die JAVA- Serverpage JSPl Ergebnisse an den Browser liefert. Ein entsprechender Ablauf erfolgt bei jedem Browseraufruf, gegebenenfalls auch mehrere Abläufe der gleichen oder verschiedenartiger Art gleichzeitig. In jeder Stufe werden im allgemeinen Fall vom jeweiligen Servermodul hierbei Parameter hinzugefügt oder verändert und entsprechende Aufrufe von Programmelementen PE durchgeführt. Ebenso werden in jeder
Stufe Ressourcen gemäß den Spezifikationen verbraucht (z.B. CPU) und eine Netzwerkkommunikation mit spezifiziertem Volumen und typ durchgeführt .
In Figur 6 ist eine Tabelle mit auswählbaren
Programmelementen PE für Ressourcenverbrauchsarten RVA, hier Benchmarks genannt, dargestellt. Es kann beispielsweise hierbei ein Default-Programmelement angegeben werden für den Fall, dass kein geeignetes Lastprogramm auswählbar ist. Die mitgelieferten bzw. übergebenen Parameter werden von diesen Programmelementen gegebenenfalls unterschiedlich interpretiert .
Durch die Erfindung wird es möglich, Informationen des gesamten Systems/Produkts konsistent festzuhalten und damit eine Grundlage für die automatische Generierung geschaffen. Die Erfindung erlaubt eine flexible Änderung des Nutzungsverhaltens, zum Beispiel neue, mehr oder andere Benutzer, eine Änderung des AblaufVerhaltens, zum Beispiel Komponente A ruft Komponente C statt B auf, und
Ressourcenbedarfe, zum Beispiel mehr oder weniger Rechen-
/Speicher-/Netzwerkkapazität . Das erfindungsgemäße Verfahren ist flexibel und voll erweiterbar hinsichtlich Komponenten, zum Beispiel Anzahl, Typ, Kommunikationsverbindung und Verschachtelung, hinsichtlich Abläufen, zum Beispiel Iterationen, Verzweigung, Nebenläufigkeit, Synchronisierung, 5 Bedingung, Zeitmesspunkte, Varianten Ressourcenbedarf je
Schritt usw. , hinsichtlich Ressourcentypen, zum Beispiel CPU, Zeit, Hauptspeicher, Plattenspeicher, Netzbandbreite, externe Geräte usw. , hinsichtlich Kommunikationsprotokollen, zum Beispiel TCP/IP, http, SOAP, RMI, IIOP, SQL, hinsichtlich 10 Kommunikationstypen, zum Beispiel synchron oder asynchron und hinsichtlich Zielplattformen, zum Beispiel J2EE, JSP, ASP, CGI, CORBA, .NET, Oracle, Rechner unter Unix oder Windows.
Die automatische Generierung der Prototypen und das L5 automatische Deployment ermöglichen eine schnelle und effiziente Erstellung von anforderungsspezifischen, konsistenten und umfassenden Prototypen, eine schnelle Anpassung an neue Entwurfsvarianten oder Einschränkungen der Umgebung. Es wird schließlich ein Testen der Entwürfe am !0 realen System ermöglicht, ohne sich auf Hochrechnungen beschränken zu müssen. Darüber hinaus erfolgt eine Unterstützung bei der Erstellung/Vorbereitung von anschließenden Lasttests basierend auf den Spezifikationen des Entwurfs .

Claims

Patentansprüche
1. Verfahren zur Performanzvorhersage eines infor ationstechnischen Systems ,
5 - bei dem während des Systementwurfs mit Hilfe einer Notation eines Models (M) performanzrelevante Aspekte erfasst werden, - bei dem aus Parametern für die performanzrelevanten Aspekte Abläufe und Ressourcenbedarfe des Systems sowie die beteiligten Plattformen entnommen werden,
10 - bei dem mindestens für die im System vorhandenen
Plattformen Prototyp-Codes (1, .. ,n) derart generiert werden, dass ein jeweilig generierter Code mit einer ProgrammablaufStruktur entsprechend der späteren tatsächlichen Abläufe erzeugt, entsprechend dem jeweiligen
L5 Ressourcenbedarf, an der betreffenden Stelle in der
Programmablaufstruktur mindestens ein Programmelement (PE) für eine Ressourcenverbrauchsart (RVA) aufgerufen und die Programmablaufstruktur mit dem mindestens einen Aufruf (a) in mindestens einen Prototypcode für eine Zielplattform (S, AS,
10 SE) umgewandelt wird.
2. Verfahren nach Anspruch 1 , bei dem der jeweilige Prototypcode auf die jeweilige Zielplattform oder das Zielsystem übertragen und dort 15 installiert und aktiviert wird und bei dem unter den realen KommunikationsVerhältnissen die Rückmeldungen des Systems gebildet und in einem Client- Rechner empfangen und ausgewertet werden.
i0 3. Verfahren nach Anspruch 1 oder 2 , bei dem in Abhängigkeit der Notation der performanzrelevanten Aspekte ein Lasttestszenario (DTS) mit mindestens einem Test- Client-Rechner (TC) erstellt wird, wobei dieser mindestens eine Test-Client-Rechner ein jeweiliges bestimmtes
5 Benutzerverhalten simuliert bzw. eine Netzbelastung simuliert .
4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Modellierungssprache UML ist.
5. Anordnung zur Performanzvorhersage eines 5 infor ationstechnischen Systems,
- bei der ein Model (M) für performanzrelevante Aspekte vorhanden ist, wobei aus Parametern für die performanzrelevanten Aspekte Abläufe und Ressourcenbedarfe des Systems sowie die beteiligten Plattformen entnehmbar
L0 sind,
- bei der ein Prototypgenerator (PG) vorhanden ist, der für eine jeweilige Zielplattform des Systems einen Prototypcode derart erzeugt, dass ein eine ProgrammablaufStruktur entsprechend der späteren tatsächlichen Abläufe erzeugt, ι5 entsprechend dem jeweiligen Ressourcenbedarf, an der betreffenden Stelle in der ProgrammablaufStruktur mindestens ein Programmelement (PE) für eine Ressourcenverbrauchsart (RVA) aufgerufen und die ProgrammablaufStruktur mit dem mindestens einen Aufruf (a) in mindestens einen Prototypcode
!0 für eine Zielplattform (S, AS, SE) umgewandelt wird.
PCT/EP2004/001168 2003-04-09 2004-02-09 Verfahren und anordnung zur performanzvorhersage eines informationstechnischen systems WO2004090756A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE2003116292 DE10316292A1 (de) 2003-04-09 2003-04-09 Verfahren und Anordnung zur Performanzvorhersage eines informationstechnischen Systems
DE10316292.5 2003-04-09

Publications (2)

Publication Number Publication Date
WO2004090756A2 true WO2004090756A2 (de) 2004-10-21
WO2004090756A3 WO2004090756A3 (de) 2005-06-09

Family

ID=33154140

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/001168 WO2004090756A2 (de) 2003-04-09 2004-02-09 Verfahren und anordnung zur performanzvorhersage eines informationstechnischen systems

Country Status (2)

Country Link
DE (1) DE10316292A1 (de)
WO (1) WO2004090756A2 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006074407A2 (en) 2005-01-07 2006-07-13 Lumidigm, Inc. Biometric recognition/verification using multispectral imaging
CN104077139B (zh) * 2014-07-04 2017-11-24 用友网络科技股份有限公司 脚本驱动环境下的远程调用方法和远程调用装置
CN107833013A (zh) * 2017-10-27 2018-03-23 链家网（北京）科技有限公司 软件开发的工作量预估准确性的自动化统计方法及装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000038087A1 (en) * 1998-12-22 2000-06-29 Celoxica Limited Hardware/software codesign system

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7069204B1 (en) * 2000-09-28 2006-06-27 Cadence Design System, Inc. Method and system for performance level modeling and simulation of electronic systems having both hardware and software elements

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000038087A1 (en) * 1998-12-22 2000-06-29 Celoxica Limited Hardware/software codesign system

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
BALARIN F ET AL: "Synthesis of software programs for embedded control applications" IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN OF INTEGRATED CIRCUITS AND SYSTEMS IEEE USA, Bd. 18, Nr. 6, Juni 1999 (1999-06), Seiten 834-849, XP002318486 ISSN: 0278-0070 *
MARIATOS E P ET AL: "Object oriented prototyping at the system level: an image reconstruction application example" RAPID SYSTEM PROTOTYPING, 1996. PROCEEDINGS., SEVENTH IEEE INTERNATIONAL WORKSHOP ON THESSALONIKI, GREECE 19-21 JUNE 1996, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 19. Juni 1996 (1996-06-19), Seiten 90-95, XP010166882 ISBN: 0-8186-7603-5 *
PASSERONE C ET AL: "Fast Hardware/software Co-simulation For Virtual Prototyping And Trade-off Analysis" PROCEEDINGS OF THE DESIGN AUTOMATION CONFERENCE. ANAHEIM, JUNE 9 - 13, 1997, NEW YORK, ACM, US, Bd. CONF. 34, 9. Juni 1997 (1997-06-09), Seiten 389-394, XP010227615 ISBN: 0-7803-4093-0 *
SALMELA M ET AL: "Smart virtual prototypes: distributed 3D product simulations for Web based environments" PROCEEDINGS WEB3D - VRML 2000. FIFTH SYMPOSIUM ON THE VIRTUAL REALITY MODELING LANGUAGE ACM NEW YORK, NY, USA, 2000, Seiten 87-94, XP002318402 ISBN: 1-58113-211-5 *
WOODSIDE M ET AL: "A WIDEBAND APPROACH TO INTEGRATING PERFORMANCE PREDICTION INTO A SOFTWARE DESIGN ENVIRONMENT" PROCEEDINGS OF THE 1ST INTERNATIONAL WORKSHOP ON SOFTWARE AND PERFORMANCE. WOSP '98. SANTA FE, NM, OCT. 12 - 16, 1998, INTERNATIONAL WORKSHOP ON SOFTWARE AND PERFORMANCE, NEW YORK, NY : ACM, US, 1998, Seiten 31-41, XP000846864 ISBN: 1-58113-060-0 *
WOODSIDE M ET AL: "Automated performance modeling of software generated by a design environment" PERFORMANCE EVALUATION ELSEVIER NETHERLANDS, Bd. 45, Nr. 2-3, Juli 2001 (2001-07), Seiten 107-123, XP002318401 ISSN: 0166-5316 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006074407A2 (en) 2005-01-07 2006-07-13 Lumidigm, Inc. Biometric recognition/verification using multispectral imaging
CN104077139B (zh) * 2014-07-04 2017-11-24 用友网络科技股份有限公司 脚本驱动环境下的远程调用方法和远程调用装置
CN107833013A (zh) * 2017-10-27 2018-03-23 链家网（北京）科技有限公司 软件开发的工作量预估准确性的自动化统计方法及装置

Also Published As

Publication number Publication date
WO2004090756A3 (de) 2005-06-09
DE10316292A1 (de) 2004-11-11

Similar Documents

Publication Publication Date Title
DE60010906T2 (de) Verfahren zum testen von web-basierten softwareobjekten
DE102013207608B4 (de) Instrumentieren von Software-Anwendungen für die Konfiguration derselben
DE60021066T2 (de) Prüfung eines Softwarepakets
US7913229B2 (en) Computer-implemented system for generating automated tests from a web application
DE112010004420T5 (de) Verfahren und System zur Verbesserung der Ausführungszeit von Software durch Optimierung elnes Leistungsmodells
DE102004057021A1 (de) Verfahren und System zum Testen eines Computersystems durch ein Anlegen einer Last
WO2015044374A1 (de) Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
DE102017106023A1 (de) Verfahren und System zum automatisierten Benutzerschnittstellentesten über modellgetriebene Techniken
DE102005013239A1 (de) Drahtlosmodulsimulator
DE10333087A1 (de) Verfahren zum automatischen Zerlegen von dynamischen Systemmodellen in Teilmodelle
WO2008113682A1 (de) Verfahren zum rechnergestützten ermitteln der abhängigkeiten einer vielzahl von modulen eines technischen systems, insbesondere eines softwaresystems
DE10333088A1 (de) Verfahren zum Liefern von Zugriff auf die internen Signale eines dynamischen Systemmodells von außerhalb bezüglich der Modellierungsumgebung
DE10303054A1 (de) Verifizieren einer Programmversion
DE112019002680T5 (de) Gerät zur Orchestrierung der verteilten Anwendungsbereitstellung mit End-to-End-Leistungsgarantie
DE10324594A1 (de) Verfahren zum Bereitstellen einer verbesserten Simulationsfähigkeit eines dynamischen Systems außerhalb der ursprünglichen Modellierungsumgebung
DE102009043287A1 (de) Verfahren und Anordnung zum Installieren und Konfigurieren eines Computersystems
WO2004090756A2 (de) Verfahren und anordnung zur performanzvorhersage eines informationstechnischen systems
DE112017002503T5 (de) Schritt-zurück-mechanismus zum entwickeln und diagnostizieren von prozessanwendungen
DE112020000434T5 (de) Disaggregierte verteilte messanalyse system unter verwendung von dynamic application builder
EP2642359A1 (de) Entwicklungseinrichtung und Verfahren zum Erstellen eines Steuergeräteprogramms
DE202012013449U1 (de) System für In-Line-Einfügung von Scriptabhängigkeiten
EP2653850B1 (de) Verfahren und IT-System zum Durchführen von Gesamtfahrzeugtests
DE102019133197A1 (de) Client-server-modell für den editor für mehrere dokumente
DE10033812A1 (de) Verfahren zum Erzeugen von Informationsmodellen
DE19845610A1 (de) System zur Installation, Lizenz- und Konfigurationsverwaltung und Wartung von komponentenbasierten Softwaresystemen mehrerer Nutzer

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
122 Ep: pct application non-entry in european phase