|
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
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"
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
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"
|
|
|
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
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"
|
|
[Previous chapter]
[Next chapter]
[Back to top]
|
