A structured approach to developing web applications includes a model-driven tool such as SAP's Visual Composer, which allows a developer to compose applications in a flexible way by using patterns. A pattern graphically depicts functional components as drag-and-drop services, and defines a data flow between the components. User interface patterns can be defined at various levels, and can be nested within each other, thus creating hierarchies of patterns. At the top level of the hierarchy, a pattern can act as a model or “floor plan” for a user interface that is designed to help end-users complete a specific business process. The floor plan defines the user interface of the application by specifying an overall screen layout for the user interface and managing and orchestrating any nested patterns.
In current implementations of pattern-based configurations, there is a strict separation of components that are related to data handling (i.e., services) and other component that are focused on user interactions (i.e., scenarios). If a service element is changed, e.g. a new attribute is created, this change is not propagated through the whole model because only a service class is associated with the backend meta data, e.g. business object node meta data.
There is currently no generic code distribution mechanism in pattern-based application development environments. Kit developers thus require code distribution, logic for every kit. This increased need for resources to write a kit makes implementation of distribution by different people too different and not always fitting together. Further, the conventional mechanisms for distribution of code created dependency between different kits. Implementing the logic in the pattern components is also not a viable solution, because such implementation violates the modularization of every component. The distribution logic has to be implemented in a more generic layer.
The pattern idea means that it is possible to create new composition unit and plug in these new components without any changes to already existing components. The consequence is that existing components are not allowed to be edited for a new component. An abstraction layer is needed to define that one component wants to host some other components, but does not make any assumptions about the used components, because the used component is added in a dynamic way.