No description available.

No description available.

No description available.

No description available.

No description available.

Building a new software system requires careful planning and investigation in order to avoid any problems in the later stages of the development. By using a universally accepted design notation such as the Unified Modeling Language (UML), ambiguities in the system specification can be eliminated or minimised. The aspect that frequently needs to be investigated before the implementation stage can be commenced concerns the proposed system’s performance. It is necessary to predict whether a particular design will meet the performance requirement - i.e. is it worth implementing the system - or not. One way to obtain this performance prediction is by using simulation programs to mimic the execution of the system. Unfortunately, it is often difficult to transform the design into a simulation program without some sound knowledge of simulation techniques. In addition, new simulation programs need to be built each time for different systems - which can be tedious, time consuming and error prone. The currently available UML tools do not provide any facilities for generating simulation programs automatically from UML specifications. This shortcoming is the main motivation for this research. The work involved here includes an investigation of which UML design notations can be used; the available simulation languages or environments for running the simulation; and more importantly, a framework that can capture the simulation information from UML design notation. Using this framework, we have built tools that enable an automatic transformation of a UML design notation into a simulation program. Two tools (parsers) that can perform such a transformation have been constructed. We provide case studies to demonstrate the applicability of these tools and the usefulness of our simulation framework in general.

Development of a software system from existing components can surely have various benefits, but can also entail a series of problems. One type of problems is caused by a limited exchange of information between the developer and user of a component. A limited exchange and thereby a lack of information can have various consequences, among them the requirement to test a component prior to its integration into a software system. A lack of information cannot only make test prior to integration necessary, it can also complicate this tasks. This paper proposes a new strategy to testing components and making components testable. The basic idea of the strategy is to merge components and testing tools in order to make components capable of testing their own methods. Such components allow their thorough testing without disclosing detailed information, such as source code. This strategy thereby fulfills the needs of both the developer and user of a component.

Thesis (Ph. D.)--West Virginia University, 2003. / Title from document title page. Document formatted into pages; 1 v. (various pagings) : ill. (some col.). Vita. Includes abstract. Includes bibliographical references.

<p>Future operating system vendor support for an office building LAN was investigated in response to the realization that current vendor operating system support of the LAN was going away. Options analyzed that would best preserve the existing functionality of the software applications utilized on the LAN were, (1) to do nothing, (2) utilize another vendor for support and (3) upgrade to the current vendors latest operating system, Solaris 2.2.</p> / Master of Science

No description available.