Chapter 1 - Introduction

The Somusar/Software Production Technique[tm] is a new, highly efficient, cost-effective technique to produce software source code, featuring an unprecedented flexibility and a broad range of applicability in the field of multilayer - or multifacet - software development.

The reference industrial model for the Somusar/Software Production Technique[tm] has been the process of automated precision molding of physical objects, that allows to produce virtually any type of object with a high degree of quality and efficiency. In a similar way, the Somusar/Software Production Technique[tm] enables the high-speed, high-quality production of virtually any type of source code file for practically any kind of software development projects.

This document provides an overview of the Somusar/Software Production Technique[tm] - in short, SoProTech[tm]. After a short description of the benefits of the technique, followed by a concise presentation of the underlying software perspective, the document introduces the following concepts:

• Multifacet Somusar/Software Entities[tm];

• Somusar/Software Molds[tm];

• Generatable files;

• The Somusar/File Generation Scheme[tm];

• Somusar languages and language processors: Somusar/Sisendel[tm] and Somusar/Tefigel[tm], collectively referred to as the Somusar/Software Production Machine[tm].

Chapter 2 - Overview of SoProTech[tm]

A typical software development project may be described in several ways. One of the most frequently used representation of software projects shows a sequence of steps where an analysis phase is followed by a design stage; a development phase and a testing phase, followed by the system deployment and maintenance phases, complete the cycle. Each stage provides feedback to its predecessor stage, thus allowing to correct problems or improving some aspects of that stage.

The illustration below shows where the SoProTech can mainly be applied in such a software development project: the stage of development in a broad sense - including the production of technical documentation - and the final maintenance stage are the stages that can most benefit from the SoProTech. Moreover, some of the activities involved in the design and testing phase can be significantly improved by means of the SoProTech. Finally, in some specific cases or tasks of the analysis and deployment stage the SoProTech might also prove to be useful.

Chapter 3 - Software Production Using SoProTech[tm]

Generally speaking, the SoProTech is a software development tool, as it produces software in a broad sense, as explained below. However, it should be noted that SoProTech does not fully overlap with currently available software development tools: in fact, in most cases it can be easily used as an additional tool within running projects without conflicting with the tools already in use.

More specifically, SoProTech can be applied as both a process or a subprocess, and the distinction mainly depends on the size of the software development project involving SoProTech:

• Large projects or large development teams may apply SoProTech as a subprocess, that is, as one of several software design and development tools, integrating SoProTech production results (that is, generated files) in the same manner as if they had been produced by other means;

• Small projects or small development teams may apply SoProTech as a process, that is, as the main software development tool, along with traditional tools like text or visual editors, compilers, debuggers, revision control systems, and so on.

The main advantages obtained by applying the Somusar/Software Production Technique[tm] within a software development project derive from Software Entities and Software Molds.

3.1 - Benefits of Somusar/Software Entities[tm]

The Software Entities, described later in chapter 5 , introduce a new format for software entities. The concept of software entity (or component, or object) is by no means new in the software industry and in computer science: nonetheless the new format introduced by the Somusar/Software Entities[tm] offers several new advantages to software development teams and professionals, in terms of flexibility, generality, productivity, reusability, and maintainability. Software Entity files are plain text files written in Somusar/Sisendel[tm], a new simple software entity design language, described in chapter 9 .

In short, a Somusar/Software Entity[tm] allows to centralize all definitions related to the software representation of a real-world entity, thus greatly improving entity-related consistency within the target software system or application dealing with that entity.

Database tables and keys, logic processing objects, data structures, usage interfaces - for both human users and automatic systems -, all these different facets of a Software Entity can be concisely and uniformly designed within one Software Entity file. The experienced software designer and developer may rapidly grasp this concept by looking at the examples of chapter 5 .

The multifacet design contained in a Software Entity file is automatically translated by the high-speed SoProMach of the SoProTech into actual software files that implement those facets - database tables and keys, logic processing objects and data structures, and usage interfaces.

3.2 - Benefits of Somusar/Software Molds[tm]

Based on long-established and well-known development techniques, such as macro-processing, templating, and code patterns, Somusar/Software Molds[tm] - described in chapter 6 -, implement a new software concept that allows one or more software development teams to:

• Effectively record and reproduce software development guidelines and best practices, and apply them to produce, or impress, all generatable files related to the Software Entities defined within one or more software projects;

• Identify, insulate and automatize a large part of the repetitive development work within one or more software development projects.

Due to the fact that Tefigel is a purely textual computer language, Software Molds are human-readable by definition, and can thus easily be written, exchanged, and customized by any development team. More information about Tefigel is provided in chapter 9 .

Chapter 4 - Software System Layers and Pillars

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.

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 next chapter , 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 .

4.1 - Core Features

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 for definitions.

4.2 - Data Base Storage

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.

4.3 - Logic

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.

4.4 - Usage Interfaces

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]).

4.5 - Documentation

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.

4.6 - Adjusting

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.

Chapter 5 - Multifacet Software Entities

As shortly discussed in the previous chapter, a typical software entity is multifacet. For example, in a software system there may be several representations for a customer account or a product such as a mechanical brake, namely:

• A data table row in a relational SQL database;

• One or more classes, written in an object-oriented language, such as Java[tm], that implement the logic of the software entity and allow it to interact with the other entities in the system;

• One or more usage interfaces, such as an HTML form, to allow human users to access the data that describe the entity within the system; or such as a data packet description, to allow the import/export of the entity data respectively from/to other software systems.

5.1 - Examples of Somusar/Software Entities[tm]

Entity files are plain text files with a ".ef" extension, that contain the definition, written in Sisendel, of exactly one Somusar/Software Entity[tm]. The following code examples show two (simplified) typical Software Entities, representing business projects and company departments, extracted from a small-scale sample project that is fully described in booklet "Somusar/Software Production Technique[tm]: A Sample Project ". Syntax and semantics of Sisendel are explained in detail in "Somusar/Sisendel[tm]: A Tutorial Introduction "and "Somusar/Sisendel[tm]: Reference Guide ".

Code Example 1 - Software Entity "project"

    1      project "Project"
    2      | A project within a company, some information about it, a project
    3      | manager, the involved personnel, a project plan and budget
    4      
    5      strings.name            proj_name       "Project name"
    6      strings.id              proj_id         "Project id."
    7      strings.description     descr           "Description"
    8      link customer           customer        "Customer"
    9      float                   budget          "Budget (K$)"
   10      list employee           team_members    "Team members"
   11      link employee           manager         "Proj. manager"
   12      link department         department      "Department"
   13      bool                    internal        "Internal"
   14      thing                   plan            "Proj. plan"
   15      function                cur_status      "Current proj. status"
   16      enum                    status          "Proj. status"
   17      
   18      ----------------------- DEFS
   19      budget:
   20         0/1000
   21      status:
   22         ok           "OK"
   23         late         "Late"
   24         danger       "Danger"
   25      cur_status:
   26         plan, budget -> status
   27      ----------------------- DB
   28      table:
   29         proj_id, proj_name, descr, customer, budget, team_members,
   30         manager, department, internal
   31      pkey:
   32         proj_id
   33      ----------------------- LOGIC
   34      class:
   35         proj_id, proj_name, descr, customer, budget, team_members,
   36         manager, department, internal, cur_status
   37      ----------------------- UI
   38      full_view:
   39      proj_name  proj_id
   40      customer   descr
   41      budget     cur_status
   42      manager    team_members
   43      department internal 
   44      
   45      compact_view:
   46      proj_name, customer, budget
   47      ----------------------- ADJUST
   48      DB.table.create = "true"
	       

    1      department "Department"
    2      | A department within a company
    3      
    4      strings.name            dept_name       "Dept. name"
    5      strings.id              dept_id         "Dept. id."
    6      link employee           manager         "Manager"
    7      list employee           members         "Dept. members"
    8      list project            projects        "Dept. projects"
    9      function                curr_projects   "Current projects"
   10      
   11      ----------------------- DEFS
   12      curr_projects:
   13         dept_id -> projects
   14      ----------------------- DB
   15      table:
   16         dept_id, dept_name, manager, members
   17      pkey:
   18         dept_id
   19      ----------------------- LOGIC
   20      class:
   21         dept_name, dept_id, manager, members, curr_projects
   22      ----------------------- UI
   23      full_view:
   24      dept_name
   25      dept_id
   26      manager
   27      members
   28      curr_projects
   29      
   30      compact_view:
   31      dept_name, manager
   32      ----------------------- ADJUST
   33      DB.table.create = "true"
	       

Chapter 6 - Software Molds

A Somusar/Software Mold[tm] is an implementation of the Somusar/File Generation Scheme[tm], which is a predefined set of steps to construct a software file, as explained later in chapter 8 .

Software Molds consist of pre-structured file-system subtrees containing a set of scripts, written in Tefigel, that allow the high-speed production of exactly one generatable file per mold, starting from any given Software Entity within a project.

A Somusar/Software Mold Kit[tm] is a set of Software Molds divided in groups (subdirectories) according to the software logical block that they belong to within the target software system: for example, there might be two different molds to generate two different types of HTML files, one for the usage interface (layer UI), and the other for documentation purposes (pillar DOC).

The following table shortly describes each mold group, relating the set of files that its molds can generate to the corresponding software system logical block.

Thanks to their structure, the Software Molds are extremely flexible, and can be very easily moved from project to project, and from team to team, thus allowing common guidelines and "best practices" to be shared among the members of one or more projects and development teams.

6.1 - Examples of Somusar/Software Molds[tm]

The following illustrations show examples of the directory structure that a Software Mold consists of.

The first mold allows to generate an SQL script file for the DB layer. The illustration below shows that the process of generating that SQL file requires 2 consecutive steps, corresponding to the subdirectories 1 and 2 of the mold directory "DB/mold1-.sql".

For example, the Java[tm] mold shown above produces fairly straightforward Java[tm] classes, by far much simpler than the set of classes per entity required by, for instance, the application model of J2EE, the Java[tm] 2 Enterprise Edition. On the other hand, the set of classes per entity required by J2EE is an excellent "real-world" candidate for a corresponding set of Software Molds.

Chapter 7 - Generatable Files

In principle, according to the definitions given earlier in this document, a generatable file can be any file that does not contain binary, non human-readable data. Thus, the current implementation of SoProTech could be theoretically used to generate any single-byte file (typically, in ASCII or ISO8859) within a software project, provided that a Software Mold be available for that purpose.

In practice, "casting" a Software Mold for a candidate generatable file (for example, a "Home.java" or a ".cs" file) is reasonable when the requirements for reproducibility and relative redundancy of the candidate are significant, which means:

• More than one Software Entity requires the generation of the candidate;

• A significant degree of similarities is expected between the files resulting by applying the same mold to two different entities.

Besides, it should be noted that the SoProMach provides a trigger mechanism to ensure that only the files strictly required by the project team get actually generated. This mechanism allows the project team to keep the combinatorial explosion of generated files under control.

7.1 - Examples of Generated Files

The following eight generated files result from processing the example entities listed before, namely "project.ef" and "department.ef", through the four Software Molds described in the previous chapter:

• "DB/mold1-.sql";

• "LOGIC/mold1-.java";

• "UI/mold3-.html";

• "DOC/mold1-.html".

7.1.1 - Generated SQL Scripts

The SQL script files of this paragraph derive from the collections of entity fields contained in section DB of the correspondent Software Entity file. The relevant collections are labelled by project convention table and pkey.

Code Example 3 - From "project.ef" to "DB/project.sql"

    1      --
    2      -- This SQL script created by somusar/SoProMach[tm]
    3      --
    4      
    5      create table project (
    6          projid                    varchar(10),
    7          projname                  varchar(40),
    8          descr                     varchar(200),
    9          companyname               varchar(80),
   10          budget                    decimal(10,2),
   11          teammembersemplid         int,
   12          manageremplid             int,
   13          deptid                    varchar(10),
   14          internal                  char(1),
   15          constraint pk_project     primary key    (projid)
   16      )
   17      ;
   18      
	       

    1      --
    2      -- This SQL script created by somusar/SoProMach[tm]
    3      --
    4      
    5      create table department (
    6          deptid                    varchar(10),
    7          deptname                  varchar(40),
    8          manageremplid             int,
    9          membersemplid             int,
   10          constraint pk_department  primary key    (deptid)
   11      )
   12      ;
   13      
	       

7.1.2 - Generated Java[tm] Classes

The generated Java[tm] source code files described in this paragraph have been produced by SoProMach from collection class in section LOGIC of the corresponding Software Entities. In the sample project described in "Somusar/Software Production Technique[tm]: A Sample Project ", the same collection class drives the generation of C++ source files containing the C++ equivalent of the Java[tm] classes listed below. The generation of C++ source code in the sample project is achieved by means of another mold, namely "LOGIC/mold3-.h".

Code Example 5 - From "project.ef" to "LOGIC/Project.java"

    1      /*
    2       * This Java class generated by somusar/SoProMach[tm].
    3       */
    4      
    5      package com.somusar.entdemo.business;
    6      
    7      /**
    8       *   Class Project:
    9       *
   10       *   A project within a company, some information about it, 
   11       *   a project manager, the involved personnel, a project 
   12       *   plan and budget.
   13       */
   14      
   15      import com.somusar.entdemo.business.Customer;
   16      import com.somusar.entdemo.company.Employee;
   17      import java.util.Collection;
   18      import com.somusar.entdemo.company.Department;
   19      
   20      public class Project {
   21      
   22          // Map enum 'Proj. status' onto an int with a set of values
   23          public final int OK                 = 0; // OK
   24          public final int LATE               = 1; // Late
   25          public final int DANGER             = 2; // Danger
   26      
   27          private String       projId;             
   28          private String       projName;           
   29          private String       descr;              
   30          private String       customerCompanyName;   // relationship to Customer
   31          private double       budget;             // range 0-1000
   32          private Collection   teamMembers;        
   33          private int          managerEmplId;      // relationship to Employee
   34          private String       departmentDeptId;   // relationship to Department
   35          private boolean      internal;           
   36          
   37          /*
   38           *   Get methods
   39           */
   40      
   41          public String getProjId() {
   42              return projId;
   43          }
   44      
   45          public String getProjName() {
   46              return projName;
   47          }
   48      
   49          public String getDescr() {
   50              return descr;
   51          }
   52      
   53          public String getCustomerCompanyName() {
   54              return customerCompanyName;
   55          }
   56      
   57          public double getBudget() {
   58              return budget;
   59          }
   60      
   61          public Collection getTeamMembers() {
   62              return teamMembers;
   63          }
   64      
   65          public int getManagerEmplId() {
   66              return managerEmplId;
   67          }
   68      
   69          public String getDepartmentDeptId() {
   70              return departmentDeptId;
   71          }
   72      
   73          public boolean getInternal() {
   74              return internal;
   75          }
   76      
   77          /*
   78           *   Set methods
   79           */
   80      
   81          public void setProjId( String projId ) {
   82              this.projId = projId;
   83          }
   84      
   85          public void setProjName( String projName ) {
   86              this.projName = projName;
   87          }
   88      
   89          public void setDescr( String descr ) {
   90              this.descr = descr;
   91          }
   92      
   93          public void setCustomerCompanyName( String customerCompanyName ) {
   94              this.customerCompanyName = customerCompanyName;
   95          }
   96      
   97          public void setBudget( double budget ) {
   98              this.budget = budget;
   99          }
  100      
  101          public void setTeamMembers( Collection teamMembers ) {
  102              this.teamMembers = teamMembers;
  103          }
  104      
  105          public void setManagerEmplId( int managerEmplId ) {
  106              this.managerEmplId = managerEmplId;
  107          }
  108      
  109          public void setDepartmentDeptId( String departmentDeptId ) {
  110              this.departmentDeptId = departmentDeptId;
  111          }
  112      
  113          public void setInternal( boolean internal ) {
  114              this.internal = internal;
  115          }
  116      
  117          /**
  118           *   Method 'Current proj. status'
  119           */
  120      
  121          // Return type corresponds to enum 'Proj. status'
  122          public int curStatus (
  123                          Object plan,
  124                          double budget
  125                 )
  126          {
  127              // insert your Java method code here
  128          }
  129      
  130      }
	       

    1      /*
    2       * This Java class generated by somusar/SoProMach[tm].
    3       */
    4      
    5      package com.somusar.entdemo.company;
    6      
    7      /**
    8       *   Class Department:
    9       *
   10       *   A department within a company.
   11       */
   12      
   13      import com.somusar.entdemo.company.Employee;
   14      import java.util.Collection;
   15      
   16      public class Department {
   17      
   18          private String       deptName;           
   19          private String       deptId;             
   20          private int          managerEmplId;      // relationship to Employee
   21          private Collection   members;            
   22          
   23          /*
   24           *   Get methods
   25           */
   26      
   27          public String getDeptName() {
   28              return deptName;
   29          }
   30      
   31          public String getDeptId() {
   32              return deptId;
   33          }
   34      
   35          public int getManagerEmplId() {
   36              return managerEmplId;
   37          }
   38      
   39          public Collection getMembers() {
   40              return members;
   41          }
   42      
   43          /*
   44           *   Set methods
   45           */
   46      
   47          public void setDeptName( String deptName ) {
   48              this.deptName = deptName;
   49          }
   50      
   51          public void setDeptId( String deptId ) {
   52              this.deptId = deptId;
   53          }
   54      
   55          public void setManagerEmplId( int managerEmplId ) {
   56              this.managerEmplId = managerEmplId;
   57          }
   58      
   59          public void setMembers( Collection members ) {
   60              this.members = members;
   61          }
   62      
   63          /**
   64           *   Method 'Current projects'
   65           */
   66      
   67          public Collection currProjects (
   68                          String deptId
   69                 )
   70          {
   71              // insert your Java method code here
   72          }
   73      
   74      }
	       

7.1.3 - Generated HTML UI Forms

The illustrations in this paragraph show how collection full_view of section UI is translated by the SoProMach into a corresponding HTML form: the row-column layout of the entity data fields in the form exactly matches the row-column layout of the corresponding full_view.

The other parts of the form (such as the company logo, navigation bar, and so on) are entity-independent, therefore their design can be centralized in the HTML mold, rather than being replicated for each entity. In this way a much higher degree of maintainability is achieved: for example, applying a generalized layout change - like adding a new vertical bar - to all forms in one or more projects only requires two simple steps:

1. Apply that particular change only once in the appropriate mold;

2. Re-impress (that is, regenerate) all HTML forms using the SoProMach.

7.1.4 - Generated HTML DOC Forms

The figures in this paragraph show the results of mold "DOC/mold1-.html": two compact documents, each describing the main features of an entity and containing useful information about it, such as a cross-reference table that summarizes the use of the entity fields in the different entity collections.

Chapter 8 - The Somusar/File Generation Scheme[tm]

The bridge between entity files and molds on one side, and generated files on the other, is realized by the File Generation Scheme, applied by the SoProMach.

It lies outside the scope of this tutorial to discuss in depth this production scheme: nonetheless a short description is useful for a better understanding of the mold structure.

The Somusar/Software Production Technique[tm] defines the following six hierarchical levels for the production of a software file in the context of a software development project, independently of the language used for the output file:

1. Project: the repository of entities and molds, the latter containing the set of project conventions and generatable files for the target software system;

2. Logical block: the layers and pillars of the target software system, corresponding to the five facets of a Software Entity, namely CORE, DB, LOGIC, UI, DOC; the project molds, collectively referred to as the project mold kit, are divided in five groups (five directories), one for each logical block;

3. File: a generated file, resulting from applying the generalized File Generation Scheme - implemented by a mold - to the specific features of an entity; the generic structure of a generatable file consists of a header, a sequence of generatable blocks, and a trailer;

4. Step: a subset of all production actions required to generate a file; each step produces one generatable block;

5. Collection: the input unit of work for a step, consisting of one or more entity fields;

6. Entity fields: the basic building block of an entity, defined by an identifier, a type, and a label.

8.1 - Applying the File Generation Scheme

The figures and code sample in the next paragraphs show the mapping between the File Generation Scheme of three molds, and three files generated by the SoProMach applying those molds.

8.1.1 - Sample SQL File Generation Scheme

The illustration below shows the relationship between the structure of mold "DB/mold1-.sql" and the contents of file "business/DB/customer.sql": the header and trailer of the file are produced at the beginning and at the end of the molding stage, respectively; two generation steps within the mold process collections DB.table and DB.pkey respectively.

8.1.2 - Sample Java[tm] File Generation Scheme

The following code example describes how the File Generation Scheme of mold "LOGIC/mold1-.java" produced source file "company/LOGIC/Employee.java".

Code Example 7 - File generation scheme of "LOGIC/Employee.java"

    1      /*
    2       * This Java class generated by somusar/SoProMach[tm].
    3       */
    4      
    5      package com.somusar.entdemo.company;
    6      
    7      /**
    8       *   Class Employee:
    9       *
   10       *   An employee, some related information, and the 
   11       *   department s/he works in.
   12       */
   13      
   14      import com.somusar.entdemo.persons.Person;
   15      import com.somusar.entdemo.persons.PersonInfo;
   16      import com.somusar.entdemo.company.Department;
   17      
   18      public class Employee extends Person {
   19      
   20          // Map enum 'Position' onto an int with a set of values
   21          public final int PRESIDENT          = 0; // President
   22          public final int VICE_PRESIDENT     = 1; // Vice-president
   23          public final int MANAGER            = 2; // Manager
   24          public final int ADMIN              = 3; // Admin
   25          public final int SALES_REP          = 4; // Sales rep.
   26          public final int ENGINEER           = 5; // Engineer
   27      
   28          private int          emplId;             
   29          private PersonInfo   info;               
   30          private String       deptDeptId;         // relationship to Department
   31          private int          position;           // enum 'Position'
   32          private double       salary;             // range 0-1000000
   33          
   34          /*
   35           *   Get methods
   36           */
   37      
   38          public int getEmplId() {
   39              return emplId;
   40          }
   41      
   42          public PersonInfo getInfo() {
   43              return info;
   44          }
   45      
   46          public String getDeptDeptId() {
   47              return deptDeptId;
   48          }
   49      
   50          public int getPosition() {
   51              return position;
   52          }
   53      
   54          public double getSalary() {
   55              return salary;
   56          }
   57      
   58          /*
   59           *   Set methods
   60           */
   61      
   62          public void setEmplId( int emplId ) {
   63              this.emplId = emplId;
   64          }
   65      
   66          public void setInfo( PersonInfo info ) {
   67              this.info = info;
   68          }
   69      
   70          public void setDeptDeptId( String deptDeptId ) {
   71              this.deptDeptId = deptDeptId;
   72          }
   73      
   74          public void setPosition( int position ) {
   75              this.position = position;
   76          }
   77      
   78          public void setSalary( double salary ) {
   79              this.salary = salary;
   80          }
   81      
   82      }
	       

8.1.3 - Sample HTML File Generation Scheme

The next figure shows the mapping between the structure of mold "DOC/mold1-.html" and file "company/DOC/company.html". Again, the header and trailer of the file are produced at the beginning and at the end of the molding stage, respectively; three generation steps within the mold process the list of entity fields (1), the function members (2) and the enumeration fields (3).

Chapter 9 - The Somusar Languages and Language Processors

This chapter briefly introduces the two languages, as well as the related language processors, that constitute the SoProMach:

• Somusar/Sisendel[tm], also referred to as Sisendel;

• Somusar/Tefigel[tm], also referred to as Tefigel.

Within the SoProTech, entity designers need only use Sisendel, as Tefigel is the back-end language, and thus is used only by mold builders. Nevertheless, Tefigel can be used by software developers as a stand-alone tool, for example as a generalized macroprocessor or preprocessor for practically any source code language. In particular, the original text of this very document, as well as that of all Somusar technical documents and web site pages, is written in Tefigel.

9.1 - Somusar/Sisendel[tm]

As described earlier in this document, Sisendel is the language and processor for the Software Entities. It is a highly specialized computer language, in that its specific purpose is to serve as a simple software entity design language, to aid software developers and designers in automatizing the production of software source files.

The input to the Sisendel processor consists of one or more entity files; its intermediate output is a set of Tefigel scripts related to the mold kit of the current project. Sisendel automatically and transparently runs Tefigel to produce the target source code files, which are the main output of the SoProMach.

A very small set of environment variables provides Sisendel with enough information about the current project, which - as explained in detail in the next chapter - basically consists of a set of Software Entities and a set of Software Molds.

More information about Sisendel can be found in "Somusar/Sisendel[tm]: A Tutorial Introduction " and "Somusar/Sisendel[tm]: Reference Guide ".

9.2 - Somusar/Tefigel[tm]

Tefigel is a text file generation language: in a way, it is a hybrid of text file and language processors, as its input can be in principle any human-readable text file in any single-byte (typically, ASCII or ISO8859) character set, but it features all necessary constructs to perform basic general-purpose computation, although its main purpose is to output text files, in particular files containing source code of virtually any computer language. Tefigel statements can be freely intermixed with plain text: the statements are interpreted and executed, and the plain input text is by default copied to output.

Main features of Tefigel are the following:

• Translation of one or more input files to one or more output files;

• Multilevel placeholder substitution: variables in Tefigel allow transparent name-to-value substitution from input to output;

• File-oriented modularity: functions and subroutines in Tefigel are also text files, directly accessed via their path name;

• Dynamic syntax constructs and operators;

• Traditional set of control flow statements, such as IF and WHILE;

• Non-intrusive translation of input to output: Tefigel for instance by default preserves from input to output even the blank and tab formatting of the input text;

• Processing speed.

    1      Hello, world!
	       

    1      Text lines, not to be altered by tefigel, as they contain neither
    2      tefigel variables, nor tefigel commands.
    3      @ echo Command line, echo message.
    4      @ set MESSAGE="Hello!"
    5      % echo Not a command line (yet), but contains a variable: MESSAGE.
    6      @ mark CMD %
    7      % echo Now a command line, due to command mark CMD. Variable: MESSAGE.
    8      % unset MESSAGE
    9      % echo After unset, variable MESSAGE is no longer a variable.
   10      % mark CMD
   11      % echo '%' is no longer the command line marker.
   12        Some more text lines, not to be altered by tefigel, as they contain
   13        neither tefigel variables, nor tefigel commands. Note that white
   14        s p a c e s   within text lines     are     left           untouched.    
	       

Chapter 10 - Structure of a SoProTech Project

A SoProTech project consists of two sets of entities - the project and the library entities -, one mold kit, and the source files generated by the SoProMach. Entities, molds and generated files are by default subdirectories of one file-system directory, called the SoProTech project directory, but this default configuration can be easily changed by means of environment variables. The components of a SoProTech project are shown in the illustration below.

10.1 - Project Entities

Project entities are Software Entity files that by default reside under a directory called "project". Under that directory, the project entities can be freely distributed across subdirectories, each representing a significant logical block of the project, typically a package. The SoProMach automatically retrieves all entity files and keeps track of the logical block that they belong to, when generating the target source files. The same logical structure used for the entities can thus be automatically replicated and used to create, for instance, Java[tm] packages.

10.2 - Library Entities

Library entities are Software Entity files that by default reside under a directory called "library". The same considerations made for project entities apply for library entities as well: under the "library" directory, it is possible to define any logical group of entities by simply creating a corresponding set of subdirectories. In fact, library entities themselves should be viewed as the set of project entities of an independent SoProTech project: this library entity project differs from a normal SoProTech project in that it has no library entities.

Library entities and the related generated files should be shared and reused across several SoProTech projects; no change to the library entities should directly occur in any project using them. Instead, any request for change to a library entity should be submitted to the project team responsible for the library entity project, to ensure that the requested change does not conflict with the other projects using the same set of library entities.

For example, a library entity called "ident.ef" may contain, among others, the company-wide definition of a product identifier, called prod_id. Changes to such an identifier should only be applied by the entity library project team, and not by any of the application project teams.

10.3 - Software Mold kit

The kit of Software Molds of a SoProTech project is contained in a subdirectory of the SoProTech project directory; the subdirectory is called by default "moldkit". As the following figure shows, this directory contains one subdirectory for each logical block - layers and pillars, as previously described - of the target software system, namely CORE, DB, LOGIC, UI, and DOC. Each of these subdirectories - also called mold groups - contain the set of Software Molds that are relevant to the corresponding logical block.

A mold kit may be private to a SoProTech project, as well as shared among several project teams. In the latter case, changes to the mold kit should be handled in the same way described above for library entities: a responsible for the mold kit should ensure that mold changes required by a project team do not impact any other project team using the same mold kit. The SoProTech and the File Generation Scheme provide a means to centrally customize a shared mold kit, in order to meet specific requirements of one or more of the project teams sharing that mold kit.

10.4 - Generated Files

As shown in the illustration below, each generated file is located under a subdirectory at the same project level of the entity that it is derived from. The name of this subdirectory - one of CORE, DB, LOGIC, UI, DOC - corresponds to the name of the facet and mold group that are relevant to the generated file itself.

For example, applying mold "moldkit/DB/mold1-.sql" to the DB facet of entity file "business/project.ef" by default generates file "business/DB/project.sql".

As discussed earlier in this document, the SoProTech does not provide an all-in-one solution to software development: instead, it should be considered as an additional, high-speed tool to automatically produce software source files. Generated source files can then be merged into a traditional project tree, as if provided by an external source.

10.5 - Teamwork and Roles in a SoProTech Project

This paragraph describes the suggested approach for working with SoProTech, independently of the size of the project and project team that may decide to use it. A teamwork scheme and a corresponding small set of project roles are suggested, to better explain the activities involved by SoProTech. Large project teams may assign one or more persons to play one role, as opposed to small project teams, that may assign two or more roles to one person - not to mention individual and independent developers, who will play all roles.

The overall teamwork scheme is illustrated by the following figure, and described in the next paragraphs.

10.5.1 - Entity Designer

The designer of Software Entities is in charge of producing Software Entity files - the actual ".ef" files. The main tasks assigned to an entity designer are the following:

• Translate the system concept design into software entities;

• Contribute to the definition of the project guidelines and conventions;

• Define the core structure of entities.

10.5.2 - Layer Expert

The system layer expert does not directly produce any tangible deliverable, such as Software Entities or Software Molds; instead, the main result of a layer expert's activity is layer knowledge for entity facets, layer-specific generatable files, and molds. The main tasks assigned to a layer expert are the following:

• Contribute with his/her layer knowledge (CORE, DB, LOGIC, UI, DOC) to the design of entities;

• Contribute to the selection and sample production of generatable files;

• Contribute to the production of molds;

• Define mapping between Sisendel basic data types and layer-specific types.

10.5.3 - Sample File Developer

The developer of sample files is in charge of producing layer-specific samples of generatable files. The main tasks assigned to a sample file developer are the following:

• Produce sample generatable files in any given language for a given layer (CORE, DB, LOGIC, UI, DOC) using any favorite layer-specific tool;

• Contribute to the definition of the project guidelines and conventions.

10.5.4 - Software Mold Maker

The mold maker is in charge of delivering Somusar/Software Molds[tm]. The main tasks assigned to a mold maker are the following:

• Translate the sample generatable files into software molds;

• Implement in molds the project guidelines and conventions.

10.5.5 - Somusar

As previously shown in the teamwork scheme figure, an additional player in the SoProTech project team is Somusar. The Somusar contribution to a SoProTech project includes the following:

• Provide the project team with the SoProMach, that consists of the high-speed processors for Sisendel and Tefigel, the languages for Software Entities and Software Molds;

• Make molds on request, playing the mold maker role;

• Deliver on request consultancy services on SoProTech projects.

Chapter 11 - Further Reading

Additional information on the different aspects of the Somusar/Software Production Technique[tm] can be found in the other volumes of the Somusar/SoProTech[tm] Booklet Series, listed below.

Vol. II - somusar/SoProTech: A Sample Project

Description of a sample project, serving as a proof-of-concept for the Somusar/Software Production Technique[tm], and the Somusar/Sisendel[tm] and Somusar/Tefigel[tm] languages. A few code examples are provided and demonstrate the practical applicability of the technique.