User Tools

Site Tools


principles:software

Software ?

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 definition

Wikipedia describe many types of software:

  • Application
  • System
    • Operating system
    • Device driver
    • Utilities
  • Malicious or malware

This is the classical categorization of software types, from the point of view of the end-user.

End-user definitions

  • User
  • Application
  • Operating system
  • Hardware
  • Utilities
  • Malware

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.

by Software needs

Each type of software has different requirements, shown in the table below:

Software Speed Data Memory Storage Connexion User Interface
Management Security Reliability Important
Media High Enough Quality
Mail Security Reliability Reliability
Games High Reliability Fast
Device FW Low Low No

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.

by Programmer work priority

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
Operating system High High
Driver High Low
User Interface Low High
Accounting High High
For Banks High Low
Management Low High
Game Low Low
Compiler High Low

No bug means minor bugs that will not interfere with the quality of the software output.

Definition result

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:

  • How can we create software without bugs and in simpler ways?

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.

Common point between software?

Some have tried to find the lowest common denominator between users, programmers and applications by defining new standards:

  • Languages such as Java, Perl, Python, Scala: simpler, therefore more widely understandable.
  • Workflows such as UML, AGILE: more organized, therefore simpler.
  • Libraries such as Qt, .Net, Fireworks: several platform, therefore less complications.

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:

  • How a small team can make big applications?

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…

  • Management
  • Media
  • Mail
  • Games
  • Device FW

… and whatever the project type…

  • Operating system
  • Driver
  • User Interface
  • Accounting
  • For Banks
  • Management
  • Game
  • Compiler

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?

7 tasks and how to use them

The base building blocs of all software defined in 1992 by Fabian J. Padilla is the following:

  • Read, put a value in a variable
  • Write, put the value of a variable where it is needed
  • Split, copy the content of a variable to another one
  • Merge, combine the content of two variables into a single one
  • Modify, modify the content of a variable
  • If value, condition about the value of the content of a variable
  • If function, condition about the value of the content of a variable, that will define a different end-user functional behavior

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.

principles/software.txt · Last modified: 2014/04/24 14:41 by fjp