Table of Contents

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

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.

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:

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.

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.