Fedora Linux Support Community & Resources Center
  #16  
Old 13th May 2014, 09:11 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Architecture, Part 4

This is the final form of our architecture document, describing the interfaces between the modules. Getting the interfaces correct early in the project will contribute greatly to the likelihood of success.

One of the things that makes a large project much more difficult is that you can easily get into a situation where every change ripples through the entire project, triggering even more changes. The mathematics of the model for this is the same as the mathematics of chaos theory. One approach to fighting this is to do nightly builds, or even continuous builds in the hope that the faster processing will smooth out the chaos. Unfortunately its not the compiler that needs to be kept up to date, but the programmers and it can often take a long time time for the notification of interface changes to filter down to the programmers that need to know, and the longer that delay, the more likely it is that chaos will ensue.

An alternative is to ensure that you don't actually have one large project, but rather a collection of independent smaller projects. To make this work you have to have well defined and very stable interfaces between the sub-projects, hence the emphasis on interfaces in the architecture document.

My idea for the development process is to provide a stub implementation of the interfaces at a very early point in the process. This has the additional benefits of giving the programmers something to work on while the detailed design is being done, and a solid infrastructure for the test team to build their test harnesses to.

On a larger project the architecture document would provide views of the system from many different points of view. In addition to the application view we provided for Vici you might find a network view showing how the modules communicate over the network; a database view setting out all the different databases that the system will use; a project view for the project manager to plan the resources required and estimate the time and effort required; a hardware view showing the equipment required; and so on. It will also provide a set of scenarios for the test team to use to demonstrate that the quality requirements have been met.

One of the problems in constructing the architecture is that the information for the various points of view can end up spread throughout the inevitably large document. This can lead to things being overlooked. An alternative is to produce separate volumes of the architecture for each view point, but this can lead to the different documents getting out of synch and leading to problems when the system is being assembled. I have done some work in automating the construction of the document based on the contents of a knowledge database, but that is a story for another time.

Next time we will look at the first bit of code.
Attached Files
File Type: pdf vici-architecture.pdf (305.9 KB, 155 views)
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #17  
Old 17th May 2014, 07:52 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Infrastructure

On one project I worked on it was considered necessary to spend about 100 person years of effort to build the infrastructure required to support the applications. This was in the early days of web applications, so the frameworks that we now use did not exist and had to built as part of the project.

Unsurprisingly the client paying the bills got cold feet and pulled the plug at about the same time as the first application was going on-line. A huge cost for no discernible output does tend to scare the bean counters.

If I was confronted with something similar today I would recommend what is sometimes called the spiral development model. Instead of a large up-front development of infrastructure and no user functionality, the idea is to develop the infrastructure in parallel with the applications. This is done by using the “quick and dirty” approach to the first cut of the infrastructure, and starting with the simplest of the applications. The infrastructure only needs to support the first few applications and can use whatever works to get the job done – scripts instead of programs, text files instead of databases, support 1 user instead of thousands – what ever it takes to demonstrate the functionality.

Once the client can see some functionality they are considerably more likely to keep the funds flowing. The danger is that the first applications will be of such low quality the project will get cancelled, so it is imperative that they be sold as demonstration versions only and not allowed to go into production until the infrastructure becomes sufficiently robust.

For Vici we don't have any large infrastructure components, but there are a few things that I find help on larger projects:
  • I like to wrap the libxml2 library in a C++ wrapper class which can then be specialised for specific purposes;
  • A configuration library that uses XML to store the configuration data is useful;
  • A nice configurable logging component that can write nicely formatted messages to a range of logs can make debugging easier;
  • I have an interesting exception class that I find simplifies the coding of error messages;
  • The ability to trace execution flow is useful when building complex object oriented systems;
  • A standardised manager for testing will help when building test harnesses.
Over the years I have collected these into a library I call the Common Facilities Infrastructure, or libcfi. I have added it as the first bit of code for a Source Forge project:
http://sourceforge.net/p/ocratato-vi...tree/trunk/cfi

I find that a Programmer's Guide to be a useful document. Apart from things like coding standards it is also a useful place for things like the instructions for setting up the Eclipse IDE, or describing how to use CFI library:
http://ocratato-vici.sourceforge.net...mers-guide.pdf
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.

Last edited by ocratato; 16th October 2016 at 06:11 AM.
Reply With Quote
  #18  
Old 19th May 2014, 08:52 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Use Cases

As anyone who has studied object oriented design principles will know the “Use Case” has become a very important part of the design process. Unfortunately a lot of what is written is nonsense. It is often proposed that use cases be drawn up as part of the requirements analysis, prior to any architectural design work. Such use cases will all too frequently assume some particular design for the proposed system since it is hard to describe interactions with a system if you have no model of what the system is going to be like. This can then prevent the architects from investigating novel alternatives.

My view is that the use cases done for the requirements analysis should be done in the most broad terms possible so that innovative designs are not precluded. Once the architecture has described the general solution we can now describe in detail how the users will interact with the proposed system. We can also include a cross reference from the responsibilities to the use cases so that we can be confident that nothing has been overlooked.

These detailed use cases provide a description of how the system will be used which feeds into the detailed design of the applications. It is also an excellent starting point for the design of the test harnesses.

The uses cases for Vici can be found at
http://ocratato-vici.sourceforge.net/pdf/use-cases.pdf
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.

Last edited by ocratato; 16th October 2016 at 06:14 AM.
Reply With Quote
  #19  
Old 22nd May 2014, 01:21 PM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Interfaces

Time for some more coding

One of my aims for Vici is to demonstrate how to build a large system by combining several smaller projects. In a commercial development project you could have separate teams for each component, each responsible for its design, development and testing. Doing a dozen components in parallel will cut the overall development time significantly. Of course this will only work if the components can be developed independently, otherwise everyone will be chasing everyone else to get things fixed before they can proceed.

On one large project that I was working on as an ordinary developer the architect was becoming increasingly concerned that there was a lot of interactions between the components of the system that were rippling through the entire design. He decided to build a diagram showing the dependencies between the components – imagine a diagram with 50 or so nodes, and every node connected to every other node ! When we saw the result we realised that for a system of any significant size it is imperative that the interfaces be carefully laid out first. (The project was eventually abandoned for other reasons, however I expect that it would have never stabilised to a working system.)

For Vici there is a design document that shows the relationships between the classes that are the façades the components of the system. It also shows the public interface for each of these classes and some sequence diagrams showing the messages between the modules for the use cases that involve multiple modules. The document can be seen here:
http://ocratato-vici.sourceforge.net/pdf/interfaces.pdf

The code consists of a header file (vici.h) that forms the glue that holds the entire system together. It allows each module to see the public interface of the other modules. There is a library (libcc) that provides an implementation of the objects that are passed between modules. There is a library (libifstubs) that is the software equivalent of scaffolding. It provides just enough of each module to satisfy the build. Finally there is a configuration library (libconfig) that allows each module to be built in isolation with test harness versions of the modules that it interfaces to. A particular configuration can be selected by passing a parameter to the configure script.

The code is here: http://sourceforge.net/p/ocratato-vi...unk/interfaces
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.

Last edited by ocratato; 16th October 2016 at 06:16 AM.
Reply With Quote
  #20  
Old 27th May 2014, 06:00 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Persistent Storage

Most projects need to store some data to permanent storage. Sometimes this is used to pass information between components of the system, but I would describe such usage as part of the interfaces. Here we are interested in storing data for later use.

There are a many techniques that can be used for data storage, from full relational databases to simple text files. Selecting the most appropriate for a particular project is part of the architectural design. In the case of Vici we have come down in favour of XML for the three different stores that we will need. Our task here is to specify the layout of the data (also known as the schema).

There are several alternatives for defining the schema of an XML file. The first was the Document Type Definition (DTD). Later an XML format was defined for the schema itself. I have chosen to use DTD s for Vici's schema since they are much easier for humans to read.

An XML file can include a reference to its schema. This allows the software to validate the XML which will probably prove to be useful.

The usual method for having an XML file find its corresponding DTD is to include a SYSTEM reference URL in the DOCTYPE element. This works fine if the DTD can be placed in a single well known location, which normally implies somewhere on the web. Of course this doesn't work if the network connection is unavailable, and it makes the development process a bit more complex.

The alternative is to use the PUBLIC identifier in the DOCTYPE element. This identifier is used by the XML library to find the corresponding DTD in a catalogue file that is in turn found via an environment variable: XML_CATALOG_FILES.

This alternative mechanism will be used by VICI.

The design document for persistent storage can be found here:
http://ocratato-vici.sourceforge.net/pdf/persistent.pdf
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.

Last edited by ocratato; 16th October 2016 at 06:20 AM.
Reply With Quote
  #21  
Old 1st June 2014, 04:37 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Application Design

There are many many books on the subject of software design. If I had to recommend a couple then Grady Booch “Object Oriented Design” and Bertrand Meyer “Object Oriented Software Construction” would top my list. Unfortunately none of them have a fool proof recipe for designing an application.

The main problem with software design is that it is difficult to validate the design without building the software. If I am designing an electronic circuit I can calculate the currents and voltages, the power levels and even the temperatures of the components before any construction is attempted. Similarly a civil engineer will calculate all the stresses, strains and tensions in the structure. For software there are a few attempts to formally validate it, but these are usually confined to very special purpose projects, and then often only for a subset of the software.

There is an old adage for those attempting something new and untried - “Throw the first one away.”

My approach is to use that idea to help build the software design. I will be developing software prototypes as part of the design process. These can validate the design, and the resultant program can be used to generate some of the design documentation.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #22  
Old 6th June 2014, 08:45 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Testing Strategy

Once upon a time the process for testing software was to finish the coding and then pass the results to the test team who would put it through its paces and write reports about what they found. Often, by the time the reports were done the development team was well into their next project and had little interest in going back to something they considered finished months ago.

For Vici we are using a Test Driven Development approach. The testing becomes an integral part of the development process and can be started as soon as the architecture is defined. In fact some implementations of the architecture task include defining scenarios for testing the quality requirements specified for the system.

An important aspect of the modern testing methodology is that the testing should be automated as far as possible. Often it is necessary to repeat the tests several times and if this is done manually then it becomes very easy to skip tests or fail to notice variations in the results. Thus the first task we have is to design the way in which the testing can be automated.

The unit testing forms the basis for all the testing. If the functions and classes are good then the higher level testing can concentrate on interfaces and other wider issues. The aim with all testing is to find problems – a successful test is one that finds a problem – which is a hard thing for a programmer to do. The testing needs to be automated, and preferably the test cases need to be set up before the code is written. Most unit testing can be done from test programs that include the object files for the main program. Some classes will need additional methods defined to support testing.

The testing of each component will attempt to find problems with interfaces to the other modules. We will use the defined use cases (that are applicable to the module) and the module's responsibilities to define the test cases. We can extend the interface stubs to provide test cases to test the interfaces to other modules. For those modules that have a user interface we need a mechanism to activate the GUI controls from some form of script. Fortunately the Qt library includes methods for triggering widgets so this should be possible.

The final testing is to demonstrate that the system works in the environment that it is designed for. In the case of Vici we need to test that it works for a range of distributions and desktop environments. To show this we will run through the use cases that have been defined in a set of virtual machines set up for the tests. These tests can be automated using the same mechanism as the user interface tests for the modules.

The testing for the final programs will need some support code that is of no use otherwise. This can be handled by loading a shared library at run time and executing the test code therein if the program is run in test mode. Using this technique we can fully test the program in its final form with very little overhead imposed on normal usage.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.

Last edited by ocratato; 13th June 2014 at 07:17 AM.
Reply With Quote
  #23  
Old 13th June 2014, 07:23 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Design of Parser

Our first design is for the parser that validates the description for the options for a command. This was chosen as it is a small and relatively simple component that we can use to validate our techniques for the design process.

There are several ways of building a parser, such as by using lex and yacc, or other code generators such as SableCC, but I have always liked doing my own recursive descent parsers, and in this case the language is very simple so it will not take much effort to write compared to the added complexity of including the code generator in the build process. Additionally I have a lexical analyser that I can recycle from another project to save a bit of time.

For the design we will be doing some prototype coding. To keep track of this I set up a branch in the Subversion repository called “proto”. We will do our design prototypes in separate projects in this branch. (The branch will never be merged into the trunk.)

The design includes a Token class and a Lex class that read the source and create a sequence of tokens. One of the features of Lex is that it keeps the tokens and has a method that allows us to back-track to a previous token. This allows the parser to try one alternative and back up and try
an alternative if it needs to.

The vici.h file defines an abstract class, EBNF, that defines the interface for this component. We now derive an EBNF_Impl class to provide an implementation of that facade and manage the parsing process. The remaining classes correspond to the elements of the language with each one attempting to recognise its part.

The output of the library is a parse tree that contains the details we need, i.e. the options and their order. Alternatively the library must produce suitable error messages if there are errors in the text.

Once the design code has reached a satisfactory point it can be used to help document the design. Note that this code is not very robust in that it has only a minimum amount of error handling and does not worry too much about cleaning up. I used Dia to capture the static relationships between the classes. The function tracing capability was then used to capture the collaboration between the classes for major use cases. Finally the class declarations were pasted into the design to provide documentation of the public interfaces for the functions.

The design document and the collaboration diagrams are attached. The collaboration diagrams have been processed by an XSL script that converts them into an animation to allow better visibility of the sequence of events. The Firefox browser can display the animation.

The prototype code for the EBNF parser is here:
http://sourceforge.net/p/ocratato-vi...hes/proto/ebnf
Attached Files
File Type: pdf libebnf.pdf (205.0 KB, 143 views)
File Type: svg ebnf-parse.svg (10.7 KB, 130 views)
File Type: svg ebnf-val.svg (49.7 KB, 137 views)
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #24  
Old 20th June 2014, 03:38 PM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Design of Syntax Library

The second design prototype is the library that displays a syntax chart for a command's options and parameters. This was chosen as it has a fairly simple GUI interface that will allow us to confirm the build process for components that use the Qt library.

The Qt library is a very nice GUI toolkit, but it does require the use of a separate code generator program, called “moc” that generates some code to handle what Qt calls signals and slots. These are a way of having indirect calls between components which can make the interconnection of the various widgets much simpler and remove a source of interdependency between classes. There is also another code generator, “rcc” which is used to embed graphics for icons into the application binary, which makes distributing the program significantly simpler. Integrating these into the autotools make system is one of the tasks for this prototype.

The second reason for choosing this component is that it will give us some practice with drawing and managing shapes on Qt's drawing canvas. I found this to be a bit confusing as each object has its own coordinates, except when objects are being combined.

The actual code is quite straight forward. A set of primitives (arcs, line segments, boxes) are composed into a chart, and then recursively combined into more complex charts according to the input parse tree.

The design document and the prototype code can be found on Source Forge:
http://sourceforge.net/projects/ocratato-vici/
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #25  
Old 28th June 2014, 01:20 PM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Design of Command Library

The next prototype is for the command library that allows the user to enter the command name and its parameters. For the most part it is a relatively straight forward GUI.

The interface is intended to be displayed when a user double clicks a box symbol on the chart. It is supposed to provide some guidance on setting the options for a command – I suppose we will find out how successful the design is once we let some users loose on the application.



The interface has a couple of lists at the left. The first allows the user to select one of the prepared commands. They can, also just type any command into the command entry field. The second is populated with the options and parameters applicable to the selected (prepared) command.

An entry list, under the command entry field allows the entry of options. Some time was spent trying to get drag-n-drop working so that the options could be re-ordered. The user can either double click from the option list, or double click in the entry list to add an entry.

The right hand side of the interface has space for a syntax chart window and above it a window for help text. My initial idea was to take the source files of the help text and simply display it in a text dialog. I started with man pages and was going to run a program to convert the man page source into an HTML document and display that in the window. However, when I came to looking at doing this for info pages it all came a bit unstuck. Unlike man pages there is no source for info pages installed on the user's machine, and I would have to download all the sources and process them into a form that could be used by the program. This seemed to be more complexity than I wanted. My final solution was to simply run the man and info programs in an xterm which is embedded in a window of the interface. Fortunately the xterm program is designed to support this, and the Qt library provides a suitable widget for embedding an external application.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #26  
Old 6th July 2014, 06:52 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Search Library

One of the problems that Vici aims to help with is finding a suitable command. Linux has thousands of command line programs, and many have names that are not particularly mnemonic. To assist the user Vici provides two approaches – key word search and classification search.

The keyword search is used to find a command that has the search term in its description. The user can search either the descriptions of Vici's prepared commands, the short descriptions in the man pages, the descriptions in the desktop files (for installed GUI programs) or the descriptions of the installed packages. The latter two are not strictly useful for finding command line programs, but seemed like a useful addition.

The classification system allows the user to search a hierarchy of tags that are associated with the programs. For example the grep program would be tagged with “text” and “search”. The user can construct simple expressions to find the union or intersection of tags, and even put the result back into the classification hierarchy.

The user interface for the component:



The “link” and “unlink” buttons enable the forming (or breaking) of associations between the programs and the tags. The last two selected tags can be used to form a boolean expression using the Venn button at the lower left, and the result can be saved in the list at the far left.

The main difficulty designing this component was understanding the drag-n-drop processing. Tags can be moved, or copied, within the classification tree, and also tags can be dragged into the classification tree from the left side list.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #27  
Old 14th July 2014, 05:01 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Asynchronous Testing

Now that a couple of modules have their designs done we can proceed a little further with the design of the testing infrastructure. One of the aims of this project is to demonstrate how a large system can be subdivided into separate smaller projects that can be developed independently. It would seem that the testing is going to break that ambition as the test module will be a dependency for all of the other modules, and some details of the test module will be dependent on the design of the other modules.

The Test Manager class that we defined in the Common Facilities Infrastructure module assumes that we can set up the initial conditions, perform a test, and then immediately check the results. However, there is some code in the Command modules where this approach will not work reliably. The function to validate a command works by starting an instance of the “which” program and once that completes putting up a warning message for the user if there is a problem. For some classes this could be tested by putting in a wait that was long enough for the external process to complete. This can result in test failures due to the wait not being long enough. It is also not very practical if the results are all local variables which may not exist when the test results are checked.

Since this style of asynchronous processing is going to be quite common in Vici we need a better approach.

The AsyncTestMgr solves this problem by running a separate thread that responds to events on queues. We can therefore set up a test by queueing up a test object which initiates the testing. We add a macro to the code under test that expands to a function that queues an event and then pauses the code. The test object can then perform the required tests while the code under test is in a well defined state. The macro can expand to an empty statement when the testing has been completed.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #28  
Old 20th July 2014, 05:08 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Notes for GUI Testing

The usual approach for testing a GUI program is to create a document that describes the actions a user is to do when running the test. The problem with this is that it is a manual operation which is therefore unlikely to be carried out as often as it probably should be.

Another approach is to perform the test manually and record the mouse and key events so that the test can be re-run at a later time (and as often as necessary). The main problem with this approach is that it is very difficult to have the test respond to variations in the response of the program. I once spent many days trying to script an expensive GUI test program that worked like this – we even got the vendor's expert to come and show us how, but after he spent all afternoon and failed to automate the Windows start menu we began to have doubts. We sort of got it working eventually, but never as well as the architect thought we should have been able to do.

The Qt library includes an ability to trigger mouse and key events for widgets. We can use this to build a GUI scripting component. The idea is that each type of widget will have a small handler class defined that can interpret some commands and apply them to its widget. When in test mode the program will load a test library that will load a shell script that will echo these commands and cause the actions on the widgets. Commands can also be created to query the state of a widget and pass that back to the script so that it can vary its actions according to the application's responses.

To make this work each widget needs to be given a name and associated with a handler object. This is the only thing that needs to be done differently for the program being tested. (It is important that the program under test should not be significantly different from its normal state.)

You can see the details in the Test Plan document attached.
Attached Files
File Type: pdf vici-test-plan.pdf (148.8 KB, 103 views)
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #29  
Old 27th July 2014, 06:42 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Interpreter, Part 1

The first few component designs were selected as they were relatively simple modules. This allowed us to ensure our procedures were working. Now it is time to try to do a design for the core component of Vici, the interpreter. If we cannot do this the entire project becomes a bit pointless.

The interpreter will have two aspects. It will have a static structure that mirrors the flow chart, and a dynamic structure for the running processes. These need to be separate since a flow chart may include a sub-chart as a function, and this may be called and run in the background several times simultaneously – hence the dynamic structure may be quite different from the static structure.

The first task to develop is the static structure of the script. This will mirror the flow chart diagram in its structure but will be made up of objects that implement the concepts that the chart symbols represent. Hence we will have classes for Command, File, Variable, etc.. These objects will be created by a factory class that interprets the XML representation of the script.



The inheritance relationships are shown in the diagram. A Channel represents a pipe that connects a source to a sink. I have made variables sources and sinks so that they can be placed at the end of pipelines. This turns out to be quite an important feature since it is not really possible to use the output of a pipeline as the parameter to a command – like the back-quote or $(command) of bash – since the flowchart has an explicit flow of control and the $(command) parameter would require an implicit flow of control, or allow some really bizarre constructs that would be difficult for the user to understand and for me to implement.
Attached Files
File Type: svg interp-static.svg (32.7 KB, 115 views)
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #30  
Old 3rd August 2014, 04:40 AM
ocratato Online
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,476
linuxfirefox
Re: VICI: A Software Development Project

Interpreter, Part 2

For the most part the script interpreter will start other programs to perform operations, however, there are few things that cannot be done that way, or are more efficient to do from within the interpreter. The following have been identified so far as being necessary or desirable built-in commands:

cd – this changes the working directory of subsequent commands. This must be a built in command as it would be impossible for an ordinary command to alter the working environment of commands that it is not the parent of.

dup – this copies its input stream to both its output and error streams. This is similar to the tee command but it seems like it would be more useful for a flow chart to use two output streams.

echo – writes the values of its parameters to its output stream. Not strictly necessary but makes a good test for the built in command processing.

export – this adds a new variable to the environment that is passed to subsequent commands. As with cd, this one is necessary.

for-each – this breaks up its input stream and runs the following commands for each element.

for-each-line – as above but for lines of the input stream. This, and for-each, are implemented with a separator character set to either white-space or new-line. The commands executed for each element are given their own context so that, for example, a cd will only apply to those commands.

let – performs simple integer arithmetic.

read – this reads a line of input and assigns the values to variables (similar to the bash read command). This must be a built in command since it modifies the interpreter's variables.

return – this just exits with an exit status equal to its only option. Since there is no “next command” it has the effect of terminating the thread of control within the interpreter (either the main thread, or a function running in the background).

signal – this sends a signal to the process that it is connected to. That sounds fine until you realise that the connection on the flow chart diagram is to a command, not a process, and that a command might be executing many times simultaneously if it is in a function running in the background. To keep some organisation I decided that a signal can only be sent to the commands within the same function scope (which also simplifies the diagrams) and the signal is only delivered to those processes with the same context as the signal.

switch – this has a return code that indicates which option matches the first option. This seems like a better idea for the flow chart. It relies on the flow of control lines on the chart being able to be given a specific exit code.

The function call is also implemented as a built in command. Like the for-each command it creates a new context and passes control to the first command of the named function. The options are passed as numbered variables (similar to bash).

There are two commands used for synchronisation between threads of control. The mutex command has lock and unlock which is used to ensure only one thread is accessing a section of the chart at a time. The semaphore command can force the script to wait until another thread posts to the semaphore.

Finally there are two anonymous built in commands used to read and write from/to variables so that a variable can be placed at the end of a pipeline.

PS
I would like to thank those that have viewed this thread. It is giving me some encouragement to keep going on this project - thanks.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
Reply

Tags
continued, development, project, software, vici

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Web Development Software Pepperonie Using Fedora 2 5th May 2007 10:56 PM
Development software for Linux jo3 Using Fedora 9 15th June 2006 03:28 PM
Software Development handshakeit Using Fedora 0 5th October 2005 08:40 AM


Current GMT-time: 02:00 (Friday, 24-03-2017)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat