Generation of distributed system test-beds from high-level software architecture descriptions

Grundy, John; Cai, Yuhong; Liu, A.

doi:10.1109/ase.2001.989805

Cited by 24 publications

(30 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Besides validating a particular methodology, the question of prediction precision is tackled from many other angles, including workload characterization [29,16], or generation of either the executable system [31,13,33,6] or the performance model [15,19]. What these approaches have in common is that they still require Self-archived copy.…”

Section: Related Workmentioning

confidence: 99%

Validating Model-Driven Performance Predictions on Random Software Systems

Babka

Tůma

Bulej

2010

Research Into Practice – Reality and Gaps

View full text Add to dashboard Cite

Abstract. Software performance prediction methods are typically validated by taking an appropriate software system, performing both performance predictions and performance measurements for that system, and comparing the results. The validation includes manual actions, which makes it feasible only for a small number of systems. To significantly increase the number of systems on which software performance prediction methods can be validated, and thus improve the validation, we propose an approach where the systems are generated together with their models and the validation runs without manual intervention. The approach is described in detail and initial results demonstrating both its benefits and its issues are presented.Key words: performance modeling, performance validation, MDD MotivationState of the art in model-driven software performance prediction builds on three related factors: the availability of architectural and behavioral software models, the ability to solve performance models, and the ability to transform the former models into the latter. This is illustrated for example by the survey of modeldriven software performance prediction [3], which points out that the typical approach is to use UML diagrams for specifying both the architecture and the behavior of the software system, and to transform these diagrams into performance models based on queueing networks.Both the models and the methods involved in the prediction process necessarily include simplifying assumptions that help abstract away from some of the complexities of the modeled system, e.g., approximating real operation times with probability distributions or assuming independence of operation times. These simplifications are necessary to make the entire prediction process tractable, but the complexity of the modeled system usually makes it impossible to say how the simplifications influence the prediction precision.Self-archived copy. The original publication is available at www.springerlink.com,

show abstract

Section: Related Workmentioning

confidence: 99%

Validating Model-Driven Performance Predictions on Random Software Systems

Babka

Tůma

Bulej

2010

Research Into Practice – Reality and Gaps

View full text Add to dashboard Cite

show abstract

“…The SoftArch/MTE [20] tool provides a framework for system architects to provide higher level abstraction of the system specifying system characteristics such as middleware, database technology, and client requests. The tool then generates a implementation of the system along with the performance tests that measure system characteristics.…”

Section: Related Workmentioning

confidence: 99%

A model-based distributed continuous quality assurance process to enhance the quality of service of evolving performance-intensive software systems

Yılmaz¹

2004

"Second International Workshop on Remote Analysis and Measurement of Software Systems (RAMSS 04)" - W15S Workshop - 26th Intern

View full text Add to dashboard Cite

show abstract

“…Some approaches use extracted component meta-data and wrappers to formulate automated component tests [26,21], but these techniques tend to only focus on functional component validation, not validating non-functional constraints. Middleware performance testing work typically focuses on only limited aspects of component functional and non-functional requirements [9,22,7]. In addition, many of these approaches also suffer from a high degree of manual effort on the part of developers to build test harnesses with which to evaluate their components and middleware [5,7,9,14].…”

Section: Motivationmentioning

confidence: 99%

“…Middleware performance testing work typically focuses on only limited aspects of component functional and non-functional requirements [9,22,7]. In addition, many of these approaches also suffer from a high degree of manual effort on the part of developers to build test harnesses with which to evaluate their components and middleware [5,7,9,14]. Most current deployed component validation approaches also typically require extensive test bed prototyping to evaluate components [16,9].…”

Section: Motivationmentioning

confidence: 99%

“…These issues cross-cut software components in multiple places and in ways orthogonal to the functional decomposition of the application typically used by most component (and object) design approaches [32,24,6]. Validating that component designs and compositions meet overall system constraints, and that individual component constraints are satisfied in a given deployment situation, is very difficult [9,7]. Our experience with AOCE has shown some design-time and implementation-time validation can be done, but this must be complemented by deploymenttime validation [8].…”

Section: Motivationmentioning

confidence: 99%

See 1 more Smart Citation