System Engineering & Design Architecture by Sander R.B.E. Beals (important books to read TXT) 📕

“Give me the job of my dreams and I will never have to work a day in my Life!”

All through this document and the theory it is based on, we find that language is an essential part of the structure, if not the underlying tapestry it relies on. So instead of starting this with the hardware, we will start with the language, and then bootstrap that into the architecture of the hardware that is required to process this language. So Qualingo it is, but in fact I must confess I have only a vague idea of how this will pan out. It is just the faith I have in the key concept, that enables me to dive into this head first....

Let's recoup a diagram from earlier on: Qualingo has to address at least the six satellite topics on the right, in order to do what we want it to do. And if it is to survive on the Web it would be nice if we could give it its own prefix like 'http://' or similar ones. 'ql://' would be the most logical and simple choice, given Occam's Razor (see App. A).

Qualingo will be based on XSD, XSL and XSQ documents, where the following roles are played:

XSD contains datatype definitions.

XSL contains layout definitions.

XSQ contains Qualingo code aspects.

Since programming is a means to an end, we may assume that in order to reach the end, a request from the source of the problem (usually called the client system) is required. This system would send its problem solver an XQL document which states the essence of its problem, along with the URLs of the XSD, XSL and XSQ which are needed to solve the problem. For now this is the default way of working, just like we now call our programs, and give them the environment strings, parameters and other input required to have the program come up with a valid result. Future extensions might lead to requests that are incomplete, where the owner of the problem does not know the entire solution yet, or even how to get it: just remember the owner of the cell phone, who has no inkling of how his phone reaches the phone of another subscriber anywhere it is on the cellphone network. All he does is just hand the number over to the nearest cell tower, and trust that it will find his conversation partner.

The request is merely the red sphere in the diagram: program data to be used to solve the problem. Just like in normal program applications, we users know the numbers and words that make up the problem, and if we can't work it out ourselves, we usually know which program can. It is kinda like the event from my youth, where the teacher allowed us (for the first time) to use programmable calculators for the exam. I decided to not study for it, but instead design a program in my calculator's Basic language, that could solve any problem he might ask of us. In the end, I sat down for the exam, looked at the questions, and decided I'd refrain from just using the program, or I'd be done in ten minutes flat! So I did the problems with just the calculator part of my machine first, and then rechecked them with the program: all correct, ready in half the allotted time, and receiving an A+ because they upped the grade since the exam had been too difficult....

Now in our normal Personal Computer experience, we mostly ask a local program to do the work for us. And in a Web-enabled environment, the 'program' might well be a certain server. That is established programming, and very many alternatives are available to make solutions that solve problems either locally or across web boundaries. The boundary between these two options is rapidly fading, and a new approach that is identical for both environments, and which has the definition of its quality imbedded in it would no doubt distinguish itself on the market. Still, I'm not aiming for the market here, but simply for sharing information....

For a Qualingo system, the starting point of the program would be an XQL file either on a local drive or some web server. XQL is a variation of XML, where aside from references to an XSD and an XSL file, a reference to an XSQ file is also present. Based on that trio, the seven concepts of the above diagram are defined. Let's just go through the aspects one by one:

Program Data: the URL of an XQL document on the Qualingo-enabled system, along with the startup parameters. Pretty much like URL's are nowadays.

Version Info: this is not chosen by the user, but defined by which XSD's, XSL's and XSQ's the XQL file on the Qualingo target system references. Of course users may call different versions of the XQL document, but the XQL document itself decides which of the defining versions of the related documents it needs. Just see it as a computer that has all versions of its program still online, and just adds new versions to work out the kinks. Old users never get thrown off their version, although they may be warned that a newer version exists.

Config Info: This is basically addressed by the XSD's, XSL's and XSQ's themselves, in that they nest other documents. This is not for the user, but to the developers creating the program this ability is key, because this is how they create system classes in Qualingo.

Qualingo: the essence of a Qualingo Application. This is basically the XQL file that gets called, and the XSQ file it references. The XQL file is called by either a local or external system, and holds references to the definition, layout, and the XSQ file. The XSQ file then holds the various programming aspects, needed to solve the problem. This points to the following three types of:

Design Specs (QDS files): Since design specs are included in the files, they can be referenced one on one by the source code of the system: instead of having to refer to external links to other programs, without hardwired checking, the design specs become more like inline documentation. No more searching through the requirements in some other program, just point to the right XQL and give it the 'Display Requirements' request.

Source Code (QSC files): As you might have guessed by now, source code in Qualingo is a hybrid mix of seven types of documents, which in ideal situations describe one class of system at a time. Notice I'm saying 'system' and not 'object' or 'class': I'm hoping my document has given you plenty of hints at the differences between the them....

Test Specs (QTS files): Basically, these are defined by the requirements, and should be coded by the developers along with their implementation of the code. Instead of having this done by separate testers, this approach guarantees better matching of the tests to the code, also in maintenance: if a developer changes something that breaks a test, he or she is immediately alerted to that fact. There are multiple levels of testing: the system itself, the interaction between systems, and even connections to other computers that take part in a cooperative effort.

There are already plenty of programs allowing us to develop XSD's and XSL's. Any one of the companies marketing these could be approached to work out an environment where we can also edit the remaining types of files, thus coming up with a programming environment for Qualingo. Of course quite an effort must be spent first in defining the requirements for such a development environment, whether or not we decide to shoulder the entire programming effort ourselves....

In order to take you towards the architecture for a QL System, we are going to drill down from the software description mentioned above. So first of all, we need to define what a typical QL system would do, if let loose on the Web. And as the Tom Tom club is just now singing: "What are words worth?" But I'm afraid we're going to need a few to get this thing of the ground!

Remember, it is basically a web server with a twist. And like any web server, it can also be called from the local host system. But its functionality is neatly described in the SevenSphere on the right here, starting at the red sphere with the XQL Parser, and ending at the XQL Composer which eventually sends back the reply.

The XQL Parser is basically just like an XML Parser, but it can take three definition documents instead of just two: XSD, XSL and XSQ fully define the functionality of the software.

Inline testing is always executed, and will perform basic validations like variable range checking and stuff. These aren't the testing aspects mentioned earlier, but the normal stuff already done with just XSD and XSL documents today. The only addition made here, is that XQL documents may also have definitions which override those in the XSD documents.

Next up is the Integrity check, which is basically the execution of the defined testing methods for the various system application objects. This may be organized into various levels, which decide just how rigorously the system gets tested during its running of the program. For development it would be advisable to go into full integrity level, where normal execution might only switch on the most basic self tests that take far less time.

The Qualingo Processor then executes the