Universal Software Principles

Universal Software is software that can be used natively on any device and guarantees universal reuse, extension, and maintenance.

The four fundamental principles of universal software are:

  1. The software must run natively on any hardware, Operating System, and network (Environment Independence Principle).
  2. The software must allow reuse of complete or part functionality as modules to create new applications (Modular Reuse Principle).
  3. The software must allow extension of its functionality by addition, enhancement, or replacement of its functionality by new modules or plugins (Inject and Extend Principle).
  4. The software must use a single set of source code that is permissive for maintenance by software engineers other than its original authors (Open Maintenance Principle).

Guidelines

These principles can be further understood by the following guidelines:

Environment Independence Principle

Universal software must run natively on any hardware, Operating System, and network.

This should be understood to mean the software:

  1. Must run natively on any device to which it is deployed.
  2. Must not require particular hardware to operate.
  3. Must not require a particular Operating System (OS) to operate.
  4. Must work in both stateful and stateless environments.
  5. Must not require a network or internet connection to perform non network tasks.

Whenever possible the software:

  1. Should also be available for use within a web browser (separate to the native applications).
  2. Should make use of specific hardware capabilities of the device it is running on where it helps achieve the software’s purpose.
  3. Should follow applicable guidelines and recommendations of an OS when running within that OS.
  4. Should cache non-senstative data to allow continued use of the software in environments without network or internet access.
  5. Should include platform independent version of any platform dependent code to allow the software to be executed on new platforms that were not available at the point of release.

Modular Reuse Principle

The software must allow reuse of complete or part functionality as modules to create new applications.

This should be understood to mean the software:

  1. Must provide all its functionality as a reusable dynamic link library or package.
  2. Must self initialise its data store and other dependencies on first use.
  3. Must provide complete functionality including CRUD operations and user interface.

Whenever possible the software:

  1. Should use the Mvpc Command pattern to allow a containing application to display its functionality alongside that of other modules.
  2. Should be suitable for use as a plugin at run time in environments that allow plugins.

Inject and Extend Principle

The software must allow extension of its functionality by addition, enhancement, or replacement of its functionality by new modules or plugins.

This should be understood to mean the software:

  1. Must allow any service it provides to be extended or replaced by another module.
  2. Must allow any service it invokes to be extended or replaced by another module.
  3. Must allow any user interface screen to be extended or replaced by another module.
  4. Must allow the replacement of a single service or interface screen without requiring related services or interface screens to be replaced as a result.

Whenever possible the software:

  1. Should allow functionality to be disabled at runtime through configuration.

Open Maintenance Principle

The software must use a single set of source code that is permissive for maintenance by software engineers other than its original authors.

This should be understood to mean the software:

  1. Must use a single source code for all functionality across all platforms except those files or classes that directly interact with the hardware or Operating System.
  2. Must provide documented APIs for all public classes and members.
  3. Must not directly create or require software patents.
  4. Must be written in a programming language with a formal ECMA and/or ISO standard that makes it free to implement and has an open source compiler available.

Whenever possible the software:

  1. Should only use version controlled standardised APIs between packages.
  2. Should be extendible in a programming language different to its original language.
  3. Should be made available under a permissive open-source license.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: