somusar/SoProTech: A Sample Project

We Generate Your Software.

Products

Services

Company

The Somusar/SoProTech[tm] Booklet Series Volume II "somusar/SoProTech: A Sample Project" Printer friendly

Contents
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/   mold2-.sql/   1/   any_type.hdr

Java[tm] class member names Should be in mixed upper case and lower case letters with no underscores EmplId LOGIC/   mold2-.java/   4/   any_type.hdr

Java[tm] class source file names Should match the Java[tm] class name, with the first letter in upper case Customer LOGIC/   mold2-.java/   trigger

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 DB/   mold1-.coll/   1

UI collections Each entity requiring an HTML data editing/viewing form should define collections UI.full_view and UI.compact_view full_view: company_name address contact phone_call cell_call UI/   mold1-.coll/   1

Database table keys Each database table should have exactly one primary key constraint   pk_employee   primary key    (emplid) DB/   mold2-.sql/   2

HTML form buttons Each full_view HTML form should have the same set of buttons at the bottom of its entity workspace New Copy Save Delete Search Prev. Next Navigate toolkit/   html/   formbuttons

C++ enumeration values Should be identified by upper case symbolic names and their values should always be explicitly expressed VICE_PRESIDENT =   1 LOGIC/   mold3-.h/   3/   enum

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   varchar(40) toolkit/   sql/   column

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   VICE_PRESIDENT   = 1; ... private int   position; LOGIC/   mold2-.java/   3/   enum
LOGIC/   mold2-.java/   4/   enum

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=   "Vice-president"> Vice-president </option> UI/   mold2-.fview/   1/   enum

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]