|
The Future Proof Enterprise |
 |
||||||||||||||
|
|
|||||||||||||||
|
The Future Starts Here
When anybody builds anything for the first time they want it to last forever. Why should software be any different?
Now, it doesn't have to be. Here's how... |
|||||||||||||||
|
|
|||||||||||||||
 |
 |
 |
 |
 |
|||||||||||
|
|
|||||||||||||||
|
What's the big idea for future proof software?
Building future proof software in the face of constant change has always been thought an impossible task, but now there's a clear way forward.
The idea in a nutshell is to use the Matrix modeling language to build an executable model of the application's business logic. At the same time build another executable model of the application's software architecture. This step creates a model compiler almost as a by-product. Lastly, feed the model compiler with the business model to generate the application's source code.
So if the technology changes simply update the model of the software architecture and regenerate. |
|||||||||||||||
|
|
|||||||||||||||
|
A solid foundation is key to a solid future
Each wall begins with a single brick, a foundation stone. Once laid, all the other bricks must be set relative to its position and direction and thus it determines where the future wall will be built.
Software projects also need a foundation stone, an overarching guide that sets the principles, method and strategy for future development.
Here we introduce Matrix, a powerful technology that establishes the way forward for software development for the next 100 years and beyond.
Matrix gives any project a solid foundation by providing the means for keeping the essential working of a project in a form that remains constant but also equipping you with the future technological flexibility that you need.
|
Delving Deeper into Matrix
|
||||||||||||||
|
|
|||||||||||||||
|
How do I future proof my project?
It's based on a really simple idea but it's taken many years of hard work to make it happen.
In a nutshell, the idea is to totally separate your business rules from your implementation code.
That means if something about your business changes, update the business rules not the code. If the business rules don't change but the technology does, change your code solution, not the rules.
|
|||||||||||||||
|
|
|||||||||||||||
|
How does the future proof process work?
The process works by building models. One for the application you wish to build and another for the environment in which you need the application to operate. Of course, our models are no ordinary models; they are future proof by design.
Models created with Matrix are rigorous, unambiguous and complete to such a degree that 100% of a system's source code can be directly generated for any software architecture and in any language.
Matrix models become strategic long life assets.
|
|||||||||||||||
|
|
|||||||||||||||
|
What's the secret of future proof software?
In two words,
After a long period with relatively little innovation in the field of Executable Modeling, we have made a number of exciting breakthroughs.
Our Matrix Technology makes real these new insights in a sophisticated and pragmatic software development product:
The Matrix Modeling Language
Now, for the first time in many years, your project has the opportunity to make a significant improvement to its own software development process.
With Matrix, Business Analysts are able to create complete executable solutions that withstand the test of time.
|
|||||||||||||||
|
|
|||||||||||||||
|
How can I change my application's language without updating its code?
If you're talking about your application's code built according to the rules of your business then it's entirely possible. In fact, to us it's routine. And it gets even better than that...
Not only will you be able to update an application from an old computer language to a new language but you could also update the application's architecture in the same way. It could use another database, distributed networking facility or even move from a single-core CPU to multi-core processing, all without changing your application model.
Matrix demands that the application and software architecture be totally separate. This means that if the business rules change only the application model need change. If the technology you use to implement the application changes then only the software architecture model changes.
|
|||||||||||||||
|
|
|||||||||||||||
|
How can Business Analysts create complete executable solutions?
Analysts use Matrix to create precise, computationally complete models that become fully testable specifications.
The software method employed in our Matrix Technology is based on the Shlaer-Mellor Method and the later Executable UML. The method uses well known and well established modeling techniques such as the relational theory of data, finite state machines and Petri nets.
Unlike most other executable UML modeling solutions, Matrix models are purely textual. In fact we sometimes refer to Matrix model text as code.
Of course, it's very useful to draw a model in a UML tool to help visualise a system. Fortunately, each of the major components in a Matrix model easily map to a UML diagram.
For example, parts of the Matrix language that describe entities, attributes and relationships map to the UML Class Diagram. Similarly, statements specifying an entity's life-cycle map to UML's State Chart.
Matrix comes with a built-in simulation environment that's automatically tailored to each model. Full functional testing (and regression testing) can be performed under the Simulator which reads commands either on an ad-hoc basis from the command line or by running scenario scripts.
|
|||||||||||||||
|
|
|||||||||||||||
|
I also need a faster, better and cheaper development process
The eternal software development triangle for project success:
Better. Faster. Cheaper. Pick only two. But what if you need all three?
Matrix Technology makes possible a development process that produces better systems faster but with less work while still retaining the ability to port to any technology platform that's going to be available in the future. A platform that will be a lot faster, a lot more reliable and a lot cheaper.
You stay competitive if you can move your system on to future platforms quickly because if you don't somebody else will.
|
|||||||||||||||
|
|
|||||||||||||||
|
How does future proofing deliver business value?
Every business would like to preserve its investment in understanding its own policies, rules and processes. This knowledge is typically held as long established manual procedures or spread over computerised systems.
The problem is personnel and computing technology changes rapidly while your fundamental business principles do not. Ideally a business would like to hold that knowledge in a standard form that does not change even when the implementation technology changes.
A further requirement should be that the business be able to reuse that investment on future computing platforms even though they are yet to be invented.
|
|||||||||||||||
|
|
|||||||||||||||
|
What are the benefits for stakeholders?
Besides from being better, faster and cheaper, executing and testing a development version of the model very early in the development phase demonstrates to stakeholders that their requirements are understood.
Both stakeholders and developers will gain confidence in the project when they see the model running scenarios showing some or even all of the behaviour expected in the final deployed system.
|
|||||||||||||||
|
|
|||||||||||||||
|
|
|||||||||||||||
|
How exactly does Matrix Technology lead to productivity improvement?
With an executable model as the primary asset there is no longer any need to maintain source code because it's all generated.
With conventional development most of the errors that are detected during lab tests are found to have been introduced in the manual coding phase. By eliminating a manual coding phase those errors are simply not introduced.
With the improvement in quality through using a Model Compiler to generate source code, we automatically get an improvement in productivity because we don't have to fix all the mistakes.
But the greatest increase in productivity improvement is simply obtained by raising the level of abstraction. By moving from programmers writing source code to analysts creating Matrix models a business builds solid flexible assets with the potential to accommodate any change in business requirements and any change in technology.
|
|||||||||||||||
|
How are the long term benefits realised?
Present day code is often platform specific and dominated by technology and is rarely understood by stakeholders.
Maintenance of a very large code centric system over many years inevitably causes an increase in entropy and the code descends into chaos. Eventually the decision has to be made to throw the code away and write it again.
"A code based legacy is not a long life asset"
Matrix brings many solid engineering practices together with new precise modeling formalisms to make better systems than has ever been done before.
|
|||||||||||||||
|
|
|||||||||||||||
|
How is a software architecture defined in Matrix?
In Matrix the software architecture refers to the architecture to be used by the application. Although the software architecture is a model of the design of an application, the architecture is actually an analysis model.
In most projects the software architecture, if discussed at all, is usually a nebulous set of aspirations and ideas. However, in Matrix the software architecture becomes something that can be defined in a formal way and reasoned about.
The software architecture is typically composed of a number of domains. Some domains are to do with the analysis formalism itself. Other domains may be concerned with the implementation. For example, Databases, Networking Facilities, Hardware Devices, Operating Systems and Language Templates domains.
A model of the software application architecture is also the model of a Model Compiler that will generate source code for the application.
|
|||||||||||||||
|
|
|||||||||||||||
|
A Model Compiler is simply a code generator that generates all of a project's souce code from a model without employing programmers.
It takes as input, a model of the business application and generates a complete working system. Matrix Model Compilers are constructed from the same software architecture that the application is to use.
The Model Compiler ensures all generated code is fully integrated and fits together perfectly. As a direct result no unit testing is required since the source code is verified by design.
|
|||||||||||||||
|
|
|||||||||||||||
|
The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.
Edsger W. Dijkstra |
|||||||||||||||
|
|
|||||||||||||||
|
How does Matrix deliver long term reuse?
In Matrix, reuse takes place on the medium and large scale.
Reuse on the medium scale with domains is probably the most useful form of reuse within Matrix. A domain is determined by identifying a distinct subject area or area of concern in which the entities are closely (semantically) related. Reuse at this level is effective because a subject matter domain naturally minimises the interface it presents to other domains in the system.
Large scale reuse is the most powerful brand of reuse and involves two types of systems.
The first is the reuse of a Model Compiler which is a software architecture made real. A Model Compiler is designed to process any Matrix application business model and produce a working system. For example, a Model Compiler designed to target Windows can generate working source code from a Stock Control Model or Library Management System Model.
The second type of large scale reuse is the wholesale reuse of an application model. Any Model Compiler can process any Matrix application business model and produce a working system. For example, the one and the same Customer Relationship Management application model can be submitted to a Windows target Model Compiler to produce a Windows application and be submitted to an Android target Model Compiler to produce a mobile app.
The small scale reuse of entities has proven to be largely a failure for the same reasons that reuse at the domain level is successful - the entities are closely related. The problem becomes apparent when an attempt is made to extract an entity, demanding that all its relationships must be pulled out too. Of course, this means more entities have to be extracted and before long the entire domain is implicated.
Both medium scale domain reuse and large scale application model and Model Compiler reuse are much more powerful than the reuse of source code.
|
|||||||||||||||
|
Why is raising the level of abstraction important and how does it work?
To answer this question we first need to consider what models and programs actually are and their place in the history of continually rising levels of abstraction above machine code.
Machine code is considered to be a First Generation Language (1GL) since it specifies instructions that are directly executed by computer hardware.
Assembly languages are referred to as Second Generation Languages (2GL) and represented a jump in abstraction level away from pure machine code. Assembly languages were the first level of programming that required a language compiler to generate machine code.
2GLs allowed a programmer to symbolically manipulate information. For example, move data from one named location to another; add or subtract data to a memory location or jump to an instruction out of sequence.
The next advance was Third Generation Languages (3GL) and although introduced in the 1950's these form the vast majority of languages in use today.
Again, there was a significant increase in abstraction level away from 2GLs. New concepts were introduced for the programmer such as loops, arrays, assignments and types. Higher level paradigms (still 3GL) were developed later such as structured programming, object oriented programming and functional programming.
The Matrix modeling language represents yet another significant jump in abstraction level.
Matrix implements well known modeling concepts such as domains (for the separation of concerns), entities, states and events but as part of a Turing complete solution while the model remains implementation agnostic. Most 3GL concepts including arrays and pointers are simply not present.
A Matrix Model Compiler brings together a previously defined software architecture and abstract system model to generate 3GL source code.
With each jump in abstraction level, languages become more expressive and powerful. In practice, each higher-level language statement is efficiently compiled to many lower-level statements and indeed to a great many more instructions when ultimately expressed in machine code.
The bottom line is that for any given computer system a Matrix modeler working at a higher level of abstraction is far more efficient than a programmer.
|
|||||||||||||||
|
|
|||||||||||||||
|
Why can't software be precision engineered just like bridges, cars or electronics?
Now it is.
Our aim is to replace the usual software development chaos with engineering discipline.
The Matrix development process elevates Business Analysts and Software Engineers to the same level as traditional engineers such as Mechanical Engineers and Electrical Engineers.
Traditional engineers use engineering processes which are based on the laws of physics and applicable mathematics. They construct their systems from large reusable components. They build models from those components from which they can predict the behaviour of their system and they subject those models to rigorous testing before they build anything. They can predict and be confident in what the system does.
Matrix Software Engineers also use engineering processes which are based on aspects of computer science such as relational theory, finite state machines, Petri nets and others. They also construct their systems from large reusable components, predict behaviour from executable models which are tested rigorously and are confident that the system will work as specified.
|
|||||||||||||||
|
|
|||||||||||||||
|
Where do Programmers fit into the picture?
Matrix Technology enables all source code to be generated from executable models, so what role can programmers play?
Generating source code requires two models. One represents the application to be built and the other its software architecture. There will be some part of the software architecture model that defines code templates, written in the target language to be generated.
Programmers are required to define the code templates within code structure constraints specified by higher-level parts of the software architecture.
This work includes defining interfaces to other software such as databases, networking and other existing systems. Also, templates for Make files, documents, web pages and spreadsheets are usually required.
|
|||||||||||||||
|
|
|||||||||||||||
|
What if the Matrix language changes in the future?
There are two main types of statement in Matrix, primitive and pattern. The functionality of pattern statements can always be replicated using primitive statements alone but pattern statements translate to more efficient source code as they provide a way for the modeller to express their intention.
The three pillars that Matrix relies upon to describe a system are the relational model, finite state machines and lower level procesing based on Petri nets. The set of primitive statements defined so far are sufficiently complete to account for their operation.
Relational theory, state machines and processes have proven themselves over many years and are likely to remain very stable in the long term.
However, the number of Matrix pattern statements will increase over time since that is the primary mechanism by which Matrix will grow and become even more more powerful. The Matrix language is designed in such a way that adding a new statement will never make any of the old statements invalid.
|
|||||||||||||||
|
|
|||||||||||||||
|
What is the track record of Dark Matter Systems Ltd?
Dark Matter Systems Ltd provides tool and modeling consultancy to business, industry and defence. The company was founded in 1994 by Mike Finn [mike@ultradark.com]
The early days of the company were largely spent pioneering the development of the PLASMA toolset and in particular PLASMA*PARSEC which was one of the first languages to generate C code from models
During the 1990's Mike developed a C code generator (a Model Compiler in today's terminology) for a Captain's Information Display and Tactical Decision Aid for the Royal Navy.
In the 2000's, while working with Kennedy Carter (now Abstract Solutions), Dark Matter Systems provided extensive consultancy to a major client for the development of an optimised SPARK Ada Model Compiler
More recently, Dark Matter Systems has created another even more advanced ANSI C Model Compiler adding to the Matrix modeling language and the Analysis Design Matrix diagram
Today we specialise in writing advanced Model Compilers to generate high-integrity code from models in languages such as ANSI C, Java and Ada.
|
|||||||||||||||
|
|
|||||||||||||||
|
The free learning edition of Matrix can be downloaded from our technical website
|
|||||||||||||||
|
|
|||||||||||||||
|
Email is the best way to contact us
|
|||||||||||||||
|
|
|||||||||||||||
|
Delving Deeper into Matrix |
 |
||||||||||||||
|
|
|||||||||||||||
|
Matrix is a textual modeling language inspired by the Analysis Design Matrix diagram.
Without compromise, Matrix provides developers with an abstract language far closer to thought than has previously been available to programmers.
A Matrix model captures the requirements or business rules in a future proof form which is reusable in any chosen implementation. One major advantage of code generation is that the implementation or software architecture does not need exist at model construction time.
The language was designed for scalability which is an important requirement for large and complex concurrent systems. Matrix Model Compilers generate code extremely fast which is another important consideration for large projects.
Matrix employs the relational theory of data and communicating finite state machines in a modeling process to create implementation free models that formalize existing knowledge and expose gaps in understanding.
The Matrix language has statements that capture the subject matter under analysis. Unlike a programming language, Matrix is devoid of any statement that is capable of specifying an implementation detail.
The language uses several types of statement. The most powerful type are pattern statements; these enable intentional specification, an increased level of checking in the Model Compiler and the generation of higher performance source code. In fact, the Matrix language constantly evolves and grows by introducing new pattern statements
The Model Compiler applies an interlocking web of checks to the model before generating source code. The checks ensure that the source code will compile without errors.
With textual languages, model development is often simpler and faster due to easier searching, refactoring, merging, differencing and configuration management. With tools for graphical modeling notations such as UML these activities tend to be problematic.
A standardised coding style and rigid model format is rigorously enforced by the Model Compiler leaving little scope for customisation. As a result, all Matrix models have the same layout and parts of the model are easily located.
|
|||||||||||||||
|
What breakthroughs have you achieved?
We have made many innovations during the 20 years we have been around but over the last 5 years progress has been remarkable and we are most proud of the following breakthroughs:
The Analysis Design Matrix Diagram that is both the backbone and road-map for everything we do. It is a formal diagram that shows, at the high level, analysis abstraction on the x-axis and design abstraction on the y-axis. At a more detailed level its shows how the software architecture (which becomes a Model Compiler) and the analysis of application work together to generate code.
The Matrix Language is the embodiment of the Analysis Design Matrix diagram. It is a language like no other. Syntactically very simple to understand but semantically very powerful to use.
The Model Compiler that generates the application's code and the Matrix model of the software architecture of the application are one and the same thing.
The breakthroughs and insights we make help build a better langauge. Ultimately, better tools mean working smarter, more efficiently and much more profitably.
|
|||||||||||||||
|
|
|||||||||||||||
|
How does Matrix explain the concept of analysis?
Analysis is simply the process of building a model of an application.
The main deliverable of analysis is a Matrix analysis model. Other activities may be involved such as gathering requirements, prototyping, writing lists, drawing informal diagrams and writing technical notes.
A Matrix model is always an analysis model
During analysis, subject matter domains are identified. Domains form the reusable components of analysis. The requirements and dependencies which client domains place on server domains are detailed in the bridges between domains.
The word “design” may be informally used in the context of the analysis process. For example, during the analysis of an application it would be acceptable to say that a solution using a specific arrangement of entities to a particular requirement has been “designed”.
The application’s analysis model is totally independent and separate from its design which is embodied in the Model Compiler. Obviously, this confers a number of advantages and is the basis of future proof software.
|
|||||||||||||||
|
|
|||||||||||||||
|
What does Matrix code look like?
Matrix is a powerful textual modeling language that is both elegant and simple.
It maps directly to two frequently used UML diagrams, the Class Diagram and State Chart. Matrix can be represented by a very simple UML profile and does not require use of any overly complex graphical notation.
The structure of Matrix code mirrors the construction of the Analysis Design Matrix diagram
A number of design principles influenced the construction of the Matrix language, such as the code being self documenting as far as possible by having explanatory statement names and encouraging the use of full names for all components.
Another goal was the enforcement of a built-in style guide by the use of indentation to replace braces and one statement per line to make the use of the ubiquitous semicolon redundant.
A further design goal was to make Matrix code look like a list of things wherever possible.
But the overriding design principle was to facilitate supremely efficient automatic code generation, enabling Matrix Model Compilers that are capable of generating 100% of a project's 3GL source code.
Here we give just a taste of what the code looks like and examine a sample of three text files containing code at different levels of model construction in the following sections. All comments have been removed in the examples below for reasons of space.
A complete description of the Matrix Passenger Elevator model with model walk-through, associated diagrams and comments can be found here
|
|||||||||||||||
|
|
|||||||||||||||
|
How does Matrix explain the concept of design?
Design can be tricky to understand because it mainly involves analysis.
"Design is a subject matter for analysis"
The process of design involves building an analysis model of the software architecture that is to be used in the application.
In other words, design is the process of building a model of a Model Compiler and the deliverable of the design process is a Matrix analysis model. There is no difference between analysis and design models except for their subject matter.
The model of a Model Compiler is actually the model of the software architecture of an application that will be compiled by the Model Compiler.
In Matrix, the main purpose of a software architecture model is to generate source code.
|
|||||||||||||||
|
|
|||||||||||||||
|
Is Matrix executable modeling programming?
The short answer is no. The long answer is maybe. It depends where you stand and how much you know.
The executable modeling programming controversy has been argued over for as long as executable modeling has existed. Discussions have become particularly focused since the introduction of purely textual modeling languages which look like program code.
Unlike Matrix, some modeling languages have a lot in common with 3GLs and have a C like syntax to make them more acceptable to programmers.
Building a Matrix executable model is an entirely different activity to what has been programming so far, simply because the concepts being manipulated and reasoned about in each are so very different.
The concepts in Matrix modeling and the concepts in 3GLs are sufficiently separate and exclusive that it can be successfully argued that this is enough justification to separate modeling from programming.
It follows that since the things (semantics) being handled in a language belong to either executable modeling or programming but rarely both, the activities of model building and program construction are also different and should be treated as such.
However, if programming is coarsely defined as giving instructions to a computer then executable modeling is programming. Of course, this is the rather unsophisticated and simplistic viewpoint that is held by the majority of programmers.
|
|||||||||||||||
|
|
|||||||||||||||
|
The structure of a Matrix model
The first example shows part of our standard Matrix Passenger Elevator demonstration model down to the domain and entity level. The indentation levels directly correspond to levels found in the Analysis Design Matrix diagram.
Statement names are highlighted in blue. Black text is used for other names such as entity, state and event names.
It can be seen that the DomainInclude statement simply lists the entities which belong in Elevator Management domain. All statements enforce this listing approach which turns out to be very powerful.
System:Passenger_Elevator SystemInclude Description Type Matrix:Model:Application Silo:M1:Software_Application Realm:Analysis_Of_Application Domain:Elevator_Management DomainInclude Event_Context Floor Door Car_Service Car_Stop Service_Assigner Car MatrixInclude Objects
|
|||||||||||||||
|
|
|||||||||||||||
|
How does the Matrix language work?
Essentially, the Matrix modeling language implements and crystallises the Shlaer-Mellor Method upon which the Matrix Method is based.
Model construction begins by identifying top-level subject matter domains. A domain is composed of a system of communicating active entities abstracted from things in the Real World.
Usually, an entity will have attributes and relationships which are also found by a process of abstraction. The events to which each entity responds are identified and ordered in a state machine.
Finally, the work done by each state is specified using a combination of state actions and processes. State actions (or just actions) are the fundamental units of work in Matrix.
A process typically includes actions and other processes. These are simply grouped together and given a name. They are used everywhere state action statements are used and because they are named are reusable.
More about the method can be found on our technical website
The Matrix modeling language is based large parts of the Shlaer-Mellor Method for Object Oriented Analysis and Recursive Design (OOA/RD) and its later update, Executable UML (xUML) aka Executable Translatable UML (xtUML).
|
|||||||||||||||
|
|
|||||||||||||||
|
The structure of a Matrix entity
The second code fragment shows one DomainInclude file from the list above. It describes the elevator Car entity which may be drawn as a class on a UML Class Diagram.
The Entity statement lists the Car's attributes and relationships together with any states that describe the entity's life cycle.
Again the powerful include statement variant, StateInclude enables the detailed description of each state to appear in its own file while appearing as a member of a list at this level.
DefineDomainInclude:Car Entity:Car Attribute Direction : Direction Relationship Services ->> Car_Service Currently_at --> Floor Accessed_through --> Door Scheduled_to_move_up_to |>> Floor Scheduled_to_move_down_to |>> Floor State Dataset:Travel Floor : Next_floor_number StateInclude Stationary Selecting_Schedule Servicing_Schedule Moving Checking_Schedule Slowing Opening Accessible Closing
|
|||||||||||||||
|
|
|||||||||||||||
|
How does the Matrix language evolve and grow?
Matrix is a fully extensible language that evolves and grows by incorporating new pattern statements.
Various primitive statements are provided by the language and these form the base language. Any model must be able to be constructed using primitives alone.
Pattern statements are discovered by users of the language and appear as arrangements of primitives and other patterns which provide some generically useful functionality. Patterns are important because not only do they make the Matrix code more readable and concise, they also signal the analyst's intention to the Model Compiler which enables more efficient source code to be generated and more sophisticated error checking to be performed.
Generally applicable patterns are incorporated into the Model Compiler (therefore, into subsequent generations of Model Compilers) and become part of the growing Matrix language.
|
|||||||||||||||
|
|
|||||||||||||||
|
The structure of states, events and actions
The third and last include file describes the Checking Schedule state for the Car entity.
The StateAction statement lists out the actual work to be performed on entry to the state in response to an event.
There are three process level actions to perform, one of which is the ProcessEntityInclude statement that enables further process actions to be listed in another file that can be included elsewhere in the model.
The state's response to an event after all state actions are complete are given in the Transition statement. For example, if the "Stop at next floor" event arrives the next state to be processed will be Slowing state. Except for the Continue event, the other events will either be ignored or signal an internal error condition.
DefineStateInclude:Checking_Schedule DynamicDataState:Checking_Schedule:Travel ProcessData Flag : stop_not_found StateAction Assignment SetBoolean stop_not_found := <<True>> Traverse Navigation Car : Currently_at : Floor TraverseSelection Unrelate Car : Currently_at : Floor ProcessEntityInclude Car : Check_Floor_Schedule Transition EventState Continue -> Moving Stop_at_next_floor -> Slowing IgnoreEvent Service_requested Open_door Close_door CannotHappen Service_schedule Service_current_floor Moving Floor_approaching Car_stopped Door_open Door_closed
|
|||||||||||||||
|
|
|||||||||||||||
|
All links to this and other websites are selected via the following colour coded buttons:
|
|||||||||||||||
|
|
|||||||||||||||
|
UML and MDA are trademarks of the Object Management Group (OMG). All other trademarks or registered trademarks are the property of their respective holders.
|
|||||||||||||||
|
|
|||||||||||||||
|
Copyright © 2017 Dark Matter Systems Ltd. All Rights Reserved. |
|||||||||||||||
