The following are definitions provided to ensure the rest of
the documentation is understood and clear to the reader. Many of
these terms have been used in differing contexts based on the
background of the writer. Thus, this allows the author and reader
of this library to ensure that everything is understand by setting
expectations of understanding.
System - A collection of
software and/or hardware performing one or several tasks. A
system can be a platform, an application, or both.
Application - A program
or collection of programs that fulfills a customer's
requirements.
Subsystem - A set of
collaborating components performing a given task. A subsystem is
considered a separate entity within a software architecture. It
performs its designated task by interacting with other
subsystems and components.
Platform - The sum of
hardware and/or software a system uses for its
implementation. Software platforms include operating systems,
libraries, and frameworks. A platform implements a virtual
machine with applications running on top of it.
Framework - A semi
finished (sub-) system intended to be instantiated. A framework
defines the architecture for a family of (sub-) systems and
provides the basic building blocks to create them. It also
defines the parts of itself that must be adapted to achieve a
specific functionality. In an object-oriented environment a
framework consists of abstract and concrete
classes. Instantiation of such a framework consists of composing
and subclassing the existing classes.
Application Framework - A
framework for completing applications in a specific domain.
Component - An
encapsulated part of a software system. A component has an
interface that provides access to its services. Components serve
as the building blocks for the struture of a system. On a
programming language level components may be represented as
modules, classes, objects, or a set of related functions. A
component that does not implement all the elements of its
interface is called an abstract component.
Message - A message is
used to communicate between objects, threads, components, or processes and may
be synchronous or asynchronous in nature. Synchronous messages mean
that the sender waits util the receiver finishes the operation
before continuing. Asynchronous messages return to the sender
immediately while the receiver processes the message in the
background.
Event - A message that
conveys the occurrence of a significant activity. An event commonly
indicates the activity that occurred, a reference to the object to
which it occurred, a timestamp, and any associated data.
Coupling - Coupling
represents a measure of the interconnection between
components. It is desirable to minimise coupling, thereby making
components as independent as possible. A design unit has low
coupling if the units are not strongly dependent on each other
and is a feature of a well-partitioned system. Simple
connectivity between components results in software that is
easier to understand and less likely to spread error through a
system.
Cohesion - Cohesion is an
integral part of modular design and represents the strength of
the relationship between design elements. A cohesive component
performs a single task and requires minimal interaction with
logic in other parts of a program. Ideally a cohesive
component should do only one thing. It is desirable to have
components which are highly cohesive and strongly related to one
another. The elements of one component should not be strongly
related to those of another component as this leads to tight
coupling which is undesirable.