Keywords:
Astract: Sophisticated business rule engines provide a way to enable users with a non-software-engineering background to take action during the runtime of e.g. an enterprise information system: rules for customers can be defined, based on the turnover realized through them. The REA accounting model defines a concept for the modeling and excecution of business models, yet it does not go into detail how to implement and integrate business rules. We propose the integration of a proven business rule engine in contrast to the definition of a REA specific rule language or model by defining a set of anchor points into which specific business rules can be hooked that are fired when these anchor points are reached.

Keywords:

Keywords:
Astract: The REA business model language is an established vehicle (i) to model businesses in terms of domain specific value chains and their key concepts and (ii) to capture business data in terms of accounting artefacts. REA has evolved into a specification that could drive web shops, enterprise/trading information systems, enterprise resource planning systems, etc. Such systems require support for sophisticated business rules in order to decouple business logic from application logic. In this work we present a framework for structural integration of business rules into REA business models.

Keywords:
Astract: E-marketplaces on the World Wide Web are information and transaction silos, which in the general case don't allow transactions across their boundaries. The consequence is that the Web, often termed the global marketplace, is fragmented along the dimensions of geography, content domain, supply or demand, user base, and many more. This fragmentation makes it inefficient to buy and sell commodities on the Web. We propose a framework that serves as a foundation for a distributed, de-centralized e-marketplace on top of the Web, making boundaries between existing systems disappear from the user's perspective. The framework standardizes the creation and description of objects that represent supply and demand. In addition to this, it allows for independent matching services to connect objects suitable for a transaction and it defines protocols for the message exchange between such objects.

Keywords:
Astract: The original REA accounting model (McCarthy, 1982) has been extended in previous years into a business modeling language. Apart from its conceptual model, academic effort has been put into the definition of a formal description language, based on standards such as UML or OWL. The specification of a generic data model from a software engineering point of view for domain independent use of REA for business model specification and execution has been touched only briefly in the past. Thus, we present a data model concept for runtime-configurable REA business model definition and execution.

Keywords:
Astract: Electronic Invoicing has attracted a lot of attention by being a cornerstone of the Digital Agenda for Europe, Europe´s 2020 Strategy. This agenda mandates a "think small first" principle in order to enable e-invoicing for companies of any size. The electronic invoice should be exchanged between the ERP systems of business partners. Traditional approaches based on electronic data interchange failed to attract SMEs. Due to the high costs, they only use e-invoicing if forced by their larger business partners. In this paper, we present an alternative approach that is based on native ERP integration of most common e-invoice scenarios. This approach was successfully implemented in a research project resulting in a university spin-off.

Keywords: model-driven engineering, executable model, executable modeling language, metamodeling, software language engineering, behavioral semantics, fUML
Astract: Model-driven engineering (MDE) is a software development paradigm aiming to cope with the growing complexity of software systems by raising the level of abstraction. In this paradigm, a system is defined by means of models using modeling languages that enable developers to abstract away from implementation and platform details. From the models, complete implementations may be (semi-)automatically generated by utilizing model transformation techniques. As MDE puts models into the center of software development, adequate methods for creating, analyzing, and utilizing models are crucial. Due to the large body of used modeling languages, means for efficiently developing adequate tool support for modeling languages are needed. To address this need, the automation techniques provided by MDE may also be applied to automate the development of such tool support. This is current practice for developing syntax-based tools. However, the automated development of semantics-based tools has not reached the same level of maturity yet. The goal of this thesis is to fill this gap and provide a solution for automating the development of semantics-based tools for executable modeling languages. Therefore, a language and methodology for developing behavioral semantics specifications based on the standardized language fUML are proposed. To provide the basis for developing semantics-based tools, the execution environment of fUML was extended with means for execution control, runtime observation, and runtime analysis. Based on these extensions, a generic model execution environment for modeling languages whose behavioral semantics is defined with fUML was developed. This environment provides the foundation for developing semantics-based tools for executable modeling languages, which has been shown by the implementation of a semantic model differencing tool and other semantics-based tools.

Keywords: Cloud computing, Model-Driven-Engineering, UML
Astract: Cloud computing had and still has a major impact on how applications are made accessible for the users. Due to the advantages cloud computing has, there is a demand to migrate applications to the cloud. Unfortunately there does not exist general guidelines how to define the required application execution environments and deployment requirements so that they can be interpreted by any arbitrary cloud provider. In the last years, cloud providers came up with approaches to be able to describe cloud resources in form of an interpretable template. Just recently, in November 2013, OASIS published the open standard TOSCA [44], which aims to unite existing proprietary approaches and standardise them. Approaches following a declarative way of describing orchestrated cloud resources are quite recent and are extended frequently, as it is a promising possibility of illustrating complex dependencies and limitations of computing resources in a way that can be read by human beings as well. This thesis firstly discusses model driven engineering and cloud computing separately and afterwards, how they can be combined. The main aim is to create a model that contains enough information about dependencies, limitations and application specific requirements, which can support the migration of the application to the cloud. Furthermore, the master-s thesis proposes a process, which is subdivided into two parts: Deployment and Provisioning. The first step is about creating UML models and refining them with UML extensions (classifiers, profiles and stereotypes), which consists out of cloud computing specific attributes. The second step converts the model into a template, by means of applying model to text transformations, in order to be interpretable and executable by cloud providers. Existing solutions only address partial aspects of the whole problem, focusing on other objectives. One of the main goal of this thesis is the creation of a unified and model-based solution, whose processes and tools support the application modeler and make a (semi-)automatic execution of the deployment and provisioning of an application in the cloud possible.

Keywords:
Astract: In model-driven software development, software models are the main artifacts used not only for supporting brainstorming, analysis, and design purposes, but also for generating executable code. Such software models are usually not created by one single developer, but within a team. To coordinate team work, versioning systems have proven to be indispensable for managing modifications performed by different modelers at the same time. When concurrently performed modifications are contradicting each other, the standard versioning paradigm requires the person who detected the conflict to resolve it immediately in order to keep the evolved artifacts in a consistent state. Whereas this approach works well in later phases of the software development process, in early phases, when the development team had not established a consolidated view on the system under development yet, the conflicts might provide valuable information on the various intentions of the modelers. This information might be lost if removed in an undocumented manner by a single modeler. We propose an alternative versioning paradigm for models, where conflicts are temporarily tolerated and discuss its technical realization for current modeling languages such as the UML. The resolution of conflicts is then not performed by one single modeler but within a team so that a consolidated version of the model is obtained.

Keywords:
Astract: As every software artifact, also software models are subject to continuous evolution. The operations applied between two successive versions of a model are crucial for understanding its evolution. Generic approaches for detecting operations a posteriori identify atomic operations, but neglect composite operations, such as refactorings, which leads to cluttered difference reports. To tackle this limitation, we present an orthogonal extension of existing atomic operation detection approaches for detecting also composite operations. Our approach searches for occurrences of composite operations within a set of detected atomic operations in a post-processing manner. One major benefit is the reuse of specifications available for executing composite operations also for detecting applications of them. We evaluate the accuracy of the approach in a real-world case study and investigate the scalability of our implementation in an experiment.