Home Page   We Generate Your Software.
Products Services Company Technology Demo Contact Site Map Search
Please note: this document is currently under revision.
The information herein contained, while still valid, does not reflect the latest state of the described technology.
The Somusar/SoProTech[tm] Booklet Series
Volume I

"somusar/SoProTech: An Introduction"

Printer friendly

1. Introduction
2. Overview of SoProTech[tm]
3. Software Production Using SoProTech[tm]
4. Software System Layers and Pillars
5. Multifacet Software Entities
5.1 Examples of Somusar/Software Entities[tm]
6. Software Molds
7. Generatable Files
8. The Somusar/File Generation Scheme[tm]
9. The Somusar Languages and Language Processors
10. Structure of a SoProTech Project
11. Further Reading

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.

Note that it is very seldom the case that each facet corresponds one-to-one to any of the other facets: some data fields may be stored in the database, but not made accessible at the user interface level; the logic processing layer may contain several entity processing functions - object class methods, in object-oriented terminology - that may have no counterparts in the database layer.

Nevertheless, several features of the entity may appear on more than one layer of the software system, most often with a different representation.

As the next figure shows, a bank account software entity could have a "Cancel" button on its user interface, which would map to a cancel method in its logic, that would not map to anything on the database tier; instead, a rollback would probably be called. On the other hand, the same bank account would most certainly have an account number, mapped to a (possibly locked) text edit field on the user interface, to an integer in the logic layer, and to a serial number in the database layer.

Figure 4 - Multifacet software entity members
Figure 4 - Multifacet software entity members

From a different perspective of software engineering, in order to improve consistency and maintainability of a software system, it is most often advisable to always use the same representation of a software item within any given software layer. For example, a choice of type "yes/no" should always be represented within one software system by a check-box on the user interface layer, by a boolean member in a logic class, and by a one-character column in a database table, independently of the software entity that the choice belongs to.

Consistency and maintainability across all layers (or tiers) of an entity, as well as consistency and maintainability across all entities on a tier, can become very difficult to keep, and may require a significant amount of manual labor. By reducing redundancy and centralizing all structural information about software entities and software layers, and by automatizing a large part of the involved manual labor, SoProTech can be of great help in achieving higher degrees of consistency, maintainability, and productivity within one or several software development projects.

Anticipating the discussion and examples of the next paragraph, the following figure illustrates the concept of Software Entity, graphically represented by a labelled pentagon, and shows an example of the actual contents of a sample Software Entity file, namely "business/project.ef".

Figure 5 - Sample entity "business/project.ef"
Figure 5 - Sample entity <tt>"business/project.ef"</tt>

5.1 - Examples of Somusar/Software Entities[tm]        top

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"
This Somusar/Software Entity[tm] shows all basic features of Somusar/Sisendel[tm], namely:
  • A CORE section (lines 1-17) and a DEFS section (lines 18-26) that list all fields, or members, and define all properties of the Software Entity;

  • A DB section (lines 28-31), specifying which fields should be stored in a database table, and defining a primary key (pkey) to the entity data;

  • A LOGIC section (lines 32-34), specifying which fields should become members of the class that manages the logic of the Software Entity;

  • A UI section (lines 35-41), specifying which fields should appear in a full view of the Software Entity on an interaction channel, such as a web browser;

  • An ADJUST section (lines 42-43), specifying any peculiarity of the Software Entity: in this case, Sisendel should generate a software script to create in a database a table, the columns of which are the table fields listed in section DB.

A few notes:
  • Comments (lines 2-3) are not ignored by Sisendel: instead, they can be referred to from within any Software Mold and written into any generated file;

  • Within the CORE section each field (lines 5-16) is assigned an identifier, used within the other sections to refer to a specific field: for example, section DEFS contains the definition of the range (0-1000) of field budget, as well as the list of possible values of field status;

  • Each symbolic identifier is coupled with a human-readable label: the entity (line 1), its fields (lines 5-16), and the symbolic values of enumeration fields (lines 22-24) are all labelled with a string of characters that can be used within any Software Mold, and written into any generated file;

  • The full_view within section UI specifies also the layout of the interaction view of the entity: in this case, the interaction view consists of five rows and two columns, with fields proj_name and proj_id appearing at the top of the view, and fields department and internal appearing at the bottom.

Source code - File "business/project.ef"
    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
    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"
   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 
   45      compact_view:
   46      proj_name, customer, budget
   47      ----------------------- ADJUST
   48      DB.table.create = "true"

Code Example 2 - Software Entity "department"
The Software Entity department is similar, in terms of structure, to the project entity. It is worthwile to note that:
  • Different sections of the entity file may freely use different subsets, or collections, of the entity fields: for example, collection table of section DB does not use field curr_projects, which is used instead by collection class of section LOGIC and by collection full_view of section UI;

  • The definitions of fields dept_name and dept_id (lines 4 and 5) are imported from another Software Entity, namely strings, which is an example of a library entity that can be shared among different projects involving different teams;

  • Field projects (line 9) is a list of projects: this is an example of relationship between two Somusar/Software Entities[tm]. Another example is given by fields manager and members (lines 6 and 7), which are respectively a link to one, and a list of possibly many, employees;

  • Relationships, like fields manager and members, can be used as any other field within collections, as shown on lines 16, 21, 26 and 27; the mapping of relationships to the proper computer language construct(s) used for each section is implemented within the corresponding Software Molds, as it depends on the generated language and on the project conventions and guidelines.

Source code - File "company/department.ef"
    1      department "Department"
    2      | A department within a company
    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"
   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
   30      compact_view:
   31      dept_name, manager
   32      ----------------------- ADJUST
   33      DB.table.create = "true"

[Previous chapter]    [Next chapter]    [Back to top]

http:// www.somusar.com  / doc  / booklets  / intro  - Powered by SoProMach
Copyright © 2003-2012 Somusar - Trademarks - Legal - Privacy - Webmaster