DE
EN
FR
The OS.bee core is composed of meta models, grammars, source code and other artifacts forming the OS.bee software factory. The OS.bee core is open source and stands under the EPL respectively under the licenses of the integrated frameworks or add-ons.
With 30 years of experience in engineering business software and in object oriented development of ERP Software with several 10.000 users we have identified throughout the years reusable abstractions of business typical domains, which can also be used in other software development areas. We know how to streamline and automate application development and due to our decades of experience we are apt to choose the right level of abstraction and to identify the necessary core assets. As a result, our applications are modeled and orchestrated with reusable elements embedded in a universal Business Engineering Environment (BEE®).
In the world of application development there is a huge necessity to reduce complexity of modern business applications, so that they can be easily understood and maintained. Our answer to this challenge was creating models to keep domains simple, and architecture of these models, covering the requirements of complex software applications.
The OS.bee software factory divides into three parts:
The OS.bee core composes the OS.bee software factory also called OS.bee “designtime” by which business models can be specified and implemented via modeling, distributed, operated and improved.
An OSGi based runtime environment, in which OS.bee developed applications are operated.
Multi-layered architecture
Developing business applications such as an ERP means to design a complex system. Therefore a scalable, flexible, extensible and evolvable architecture is required. For OS.bee generated applications we follow the multi-layered architecture (MLA) approach, organizing software components into different layers for presentation, business logic and data management.
Business applications built on a formal semantical model
OS.bee is built on a formal semantical model, which is used to describe meta models of domains persisted in DSL. Each DSL has its own grammar, enforcing its correct syntactical usage, which is described in syntax diagram. Each model or equivalent each DSL is mapped to a distinct component environment, generating source code, configuration files, required databases etc. via an inferrer. And as result a “customized” component based business application running under OSGi is build.
DSL Architecture hiding complexity
DSL are meant to hide complexity of a certain domain. For that reason DSL for business applications are challenging as business is so often complicated and their corresponding DSL tend to be complex and complicated themselves. So how can a DSL for business applications be kept simple but sufficiently sharp to solve given problems?
Our solution to diminish complexity of an application field like an ERP is to subdivide the business domain in sub-domains and to preserve their context and coherence. Even better, OS.bee uses the DSL concept also to describe inter sub-domain and therefore inner-domain dependencies.
