If you want to build applications on top of the FPM framework, you should consider about a clear structure of your application and the data, which will be processed in it. As a first fundamental principle, you should define clear layers in your application:
- UI-Layer: Visualized by FPM, configured by you.
- UIBB-Layer: Feeder, Freestyle-UIBBs and some controlling classes developed by you.
- Application-Layer: Implementing the application behaviour.
- Backend-Layer: Busines Logic developed by you or provided by somebody else.
When you look at the FPM architecture map , you could see such a structure. In the following image, I show the layers and their elements corresponding to FPM and your application.
As I call the fourth layer “Backend-Layer”, it is only a synonym. You can also call it “Business-Layer” or “Application-Model-Layer”.
In this blog, I will show you, how to separate a new FPM application into this layers, what are the different tasks of each layer. I will not cover the FPM-Layer and freestyle-UIBBs.
Imagine the following situation: Your customer wants you to build a UI-based application on top of an existing backend system. ( In my examples I will often use the travel-agency demo application of SAP. )
In the first step, you should look at the use cases of your customer and what the UI how the looks like. In most cases, your Customer have an idea about how the UI should looks like.
Than you take your pencil an draw some demo screens on a paper – or if you can better handle it with PowerPoint or something else; on a file -, I will just show simple samples, so that the structure and my approach will be easier to understand.
Here is the example…
We have a Identification Region, a Form-Region and a Table in which addionational data will be shown.
Structure your UI-Layout and your FPM-application
Now you got an early vision about your application. Now, try to separate your screen with the help of all known GUIBBs, IDRs and Tabbed-Regions. As I mentioned, try to use GUIBBs as often as you can. The usage of Freestyle UIBB should be strongly avoided. By time, I will handle this topic in a separate blog.
Look at the following picture: Here I have marked all UIBB with a green area. The rest will be done bei FPM. (Naturally, this is a very basic example, and the real life is much more complicated ).
Structure your underlying application
OK, after you have identify the several UIBBs, you can define a clear object model, representing the whole UIBB-Layer:
Try to name your classes like the used feeder classes and there concrete job. (And not as I did it here “ListFeeder”, “FormFeeder”, “HeaderIDR” 😉 ).
If you regard to the UML-structure, you will discover some more classes than only the FPM-related objects. That’s right, because I know by our requirements, which data has to be handled and so, I need at least a data-abstraction class, some instance for controlling the application and event handling and at least a subsystem, which encapsulates underlying business and persistence. The think about data-abstraction classes and controlling-instances will be shown in a later blog.
When you structure your application in a similar way, you will meet some (important) architectural principles:
- Loose Coupling: Every class of your application is so separated, that you can easily enhance and change it.
- Structural modularity: Due to this splitting of your software, you will get manageable components and not one big “monster”.
- Separation of concerns: Every part of your application handle only the thing for what it has been built.
- Open extensibility: You will be open more further requirements and do not have to change the whole application
There are even more architectural principles, which I can enumerate here, but one important should also be named:
- Fulfillment of standards: Due to the FPM-framework, you will get a standard environment, in which you have to perform your contract with FPM.
In this blog, I do not touch the topic “UI-configuration”. Instead, you have seen, how you can separate and structure your application, to get a stable fundament for your development.
Later, I will show you, what posibilities are behind this approach. Especially, if you think about enhanceability, quality or maintenance.
If you can manage it, you will have the option, to split your team and your tasks in very good packages and gain a lot of speed for implementing new FPM-based UIs.