Home Page   We Generate Your Software.
Products Services Company Technology Demo Contact Site Map Search
The Somusar/SoProTech[tm] Booklet Series
Volume II

"somusar/SoProTech: A Sample Project"

Printer friendly

1. Introduction
2. Sample Project Entities
3. Sample Project Mold Kit
4. Project Conventions
4.1 Naming Conventions
4.2 Layer Design Conventions
4.3 Multilayer Conventions
5. Exercise 1: Adding Field currency to Entity country
6. Exercise 2: Adding Entity "company.ef"
7. Exercise 3: Changing all SQL Scripts and all HTML Forms
8. Further Reading
Appendix A - Project Entity Files
Appendix B - Library Entities

Chapter 4 - Project Conventions

Even if the sample project is a small, simple project, nonetheless it allows to define a number of conventions that the molds should implement and possibly verify, for instance to issue a warning message in case of inconsistency. Project conventions vary in type and complexity, ranging from simple naming and layer design conventions to more complex multilayer conventions.

In most cases the most simple conventions are usually implicitly assumed by an expert project team, which is reasonable: the intent of this paragraph is simply to show that even such fine-grained conventions can be actively implemented and documented in a set of molds.

4.1 - Naming Conventions        top

The following table describes some naming conventions, indicating in which mold, or part thereof, or toolkit script, they are implemented.

Table 5 - Sample project naming conventions

Convention Description Example Relevant mold or script
Database column names Should be all in lower case letters with no underscores emplid DB/
Java[tm] class member names Should be in mixed upper case and lower case letters with no underscores EmplId LOGIC/
Java[tm] class source file names Should match the Java[tm] class name, with the first letter in upper case Customer LOGIC/

4.2 - Layer Design Conventions        top

A project convention that impacts the design style of a single system layer level can be classified as a layer design convention: for example, deciding that an entity should have exactly one primary key at DB level does not force to use exactly the same key in the UI design of a search function for the entity. In most cases, layer design conventions are a matter of programming style in a broad sense.

The following table describes some conventions of layer design, indicating in which mold, or part thereof, or toolkit script, they are implemented.

Table 6 - Sample project layer design conventions

Convention Description Example Relevant mold or script
DB collections Each entity requiring SQL data persistence should define collections DB.table and DB.pkey; collection DB.null is optional table:
company_name, address, contact
UI collections Each entity requiring an HTML data editing/viewing form should define collections UI.full_view and UI.compact_view full_view:
Database table keys Each database table should have exactly one primary key constraint
  primary key
HTML form buttons Each full_view HTML form should have the same set of buttons at the bottom of its entity workspace New
C++ enumeration values Should be identified by upper case symbolic names and their values should always be explicitly expressed VICE_PRESIDENT =

4.3 - Multilayer Conventions        top

Multilayer conventions are those project conventions that affect more than one software system layer. For example, the decision on how a simple relationship between two entities is implemented in the DB, LOGIC and UI layers may have a major influence on the performance and maintainability of the target software system.

Another example of multilayer convention is what can be defined as the middleware relay that transmits a request from the UI to a legacy transaction - logically belonging to the DB layer - via an intermediate dispatcher at the LOGIC layer level.

This type of conventions usually involves overall software system design decisions, that should ideally be agreed upon by the project team at project start-up time. These conventions are particularly important from the SoProTech perspective, because:

  • They can benefit from the specialized skills of the experts of the different layers, who can identify the best guidelines and patterns for each layer;

  • They can be recorded in molds, fine-tuned at system-test time, and then centrally maintained and reused in new projects;

  • They relief Software Entity designers from the implementation details of the various layers, allowing them to use the simple, powerful, and layer-independent concepts of entities and collections, in order to concentrate their productivity on multientity and multilayer design decisions.

The following table describes some multilayer conventions of the sample project, specifying in which mold or script they are implemented.

Table 7 - Sample project multilayer conventions

Convention Description Example Relevant mold or script
SQL mapping of Sisendel enums Sisendel enums should be mapped to SQL varchar, large enough to hold the Sisendel enum label position
Java[tm] mapping of Sisendel enums Sisendel enums should be mapped to Java[tm] int private members, whereas their values should be implemented as final int public members identified by upper case symbolic names public final int
  = 1;
private int


HTML mapping of Sisendel enums Sisendel enums should be mapped to HTML select/option lists, and the labels of their values should appear as both value and label of the HTML option <option value=

It should be noted that the three mappings in the example above are tightly related with one another: when option Vice-president is selected by a user on the data-entry HTML form at UI level, the LOGIC-layer Java[tm] class member position gets set to VICE_PRESIDENT. Finally, when an SQL insert or update is executed, the DB column position is set to "Vice-president". In this particular case, it would probably make sense to change the Java[tm] mapping convention, thus avoiding the conversion from string (at UI level) to Java[tm] int and again to SQL varchar. But this type of decisions vary from project to project, therefore the SoProTech[tm] does not enforce any predefined type-mapping scheme.

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

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