ALEHUB is a project comprised of several parts which demand special attention when designing this system. Thus, the project has a modular architecture and, besides, follows the notion of multilevel design when some components make use of different components which are part of a lower level. The system contains several subsystems which have a complicated structure and separate components communicate in the same way as protocols of different layers in the OSI model do.
Designing of ALEHUB uses method usually used when creating models. This method implies the division of the designing process into several steps, and each of them is dedicated to disclosure and specification of principles and rules described at a previous step. The method contains following steps:
1. Conceptual model — general description of system workflow, basic work logic and principles of system functioning;
2. Algorithmic model — a model in a form of algorithms, set of classes, procedures, variables and other common notions of programming;
3. Mathematical model — formalized description of system workflow in a form of mathematical dependencies, variables and transition functions;
4. Implementation model — a project of concrete system implementation for concrete programming language and concrete system peculiarities.
Under design the system consistently passes all the steps and the return to some passed stages and their correction is possible. The presented method is greatly simplified in comparison to the one used in modelling. The steps of building cognitive and informative model are omitted. The reason is that the description of the system uses terms of the subject area which excludes the necessity of using general descriptive model.
System design begins with creation of conceptual model. This step implies describing all the processes and principles of system behavior, basic roles and their capabilities etc. The algorithms might be weakly formalized, and some details are to be missed. The aim of designing is formalization of boundaries for workflow and eliminating of uncertainties of the previous steps of system description (White Paper, advertising, etc.). The result of this step is a document called Technical White Paper. Nowadays the traditional notion of White Paper has shifted, and this document is project charter and not its complete description at least in a generalized way. Many projects do not have this document at all which did not prevent them from collecting significant funds during ICO.
At the algorithmic step the system is shown as a formal set of algorithms, data structures, classes and objects. This step requires strict formalization of general description created at a conceptual level. However, using the natural language when describing classes and algorithms is allowed. The result of this step is the first part of technical description — Yellow Paper. Many projects have Yellow Papers, which contain only conceptual and algorithmic design results. ALEHUB follows the principles created when designing Ethereum. Yellow Paper is a technical document which contains exhaustive information on principles of building the system and its workflow and which is written using strict mathematical notation.
Mathematical model allows to achieve strict formalization of algorithms and data structures presented earlier. This step results in publication of first version of Yellow Paper. In comparison to similar documents of most modern projects, as mentioned before, Yellow Paper of ALEHUB will contain complete information about the system, i.e. information necessary and sufficient for building the system using arbitrary programming language.
At last, the implementation step implies building technical project (Blue Paper). This document is a description of system for specific programming language and technology stack. In case of ALEHUB Blue Paper is a peculiar backlog of project: as during system development the requirements tend to change (thanks to modification of Technical White Paper and Yellow Paper), it is reasonable to use agile methodologies for software development. At the same time, as practice shows, the absence of technical project for complicated systems rarely leads to positive results.
A common practice in the process of software development is the coverage of program code by a system of tests. Testing is to be performed over distinct modules and their aggregate. Consequently, two stages are singled out: unit-testing and integrated testing. When designing ALEHUB a similar approach is used. Use-cases (uCases) are used as tests. These are examples of system functioning, which cover all the possible ways of its usage. The examples are created simultaneously with designing and can contain either separate sub processes as part of system functioning or complete sequence of actions from the beginning of work with system and to the moment of total withdrawal of funds. All uCases follow the same designing steps as the system. I.e. with concretization any subsystem all the covering uCases are concretized. This allows to achieve consistent and total result during the process of designing thanks to exclusion of potential errors caused by absence of uCases.
This principle virtually borrows the concept of cognitive modelling. To design the system, it is necessary to comprehend modes of operation and potential reactions on external impacts. This is the reason to use uCases, which act like an image of yet not implemented system.
Stay tuned with us, soon we’ll have more good news about our project and the development process.
📌Join our Telegram news channel
📌 Join ANN thread
📌 Join official Twitter page
