Keywords:
Astract: Huge classes with more than 800 students pose a major challenge to lecturers as well as to students, especially when a practical part is included. In order to successfully master lectures of this size, novel kinds of teaching media provide a multitude of enhanced opportunities. In this paper, we present our experiences with the application of new media in our undergraduate course Introduction to Object-Oriented Modeling (OOM). In this course, we teach approximately 800-1000 students per year the principles and techniques of UML 2.0. New media, i.e., technologies other than the traditional blackboard presentation like a document camera, web-based self assessments, or lecture recordings, are applied to support both, students and lecturers when learning and teaching, respectively. We empirically underline the acceptance of our concept with the feedback of our students concerning the newly used technologies gained through an extensive survey.

Keywords:

Keywords:
Astract: In the discipline of accounting, the resource-event-agent (REA) ontology is a well accepted conceptual accounting framework to analyze the economic phenomena within and across enterprises. Accordingly, it seems to be appropriate to use REA in the requirements elicitation to develop an information architecture of accounting and enterprise information systems. However, REA has received comparatively less attention in the field of business informatics and computer science. Some of the reasons may be that the REA ontology despite of its well grounded core concepts is (1) sometimes vague in the definition of the relationships between these core concepts, (2) misses a precise language to describe the models, and (3) does not come with an easy to understand graphical notation. Accordingly, we have started developing a domain specific modeling language specifically dedicated to REA models and corresponding tool support to overcome these limitations. In this paper we present our REA DSL which supports the basic set of REA concepts.

Keywords:
Astract: The Resource-Event-Agent (REA) ontology has its roots in the accounting discipline and was originally developed as a reference framework to conceptualize economic phenomena in an enterprise. In its proposal in 1982, McCarthy already had the vision to facilitate the design of data structures of accounting information systems by means of REA. Since this time the REA model has been further extended and evolved into a domain ontology. All REA concepts are based on well established concepts of the literature in economic theory - which is certainly one of the strengths of REA. However, REA has no dedicated representation format and, consequently, no graphical syntax. Thus, users may struggle when describing the REA models leading to the impression that REA is a rather heavy-weight approach. A dedicated graphical syntax - such as it exists for e3-value - may help in overcoming this problem and may lead to a much more significant adoption of REA. Accordingly, we have started the endeavor of developing a domain specific modeling language for REA.

Keywords:

Keywords:
Astract: Standardized business documents are a prerequisite for successful information exchange in electronic business transactions. The United Nations Centre for Trade Facilitation and eBusiness (UN/CEFACT) provides a conceptual modeling approach, called Core Components, used by Business Partners (BPs) for defining business document models (BDMs). These BDMs are essential for defining service interfaces in service-oriented systems. However, in such a highly dynamic environment with ever-changing market demands, BPs are confronted with the need to revise their BDMs resulting in new versions of BDMs. Furthermore, BPs may dictate the use of new versions of BDMs. However, small- and medium-sized enterprises (SMEs) may not always adopt new BDM versions due to the cost and effort involved, inhibiting electronic information exchange. In this paper, we present a framework for dealing with interoperability issues in service-oriented systems through providing BPs with Business Document Interoperability as a Service. Having such a framework at hand provides SMEs with a low-cost and light-weight approach for dealing with evolving market requirements and hence evolving business documents. Furthermore, we present a prototypical implementation as well as an evaluation of the framework proposed.

Keywords:
Astract: Electronic Data Interchange (EDI) is based on the standardization of business document types. Usually, a standard business document type is defined in an all-embracing manner covering all elements needed in any business context, such as geopolitical context, industry context, and others. Before exchanging business documents in a particular business context, business partners have to agree on an implementation guide resulting in a subset of the standard document type. Different subsets of a standard document type may also be considered as variants of the standard document type. Since no agreed methodology for building variants of standard documents types exists, the domain of EDI may learn from Software Engineering. In fact, we are facing the need for managing variants which is typically addressed in Software Configuration Management. In this position paper, we propose utilizing concepts from Product Line Engineering (PLE) for managing variability in business document models. Therefore, we present the challenges encountered in managing variability in business documents. Furthermore, we provide a profound discussion why concepts from PLE are promising for managing business document variants.

Keywords:
Astract: The United Nations Centre for Trace Facilitation and eBusiness (UN/CEFACT) provides a conceptual approach named Core Components for defining business document types based on generic, reusable building blocks. For facilitating interoperability in Electronic Data Interchange, these reusable building blocks are defined in an all-embracing manner. Accordingly, business partners customize the standard business document types for fitting their needs and requirements, resulting in different business document type variants. However, the approach is missing sufficient mechanisms for managing business document model variants. First, customizing standardized business document types is purely based on a textual specification. Second, the variability present within the Core Component approach lacks an explicit representation. In this paper, we aim at making variability explicit as well as adding a formal aspect to the business document type customization process by employing variability concepts from Product Line Engineering. Furthermore, based on having explicit variability models, business partners are provided with an approach for customizing business document types through configuring variability models.

Keywords:
Astract: Despite standardization efforts the seamless exchange of business documents often poses a problem, due to a large number of different formats. Also, there may be several standards initiatives in the same business domain, all equally important. Consequently, transformation between various document formats on the instance layer becomes necessary. To ease the implementation of transformers we propose an XSLT-based generation framework that allows for bidirectional transformations. Furthermore, we rely on Core Components as an intermediary format. As a proof of concept we developed a prototype based on the open source tool named VIENNA Add-In.

Keywords:
Astract: The United Nations Centre for Trade Facilitation and Electronic Commerce provides a conceptual approach named Core Components for defining business document models based on reusable building blocks. For the application in concrete business scenarios, these building blocks need customizing, resulting in different variants of business document models. In previous work we have proven the application of concepts from Model-Driven Product Line Engineering to manage the resulting business document model variants. However, due to the highly dynamic environment of electronic commerce with ever-changing market requirements, business document models evolve over time. This adds another dimension of variability to the problem domain leading to complex evolution scenarios. In this paper, we define evolution patterns for capturing the different types of evolution present in the context of business document model variants. Having such patterns at hand, makes the different types of evolution in business document models more tangible.