Master's Thesis - Computer Graphics and Visualization - TU Delft

More documents

Recommendations

Info

2.1.2 Interface analysis This section explains the external requirements of the Culgi GPE, like the hardware interface, software interface and the system platform. Table 2-1 shows this information in general. Table 2-1 Overall situation of the Culgi GPE Item Culgi’s situation Platform - Cross platform Hardware interface - The Culgi GPE will run in personal computer. Software interface - The Culgi Library - The Tcl interpreter. As shown in Table 2-1 , the Culgi GPE will run on various platforms, at least on Windows and on Linux. And it is designed to run on a personal computer, so there are no special requirements in hardware. The Culgi GPE should have interfaces with the Culgi Library and Tcl interpreter. It should be able to load Tcl interpreter into the system, and then load the Cuigi library into the Tcl interpreter. Because the Culgi GPE is a bridge of the Culgi Library and Tcl scripts, it is very important to study the Culgi Library. The features of the commands in the Culgi library are listed below. 1. The data types of almost all arguments of the Culgi commands are some primitive types, like string, integer or double. Culgi stores most of the data in some special structure which is hidden from the users. For example, the command BrownianDynamics, whose functionality is to calculate the next positions of the molecules, takes the time of calculation as the only arguments. Those data are stored in some global variables, and BrownianDynamics operates on these variables. 2. The operations in the Culgi commands do not change the arguments. For example, in CreateDPDMolecules, an argument that needs to be set is the name of a molecule, whose data type should be string. But after this command has been executed, this string is still a string with no change in its contents. Only the Culgi system knows that there are some molecules in the system now having this name. 3. The return values of the Culgi commands are void or string. The real data structure that stores the data is not returned. 4. Some commands take the same arguments. The argument in a command some times will be referred to in another command. For example, the command CreateDPDMolecule takes the name of the module as a parameter. Then some other commands, like AddMoleculesViewable, may refer to this parameter in order to get the instance of the molecules. 5. The general pipeline of a simulation program with Culgi consists of three steps. 1) Create molecule models by giving the composition of each type of molecules. 2) Create rendering windows and set the window if a user wants to make the simulation progress visible. 3) Set the properties to the molecules and launch the simulation. 6. The structures of the simulation programs of Culgi are always a sequence of commands. Almost no control structures are used, like “If-else” and “switch”. The only control structure used is a kind of - 6 -
loop in which users only need to specify the time of this loop. 7. The Culgi library is still in development. It is possible that some of the existing commands will be replaced or deleted in future. 2.1.3 Product functions From the general description of this product, the users’ characteristics and the interface analysis, the Culgi GPE should have following functionalities: 1) To load Tcl interpreter into the system and be able to access the Culgi Library. 2) To represent the commands in the Culgi Library in a visual way. Each presentation unit is called a module. A module should have properties, contents and interface. The contents of a module should be a Tcl script which includes one or more Culgi commands. The interface should be an API that users could manipulate. Modules will be the primary building blocks of a program. 3) To have a module library to manage modules. Modules are used to represent the commands in the Culgi Library. But there will be several hundreds of commands in the Culgi Library. So the number of modules will be big as well. In this case, a module library to manage these modules is necessary. 4) To provide interaction between users and modules. Users should be able to create or delete the instance of the module, should be able to communicate with the module. 5) To run the program composed of modules. 6) Debug users’ programs. 7) To export the source code of the users’ programs automatically with the end user GUIs. We call the export program an end user application. 8) To have an easy-to-use user interface that should wait for users’ commands and then execute the corresponding actions. 9) To provide Enough help information on not only the function of modules and parameters, but also on the interface itself. In this section, we give out the overall description of the Culgi GPE. Basing on these general requirements to the system, the section 2.2 explains the particular requirements. 2.2 Specific requirements This section describes the functional and non functional requirements in detail. In section 2.1.1 , a scenario is described to show how a user uses the Culgi GPE to achieve the goal successfully. Based on this scenario, a Use Case Model 1 is defined to specify the features of the system. Then in section 2.2.2, a detailed function list is presented. This list is concluded from the use case model. 1 The UP (Unified Process) defines the Use-Case Model within the Requirements discipline. Primarily, this is the set of all written use cases; it is a model of the system's functionality and environment [1]. A use case describes a sequence of actions that provide something of measurable value to an actor. An actor here refers to a user in the system. - 7 -
Page 1: A Graphical Programming Environment
Page 5 and 6: Preface This project started in Sep
Page 7 and 8: Abstract Culgi stands for Chemistry
Page 9 and 10: Contents Abstract..................
Page 11 and 12: Chapter 1 Introduction Culgi stands
Page 13 and 14: elationship model (see Figure 1-3).
Page 15: Chapter 2 Requirement Analysis This
Page 19 and 20: Primary actor: -Simulation Program
Page 21 and 22: Req04 Select a module in the librar
Page 23 and 24: Chapter 3 Design Models In chapter
Page 25 and 26: also generates the same result as (
Page 27 and 28: 3.3 The Concept Editor 3.3.1 Descri
Page 29 and 30: (a) Step1 Build Box Step2 Create Vi
Page 31 and 32: 3.5.1 Multi view of modules In the
Page 33 and 34: 3.5.2 Various widgets to display a
Page 35 and 36: a correct order. These source codes
Page 37 and 38: Chapter 4 Implementation of the Cul
Page 39 and 40: library. Meanwhile, the interface p
Page 41 and 42: For example, in Figure 3-5(b), the
Page 43 and 44: The Module Editor is a tool for cre
Page 45 and 46: corresponding operations. Figure 4-
Page 47 and 48: The second problem is about how to
Page 49 and 50: sequence. From these approaches, we
Page 51 and 52: Chapter 5 Results and Test The prev
Page 53 and 54: (a) Before click. (b) After an item
Page 55 and 56: instance of the module setDPDEnviro
Page 57 and 58: (a) Make only “Oil” visible (b)
Page 59 and 60: Feedbacks from the novices of Culgi
Page 61 and 62: Chapter 6 Conclusion The goal of th
Page 63 and 64: Chapter 7 Bibliography [1] Craig La
Page 65 and 66: Appendix A. Class Diagrams Figure A
Page 67 and 68:
Figure A-4 Class Diagram of “Sequ
Page 69 and 70:
Appendix B. Tables Table B-1 Functi
Page 71 and 72:
Table B-3 Functionalities of Class
Page 73 and 74:
Table B-5 Functionalities of class
Page 75 and 76:
Table B-7 Properties of input param
Page 77 and 78:
Appendix C. DPD Simulation # DPD Si
Page 79:
$plot SetSize 400 400 $plot Load My
show all

Master's Thesis - Computer Graphics and Visualization - TU Delft

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?