Products
Introduction
Capcaval.org is a nonprofit organization, made of passionate coders. We create Java(*) libraries for others with open source license. Libraries purpose is to provide tools reducing effort on technical aspect of coding and therefore gaining time for your own domain aspect. Domain part is the real goal of programming, the technical is only the mean.
For that we strongly believe that good design and architecture are the major keys for software creation success.
Capcaval.org libraries are the result of years of experiences on complex software systems. Our experience is made of many failures analysis and we have tried many solutions on lots of projects for different domains.
We simply wish to share our result of that experience within simple solutions.
Inside this article, we explain, firstly one of the most important problem of making software. Secondly, we will describe important structural points about software program. Thirdly, we present our generic program architecture and their different uses and we finish by describing our libraries which implement all the described concepts.
Software pitfall
Overcomplexity is one of the main software pitfall and it is mainly due to a lack of design or wrong architecture choices. As it is structural, even some snags can have a great impact on Software program success. Even at worst, the project can never be delivered and becomes a dead weight loss. Unfortunately this is not rare. Overcomplexity forces more source code to be written, to be tested, this can increase dramatically the production effort. It can also yield all the tests very difficult to write. Having bad test implies a double impact on cost and on quality . A too high complexity also have an impact on developers : they need more support and training and might also decrease strongly their morale.
In synthesis, the consequences of overcomplexity are :
- bad productivity,
- bad quality.
On the contrary, we firmly believe that simplicity is very important. The goal that each developers shall have is to match the input domain complexity and no much more. The following picture tries to resume all of the above points. It tries to display graphically the differences between some spaghetti code and some designed programs.
Software program description
Nowadays, software program has to handle three types of interfaces :
- OSI (Operating System Interface) : This interface does not represent the most important effort in writing software but it is still important as it is used to launch and to configure your program. This interface depends on the operating system. Starting a program on Linux is different than on Windows, and luckily not too much.
- CSI (Computed system Interface) : This interface can be very big, and it can be implemented in a tremendous amount of media type like, USB port, real-time bus, Ethernet wire etc.. and also on many protocols like TCP/IP, UDP, Thrift, HTTP, etc.. This type of interface can be very complex because of rich functionalities and also it can be the result of a bad design which increases the complexity.
- HMI (Human Machine Interface) : This interface can also be very complex due to a high number of possible interaction, of also to some complex state machine and to some complex interaction type.
See below the three different interfaces :
From this interfaces, we have simply split our architecture in three part, one per interface. This has to be done this way because they do not do the same thing at all and therefore the tool type needed for each is different.
An UML notation is used to describe links between the different parts of the architecture. Application is the root part and so it is in charge of creating the two other sub-parts. It is also in charge of getting the configuration out of the OS function, like properties or application parameters. From this configuration it shall configure either the Processor or the Interactor. Processor is in charge to handle one or several specific computed interfaces. It shall separate the technical specificity code to a more simple domain and functional code needed by the Interactor. Interactor uses in one hand the domain and functional code provided by the processor and in another hand it also handles all the input and output of operators.
To avoid spaghetti design only Application knows the two other, and Interactor knows only Processor. Processor has no dependency. If we rephrase, we can say that a specific program has to know which processing and HMI have to be used. That a HMI has to know what processing data that it has to display. That data processing does not need any other part of a program.
As you can see the architecture is quite simple.
From this generic and simple architecture, you can still simplify it for simpler programs. You can find, inside the below diagram, the four possible types of architecture :
1- Basic standalone program : a small program which does not need a complex design. It can be a single class. For instance, it can be a simple command launch inside a terminal, like finding a file inside a directory.
2- Processing program within a computed system : this an application which needs to connect to one or several external Interface. The functionality to be implemented is complex and needs to be split into several components inside the Processor part.
3- Standalone HMI : is an application which handle itself its data, which comes from the OS(properties, files etc..) on which it is running. It also handles input and output from an operator.
4- HMI within a computed system : is an application which received data from other software applications and it also have to handle input and output from an operator.
Cap Caval's libraries
As you can see on the below picture, each architecture part has its own libraries. So far, we have an implementation in Java, but for sure the concept can be applied on many other language. Again to be simple as possible, we did not use or create a language per library. We think that modern language, as Java, are far good enough to create very good tools. Having several languages increases the need of training and the complexity or the number of tools with a low return of investment.
LaFabrique : provides tools to create, compile, make jar etc.. from your source and it also handles your program launch and its configuration.
C³ : provides tools to define components handling data processing. It is very good at splitting your domain functions into simple and explicit black boxes. It also provide isolation of external interfaces to create easely an internal domain interface. Component design can be defined in two dimensions and so you are able to split a complex function into a simpler component tree. In the future we will provide 3D design for even better simplicity and productivity.
Ermine : It is still is in development process. It should be coming out soon. Ermine provides a new kind of MVC, it also provides injection of events and services from C³. It also provides some convenient tools for HMI like some state machine.
Conclusion
We have created a generic architecture which is simple and scalable. For each part of the architecture we create three libraries containing tools to create your programs for your own domain needs and code with minimum effort on the technical plumbing.
Links
Ermine, web site is coming soon
