System Engineering & Design Architecture by Sander R.B.E. Beals (important books to read TXT) π
Read free book Β«System Engineering & Design Architecture by Sander R.B.E. Beals (important books to read TXT) πΒ» - read online or download for free at americanlibrarybooks.com
- Author: Sander R.B.E. Beals
Read book online Β«System Engineering & Design Architecture by Sander R.B.E. Beals (important books to read TXT) πΒ». Author - Sander R.B.E. Beals
http://www.youtube.com/watch?feature=endscreen&v=mT3vfSQePcs&NR=1
In a more military minded environment, Boston Dynamics has been developing Big Dog, Cheetah and even an erect walking humanoid robot. Since Cheetah was the most impressive to show, with it's speed of up to 18 mph, here is the video:
http://www.youtube.com/watch?v=EtVIh0bh-Sc&list=PL5896A1D4631F3B96&index=28
Or what to think of a real 3D display, which you can look at without the required glasses for the current consumer 3D televisions?
http://www.youtube.com/watch?v=eNWJ9XtRhLw
And if you thought Harry's invisibility cloak is magic, take a look at this Japanese invention initially done in 2003:
http://www.youtube.com/watch?v=PD83dqSfC0Y
And touch is a sense which can be far more varied than the current implementation used in most smart phones nowadays: TouchΓ© is an amazing multi-functional touch functionality:
http://www.youtube.com/watch?v=uanM3YGflVw
And why use touch if brainwaves can work just as well?
http://www.youtube.com/watch?v=q-fE9QBy0FI
Or why work with rough tools if you have the capacity to manipulate matter at the atomic level? Nanotech is no longer just Science Fiction, but Science Fact:
http://www.youtube.com/watch?v=sITy14zCvI8
Another piece of info you may have heard of is the work of Nicolai Tesla. A nice overview of what he achieved can be found here:
http://www.youtube.com/watch?v=h5uiK_QnyrE
Maybe you won't believe this last one, but given the movement of the inner mechanism of the three spheres in this next plane model, I figure we may also have a way to counter physical gravity:
http://www.youtube.com/watch?v=0YLhCuyE1rA
But I digress... We were on redefining the System, and that is what these next few pages are all about. First of all, I'll do a small intro on XML, for those who have never seen it:
XML in itself is equally suitable to represent as a SevenSphere: in it's simplicity it consists of Tags, Elements and Attributes, the last of the two being subsystems and properties of the System the tag refers to. Now XML entities are described in either DTD's, or in XSD's and XSL's, which separate definition from markup. In fact, since the DTD has sort of been replaced by the XSD and XSL, we have one sphere open to allow for newer stuff we might want to include with our Web-based Systems approach. So let's just claim that sphere and call it XSQ for now. The next bit is for the technical minded. Skip it if you don't know what I'm talking about, or learn more about it from our friend the all-knowing Web.
What I'm proposing is this: develop a new hard- & software architecture, which is able to process XML-based instructions and data. Since we can easily include the rules for Integrity into the structure that the XML and its defining documents provide for us, we will have the necessary information to make sure Integrity is maintained, without multiplying storage on the metadata: an XSD datatype for an integer might provide minimum and maximum values, which are valid for any Integer that claims to have the datatype as its defining structure. On the other hand though, the XML representation might well also have minimum and maximum values inside it, which would then override the ones defined on XSD level. By catering for the Integrity on the XSQ level, it becomes an essential part of the System, which hardware and software provide together. Configuration and Version information could then also be part of the XQL (because they use a certain version of the XSD, XSL and XSQ), thus linking the QA information in there as well.
For the building of more material stuff like buildings and bridges, and other cases where structural information is used to calculate the dimensions of the physical parts needed, the same description of XQL-based information would exist (the Model), but its outputs would be either a virtual representation on screen, or construction guidelines for the physical parts themselves (two different Views). In addition, the same XML construction data might be used to simulate 'virtual' abuse of certain structures in order to show a multimedia 'what-if' sequence of images in a movie environment. I mean: why crash a Bugatti Veyron into a concrete wall, when it's design specs can deliver you information about the way the Veyron crumbles if crashed into that same wall at 407 kmph? All these applications are merely different 'Views' on the basic 'Model'.
Another plus of using XQL to represent program code and data is that it is easy to move it from one location to another, or even to use it in a truly distributed fashion: like my representation on the Web would include my home address, and other programs (instead of always asking me for it) would be able to retrieve that data if I just reply to that request with my Personal Address object instead of having to fill in numerous fields which are already known on the Web. We may not want it accessible to everyone for now, but if we decide someone may have access to it, why not send an Address XQL object reference instead of filling in multiple fields by hand? Moreover, if we use this approach, the other party can just keep the reference to the object, and access it in the future until we tell them that is no longer permitted. But in the meantime, if we move, and change our address in the Source Address Entity, then all sites that have access to it can automatically pick up the updated address when needed. The same would be true for a CellPhone object, which would modify its GPS position as it picks it up from the GPS system. If we have the reference to the Phone, we may retrieve the GPS coordinates. With this direct access approach, the doubles in information will become obsolete, and we will also use less storage space: instead of our Address info being stored in numerous systems across the Web, it would only be stored once, and be referenced there when needed. Suffice it to say, that statistics kept on the various servers would more accurately reflect the interest in a given information entity, and the extra reference request would make sure recent data is used, instead of obsolete data. It is like now I have to visit a few sites to determine how many times their users downloaded my books, instead of being sure that all downloads reference the copy of the PDF files on my own domain server. It is just what you prefer, bandwidth or storage. Both are mere concepts, that have alternatingly been the bottleneck in computing. But the real bottleneck is in the quality of our systems, and their interactions.
Of course the whole XML Object Architecture would have similar exposure rules as files and folders on the Web have nowadays: public, group and user levels, and of course the exceptions to the rule: specific permissions set for specific users.
Since in the beginning there will be no hardware to do these computations on, we will have to build a simulated platform that will do the calculations based on a 'normal' von Neumann based computer. Since we want distributed capabilities to be essential to the System, we might devise a simulation layer on top of a web server like IIS7 or an Open Source alternative, which will make sure we can communicate requests to other systems, and receive answers from them. These will in fact be variations on XML requests, that represent the various classes and objects, and the messages that occur between them. Once the hardware becomes available, it will provide this same functionality on the Webserver level, but will need no translation to the target platform anymore, since that is no longer Windows, Mac or Linux, but a generic Server Operating System that speaks to both Webserver, user interface and hardware in the same XQL language.
Of course, the starting point for an XQL application may well be a QR-code found somewhere in the material world. Since QR code is a patented system where the patent has been published and not been actually enforced, QR code has become a popular mechanism to get URLs or other data into computers (and phones) quickly and error-free. It was originally designed to enable reading of configuration labels on production materials in a manufacturing environment, but due to its capabilities became the number one method for ubiquitous tags in the environment, as was predicted by some web page I read somewhere back in '92 or so. Sure, like every tool man has ever made it can be used for both good and evil, but let's just stay focused on the positive here....
Where do we go from Here?
OK, so we've set ourselves one Hell of a Challenge: using an extension to XML as a language that is both program source code, configuration informa-tion, data and documentation. No doubt we could add two more possible uses for it to this list, in order to make up another SevenSphere. How about design specs and test methods? Sure, stuff like Visual Studio allows us to define tests during development, but they never leave the develop-ment environment. And even the external black box testing of the entire program ends at the door of the software company.
Now all of these constituent parts are not mere values, but self-contained pieces of XML which define their own structure. Where the 'design' is mostly defined in the XSD's, XSL's and XSQ's, which we might regard as class information, the actual runtime values are in the XML-like code itself, which can be regarded as the object information. Since XML documents usually are identified by the URL through which they are reachable, we can easily identify them unambiguously. The same goes for XSD's, XSL's and XSQ's. For all of these, the Source is well-known, so to say. And version numbers are often used in the URL to discriminate between the various versions of these definition documents, so that aspect is also taken care of. Design Specifications can be fleshed out using the various simple operations mentioned before, until they are sufficiently detailed for the process of design and implementation. That basically produces the Source Code and the Program Data, which is required to run the program. Also, the design specs and even the implementation of the Source Code will be inputs for the Test Methods, or rather the black box and the white box tests respectively.
Since the discoverer of a new phenomenon has historically been allowed to name it, I guess that honor is mine this time. Since the essence of my plan is to incorporate Quality into Systems Engineering, Design and Architecture, I guess 'Qualingo' (or QL for short) is as good a name as any, since it gives us Quality in 1 (often confused with the letter 'l') go.
Will I be able to follow up on this plan? Who knows.... You need only one solid chance at getting it right. Thousands may read it and think me a bit flaky, but only one visionary with enough business influence is needed to make my day job the job of my dreams. And since our company has recently been taken
Comments (0)