Appligenics Limited
Appligenics Limited Appligenics Limited Home Page Agile+ - Discover the power of Agile Development Products - Appligenics Product Suite & White Papers Services - Professional Services, Mentoring, Training & Support Partners - Appligenics' Valued Partners Customers - Business Solutions for All Business Types About Us - Contact Details, Corporate History & Investor Relations
Appligenics Limited         Customer Log In   
graphic spacer spacer graphic
 

Technical White Paper (page 2)

Previous Page   1   [2]   3   4   5   6   7   8   9   10   Next Page

Chapter 2 - The Designer

The Designer consists of blocks of information that ultimately become the complete specification of an application. The brochure on the Designer explains the process in more detail and we recommend that you read that first. For the purposes of this document the blocks that relate to generated code through the Generator are as follows:

Boxes showing the text: entities, elements, rules, programs, events

These blocks group many types of data and are illustrative only to show how they relate to the Generator in the next chapter.

Positioning

It is important at this early stage to position the Designer within its many possible implementations. The output operates in an Application Server environment but is not exclusive to the Internet. Application Servers are now low cost modules (free in some cases) and will be released as part of the operating system in future releases. Therefore, the generated application can work comfortably on a laptop PC or an enterprise client/server, as well as in an Internet environment.

The next iterations of the Generator will provide output for PDAs and 3G devices from the same design - the only difference for the Business Analyst will be in presentation using different frame sets for the smaller screen. So once again, one design for many implementations.

Methodologies

Many companies use methodologies for early Requirements and outline Specifications, such as UML, BPMI, SSADM, etc. We recommend that you continue to use the key charts for Entity Relationship Diagrams (Class Diagrams), Process Flow, and Use-Case and relate them to the physical design within the Designer. This ensures continuity during a time of change and consistent links between documents. After your first few projects, we recommend that you review the early stage processes in order to remove any redundant tasks and steps that do not complement the Designer.

Boxes showing the text: entities, elements, rules, programs, events. Entities box is shaded.

Entities

The Entity Relationship Diagram (or Class Diagram) is a critical picture of the scope of the project. Because of the Designer's inherent concepts, the relative impact on time and cost can be deduced from the diagram. If more entities are added, they have a direct impact on the overall project, whereas if more query or maintenance programs are added they will have minimum impact on the overall project.

Entity Relationship Digram

Relationships

The relationships between entities are defined once only. While a diagram shows the path from the higher to a lower entity (for instance, a Client has Officers), for Relationships we define the access path from the lower entity (the Client element on Officers, for example). The elements in the path are uniquely named so we only have to define the path once.

The effect of this is that we have catered for relationship integrity, such as "check above" and "delete below" which are automatically generated.

Boxes showing the text: entities, elements, rules, programs, events. Elements box is shaded.

Previous Page   1   [2]   3   4   5   6   7   8   9   10   Next Page



   
Home   |   Agile+   |   Products   |   Services   |   Partners   |   Customers   |   About Us   |   Privacy Policy   |   Customer Log In   |   Site Map