From the SoProTech perspective, a generic software system can be
structured according to three abstract layers (often referred to as
tiers) and two cross-layer
pillars, as shown by the next figure. Layers and pillars
are collectively referred to as software system logical blocks.
Figure 3 - Software system layers and pillars
A software entity in a software system may be present in one or more
logical block, depending on its features, functions, and role.
For instance, a bank account entity in an on-line banking system
will most likely have several facets distributed across all logical
blocks, as the system should provide (at the very least):
Logical block Core Features acts as a comprehensive repository
of all entity features used for the entity facets listed above;
besides, one or more
documents - for instance, a user's guide to the edit form,
and a programmer's guide to the entity logic - may be produced
and kept in pillar Documentation.
- An edit form (on layer Usage Interface) to enter and view data related to the bank account;
- Some business logic (on layer Logic) to process the data provided by the user;
- A database table (on layer Data Base Storage) to store the data.
The following paragraphs describe the relationship between
software layers and pillars on one hand, and Software Entities
on the other. As explained in more detail in the
, each Software Entity file is divided in sections,
roughly corresponding to the logical blocks illustrated above.
In a similar way,
Software Molds in a Somusar/Software Mold Kit[tm] are divided in five groups, one for each
software system layer and pillar, as explained
in chapter 6
The core features of a Software Entity in a software system
are defined, in the SoProTech context, as the identification block
for the entity and
the complete set of data fields, data processing functions, and
relationships with other entities, that concur to characterize
that entity across all layers of the software system.
In other words, the core features of an entity consist of the
complete collection of the components of
all the layer-specific entity facets.
Within a Software Entity file, the core features of an entity are
described in sections CORE and DEFS, which stands
In many cases the most straightforward implementation of
the data base layer, or data storage layer,
consists of a relational
SQL data base. In addition to RDBMS the DB layer may
also include other
software mechanisms that ensure the so-called
persistence of the data of an entity:
hierarchical databases, transactional systems, plain file systems, custom
data management legacy procedures, or even the back-ends
of complex ERP (Enterprise Resource Planning)
or CRM (Customer Relationship Management) packages,
all these data management systems logically correspond to this layer.
The data storage facet, or facets, of an entity can be defined in
section DB of the corresponding Software Entity file.
The business logic, or data processing layer of a software system
is the junction layer between the data base and the usage interface
layers: the data flowing back and forth between the DB and UI
layers are processed by classes, or procedures,
implemented by means of programming languages in
a strict sense, ranging from older languages such as COBOL, RPG
and C, to newer languages such as Java[tm], C++, C#. Scripting languages
like Perl are also often used in this layer.
The LOGIC section of a Software Entity file is the repository
for the entity facet (or facets) on the logic layer.
The third layer of a typical software system is
the usage interface layer, or data presentation layer.
The SoProTech particularly emphasizes the fact that an entity
usage interface design should cover not only the (human)
user interface - usually a GUI -, but it should also comprise
generic usage interfaces for other systems,
such as protocol packet or data exchange representations, that can
be implemented as a Java[tm] class or a C struct, or as
an XML document, along with other source code.
In most cases, however, the corresponding section UI in a Software Entity
file will probably contain one or more human-oriented views of the
entity data fields and processing functions.
The SoProMach will in this case translate those views into generated
files in one or more GUI-oriented languages, such as HTML, XML,
Visual Basic®, or JSP[tm] (JavaServer Pages[tm]).
An additional pillar of software is represented by the
system documentation, called DOC in SoProTech terminology,
that should describe the implementation
of the software in a more or less technical language,
depending on the type of reader that the documentation
is intended for. The SoProTech
allows documentation to be generated at the same time
that the software is generated, thus ensuring a high
degree of consistency between the software and the documentation,
which is thus always up-to-date.
The generation of documentation follows exactly the same scheme
as for the generation of software for the layers previously discussed.
Logical block DOC has one peculiarity with respect to
layers DB, LOGIC and UI: Software Entity files do not have
a DOC section, as the files produced by
the SoProMach should document the role
and function played by the entity across the layers
of the software system, and those role and function are
already described in the other sections of the entity file.
In real world projects it is often necessary, and even
advisable, to make use of tools equipped with a flexible tolerance
mechanism, so that automatic production processes
provide some room for manual corrections and adjustments, that
can be then automatically applied by the same tools.
For this purpose Software Entity files contain an ADJUST section,
that allows entity designers to define and tune localized
parameters for any given entity, thus influencing the
software generation phase of SoProTech.
[Back to top]