Versus other paradigms
Versus other paradigms
In order to define what software is, let's look at different ways of viewing, or grouping software using the classical layers: software from the point of view of users and programmers. The goal is to find commonalities between them in order to understand what software is.
Experienced programmers know that all types of software have their own constraints: programming an accounting program has constraints that a drawing application has not, and games have yet another set of constraints. The constraints for a particular kind of software mold not only the internal structure of its code, but also dictate the importance of different aspects of the software and creates a hierarchy.
Wikipedia describe many types of software:
This is the classical categorization of software types, from the point of view of the end-user.
Internet users might be surprised by the last two categories, utilities and malware, as they do not appear in Web services. The Procedure page explains their existence.
Each type of software has different requirements, shown in the table below:
Example : Media software like Movie, Music or Graphic editors, most of all need High Speed. Management software like Accounts management or ERP, need Data Security. Games need Fast user interfaces.
Software categorization can also be done from the point of view of programmers, by project type: programming an operating system have other constraints than creating an accounting system. The following table categorize software by project type and give a grade on three criterion for each:
|Project||Reliability||No bug||Due date|
No bug means minor bugs that will not interfere with the quality of the software output.
Given the above categorizations we made, we can see that each kind of software has its specific needs and constraints. Each analyst, by using a specific approach and point of view, with his own experiences and the way he envision the final product, will prioritize differently the creation of the program. The prioritizations shown in the tables above are not universal, everyone can have different ones given his own experience.
But then how can we answer the question:
Now that we can see that all programmer, even the best ones, see the problem differently at some point during the development, we can understand that those differences, which do not appear in the code and won't be obvious to members of a development team, come with a high risk of bugs in the code.
To avoid potential bugs because of misunderstandings among the development team members, we need to find the smallest common between all application types, applications and programmers, so we could have a common ground on which users, programmers and applications can communicate, in a simpler way.
Some have tried to find the lowest common denominator between users, programmers and applications by defining new standards:
People with a little experience know that even with the help of one or several of those standards, bug appear. In facts, if a project the more a project is big and takes time, the more programmers will be needed to maintain it and make it evolve.
So the next question is:
Since even the use of evolved languages, libraries and workflows cannot prevent bugs, it means that they are not able to provide a complete solution.
So what ?
The common point between all components, human on electronic, of a software is its reality, what it actually does, what the programmer wanted it to do. Another way to put it is: What does the program actually do that the programmer programmed it to do? The answer should be something common for all type of applications…
… and whatever the project type…
Is there a way to break down the applications which will show the same base element whatever the application, as a few kinds of atoms common to all and every kinds of objects?
The base building blocs of all software defined in 1992 by Fabian J. Padilla is the following:
Those base tasks are inspired by the old assembly languages such as Signetics 2650, Zilog 80, Intel 8080 and 8048, and others from less powerful processors of the 70's. At that time, each byte was important and every instruction precious. The programmer needed to know precisely what was needed.
We don't consider IRQ management or DMA tasks, as they are taken in charge of by hardware or the operating system, beyond the focus of Evenja.
This definition of the 7 tasks, can be used in any software of any type, in any languages, used in any condition, by all programmers. This is the principle of Evenja.
Next page of Evenja's theory, Procedure.