|
The Somusar/Software Entities[tm] are plain text files containing a formal,
yet simple, definition of the several facets that a
software entity (in a broad sense) may have with respect
to the several layers, or tiers, that a complex software system
may consist of.
As an example, the software representation of a customer
may include the following facets:
- The columns of the database table containing customer data;
- The members and methods of the object class used to process customer data;
- The interaction items of the user interface that allow to enter, edit, and view, the customer data.
The three facets listed above may be, and usually are, implemented
using different computer languages: SQL, Java[tm] and HTML may for
instance be used for those facets. In most real cases,
each facet may offer a different
view of the customer data: the SQL, Java[tm] and HTML subsets of
customer data and data processing functions may logically not
completely overlap; for example, the HTML user interface
may display a string of characters containing the
result of a floating point operation performed by a method of the
Java[tm] class on the basis of two SQL database columns.
Sisendel allows to gather all facets of a software entity
and describe them in a simple fashion within one text file
that lists all data fields and data processing functions
related to that entity. Moreover, the contents of the entity file
drive the high-speed, multifacet software generation
performed by the Sisendel language processor within the context
of the Somusar/Software Production Technique[tm].
The foundation of a Software Entity consists of the list
of its fields - its data items and data processing functions.
Upon this foundation, the facets of an entity are described in terms
of one or more collections (subsets) of fields, one facet for each
software layer or tier: for each facet an appropriate section
is provided within the entity file.
Entity fields in Sisendel are very flexible and comparatively
simple to define,
as they should as easily as possible be mapped to the large variety
of computer languages, and related types, that Sisendel can generate.
Simplicity is achieved by means of a fairly small set of predefined or
basic field types; flexibility is obtained by leaving
the mapping between Sisendel types and other languages'
types outside the Sisendel
language, and by implementing that mapping in the molds.
New Sisendel types, or user types can be defined
by simply creating entity files: for example, to
define the new Sisendel types project and department
a developer simply needs to create - anywhere in the project
or library directory tree - two new entity files "project.ef" and
"department.ef".
An overview of the main features of entity files is
given by the following sample Somusar/Software Entity[tm].
|
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
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"
|
|
[Previous chapter]
[Next chapter]
[Back to top]
|
