Participants

Software Site.

The Software Site objective is to provide a stable base on which we construct software programs. This can be represented by the hardware elements of Computer Architecture and the software environment in which a software program will be developed. In general, a good part of the result of the software development and construction relays on these elements.
During a software development, the elements that compose the Software Site should be analysed determined as the first elements that influence the design and implementation of software programs. "Site is eternal" [Brand94], at least during the lifetime of a software program.

Software Structure.

The Software Structure objective is to provide stability and support to the other subsequent layers. It can be represented by the basic organisation schema of a software program.
Software Structure is the description of a software program as a set of defined subsystems, specifying their responsibilities, and including rules and guidelines for organising the relationships between them. Software Structure is concerned with the issues about partitioning a complex software system. The partition of software is necessary to cognitively deal with complexity. A big problem is divided into smaller subproblems that are possible to reason about, and perhaps perform some work on separately, at more comfortable cognitive level. Software Structure can be described in terms of architectural patterns:

"An architectural pattern expresses a fundamental structural organisation schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organising the relationships between them" [POSA96]

Software Structure is properly the first design stage of a software program. In practice, software development consider the Software Site as provided or given, and initiates from the Software Structure design. Due to it supports and stabilises all other layers, any considerations and decisions taken during its design affect the other layers design and construction. "Structure persists and dominates" [Brand94].

Software Skin.

The Software Skin objective is to give an appearance to a software program, exhibiting its functionality. In general, it is represented by all the elements that allow user interaction, mainly expressed by the use of graphical user interfaces, in which end users conceptualise how the software program works. Software Skin ranges from complete graphical environments to simple text screens. User friendly software programs try to enhance their Software Skin to make them attractive and understandable. The aim of Software Skin then is to support the usability of software, allowing users to learn about the software program and use it effectively.
The most visible changes that can be performed on a software program are at the Software Skin layer. Just observe the graphic or programming environment of different users and programmers. Although they preserve the same elements, most of them represent a modified version of an original. Changes can be performed quickly and easily, according to necessity or taste. Also, it is noticeable that from one software release to another, developers commonly introduce changes in the user interface of a software program. The change may follow different causes, from newly added capabilities to aesthetics. These changes represent, in a more visible form, the improvement of the software as a product but occasionally, as with buildings, this is the only improvement of the software. "Skin is mutable" [Brand94].

Software Services.

The Software Services objective is to provide support for common activities during the use of a software program. Software Services are defined as those elements, which are part of the "working guts" of a software program. From a programming point of view, Software Services can be found in the form of all those pre-built standard components that provide common functionality like mathematical, input/output, and disk access, available as libraries of standard components from reliable suppliers or experienced programmers. Often, Software Services in a library are customised for a particular software design by the designer or programmer. For example, libraries of classes can be used effectively for customisation in Object-Oriented programming [Strous91].
The correct use of Software Services can lead to more manageable, extensible and maintainable implementations. However, they are not universal standard programming tools or programming libraries. They depend closely on features and resources of the computer system where they are suppose to be used. Due to this, it would be unreasonable to expect them to be fully standard. Most Software Services can be considered standard on only a specific type of computer system [Strous91]. When computers change, Software Services have to evolve with them. "Services obsolesce and wear out" [Brand94].

Software Space plan.

The Software Space Plan objective is to organise the different partial tasks or activities performed by a software program. It represents the way in which the parts of a software program are organised. Following a particular paradigm or technology, data structures and functions are organised as abstractions in the form of software components and interfaces among them. Object-Oriented Programming, for example, presents organisations of classes that can be used as a layout of cooperative objects. This is the base for the concept of design patterns [POSA96,GoF94]:

"The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context" [GoF94].
"A design pattern provides a scheme for refining the subsystems or components of a software system, or the relations between them. It describes a commonly - recurring structure of communicating components that solves a general design problem within a particular context" [POSA96].

Design patterns can be applied in the design of the Software Space Plan by specifying detailed design aspects and the implementation requirements of a component. They can also be applied in refining and deciding on the basic module interfaces, following the reuse principle "Program to an interface, not an implementation" [GoF94]. Decoupling interface of implementation aims to simplify the reuse and reorganisation of the Software Space Plan.
As with the case of Space Plan in building architecture, Software Space Plan is the layer that often changes to cope with the needs and desires of occupants. This layer is where most software systems are designed to evolve in response to changes of existing requirements or the needs of new requirements. "The space plan is the stage of the human comedy. New scene, new set" [Brand94].

Software Stuff.

The Software Stuff objective is to represent the actual programming elements that perform processing or contain information: functions, procedures, data representations, data structures, etc. In an OO program, classes are defined with an interface controlling access to the data and functions, and an implementation that represents the coding of such data and functions. Idioms are the Software Pattern approach for describing Software Stuff.

"An idiom is a low-level pattern specific to a program language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language" [POSA96].

Software Stuff is precisely the working material of the programmer. It is the layer of software that is continuously evolving and changing. "Stuff just keeps moving" [Brand94].


Contact Information

Jorge Luis Ortega Arjona

E-mail jortega-arjona@acm.org