Towards a Shared European Logistics Intelligent ... · • ST5.3.4 Visual Analytics, UI and Dashboard Generation: Design the user related presentation items. Integrate available open

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Grant Agreement No 690588.

Towards a Shared European Logistics Intelligent Information Space

D5.5 Tools and services for accelerated

application development, integration and

deployment (version 1)

Ref. Ares(2017)4260715 - 31/08/2017

D5.5. Tools and services for accelerated application development, integration and deployment (version 1)

© SELIS, 2017 Page | 2

Document Summary Information

Grant Agreement No

690558 Acronym SELIS

Full Title Towards a Shared European Logistics Intelligent Information Space

Start Date 01/09/2016 Duration 36 months

Project URL www.selisproject.eu

Deliverable D5.5 Tools and services for accelerated application development, integration and deployment (version 1)

Work Package WP5 SELIS Intelligent Logistics Applications Suite

Contractual due date

31/08/2017 Actual submission date

31/08/2017

Nature Other Dissemination Level

Lead Beneficiary CLMS UK Ltd.

Responsible Author

Christina Stratigaki

Contributions from

Revision history (including peer reviewing & quality control)

Version Issue Date Stage Changes Contributor(s)

0.1 13/01/2017 Structure the outline

Christina Stratigaki-CLMS

0.5 31/05/2017 Draft Christina Stratigaki-CLMS

0.6 15.06.2017 Draft Add Conclusions Christina Stratigaki-CLMS

0.7 12/07/2017 Draft Adding LL example Christina Stratigaki-CLMS

0.8 28/07/2017 Ready for Internal Review


0.9 07/08/2017 High level review Review the consistency with DoW

Ben Hodgson – BMT Pat O’ Sullivan – ILS

0.95 21/08/2017 Peer review Ioannis Konstantinou - ICCS

0.96 22/08/2017 Peer review Beatriz Royo - ZLC

1.0 28/08/2017 Final version Integrated reviewers’ comments




Executive Summary The SELIS Project aims to deliver a cloud-based “platform for pan-European logistics applications” which will work as “a network of logistic communities' specific shared intelligent information spaces termed SELIS Community Nodes (SCNs)”.

Within every SCN and for every Living Lab applications will be created to facilitate the monitoring of sharing information. This deliverable and Task 5.3 aim to develop a toolset allowing applications to be developed collaboratively and deployed on the cloud. The tools will be used to encode design patterns of SELIS to applications transforming designs to software deployed to web and cloud. The SELIS toolset will also enhance reuse of existing components and integration of existing systems in SCNs.

D5.5 focuses on delivering a (a)Domain Models Constructor and a (b)Data Mapper and Transformer with respect to what is described in ST5.3.1 and ST5.3.2 of the DoW.

Disclaimer

The content of the publication herein is the sole responsibility of the publishers and it does not necessarily represent the views expressed by the European Commission or its services.

While the information contained in the documents is believed to be accurate, the authors(s) or any other participant in the SELIS consortium make no warranty of any kind with regard to this material including, but not limited to the implied warranties of merchantability and fitness for a particular purpose.

Neither the SELIS Consortium nor any of its members, their officers, employees or agents shall be responsible or liable in negligence or otherwise howsoever in respect of any inaccuracy or omission herein.

Without derogating from the generality of the foregoing neither the SELIS Consortium nor any of its members, their officers, employees or agents shall be liable for any direct or indirect or consequential loss or damage caused by or arising from any information advice or inaccuracy or omission herein.

Copyright message

© SELIS Consortium, 2016-2019. This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both. Reproduction is authorised provided the source is acknowledged.



Table of Contents

1 Introduction .................................................................................................................................... 7

1.1 Addressing the SELIS Description of Action ............................................................................. 7

1.1.1 Task Description ............................................................................................................... 7

1.1.2 Deliverable Description .................................................................................................... 7

1.2 Document outline .................................................................................................................... 9

2 Design Considerations .................................................................................................................. 10

2.1 Foundations Setup ................................................................................................................. 10

2.1.1 Application Platform as a Service ................................................................................... 10

2.1.2 Model-driven Engineering .............................................................................................. 11

2.1.3 Architecture-Centric Engineering ................................................................................... 13

2.2 SELIS requirements and specifications .................................................................................. 13

2.2.1 Reference information exchange models ...................................................................... 13

2.2.2 Green Logistics Strategies and Capabilities .................................................................... 15

3 SELIS Toolset architecture............................................................................................................. 16

3.1 High-level Features ................................................................................................................ 17

3.1.1 Collaborative Environment ............................................................................................ 17

3.1.2 Coding in the cloud ......................................................................................................... 17

3.1.3 Version Control............................................................................................................... 17

3.1.4 Agile Environment .......................................................................................................... 18

3.2 Architecture overview ........................................................................................................... 18

3.3 Key components of the SELIS toolset .................................................................................... 20

4 SELIS Toolset implementation ...................................................................................................... 21

4.1 Domain Modelling ................................................................................................................. 21

4.1.1 Usage of Domain Models Constructor in Living Lab 8 ................................................... 24

4.2 Business Processes & Workflows .......................................................................................... 27

4.3 Data Mapper and Transformer .............................................................................................. 30

4.3.1 Data Transformation Tool .............................................................................................. 30

4.3.2 Data Transformation Inference Engine .......................................................................... 32

4.3.3 Usage of Data Mapper and Transformer in Living Lab 8 ............................................... 35

5 Conclusions ................................................................................................................................... 37

6 References .................................................................................................................................... 38

List of Figures

Figure 1: Layers of abstraction in MDE ................................................................................................ 12

Figure 2 MDE approach in SELIS toolset solution semantics transformation into software artefacts. .............................................................................................................................................................. 16

Figure 3 SELIS Toolset Overview .......................................................................................................... 19

Figure 4 Overall context of SELIS Toolset ............................................................................................. 19

Figure 5 Domain-oriented vs data/transaction-centric approaches.................................................... 21

Figure 6 Domain meta-model .............................................................................................................. 22



Figure 7 The Business object “Consignment” based on ISO/IEC 19845 .............................................. 24

Figure 8 SONAE Order Forecast Business Object ................................................................................. 25

Figure 9 Class Association Properties ................................................................................................... 26

Figure 10 Class Operations ................................................................................................................... 27

Figure 11 Class Usage Search ............................................................................................................... 27

Figure 12 Workflow meta-model ......................................................................................................... 28

Figure 13 Sample Workflow model created in the Toolset ................................................................. 29

Figure 14 Enabling Scheduling within a workflow ............................................................................... 30

Figure 15 Data Transformation meta-model ....................................................................................... 31

Figure 16 Example of Data Transformation ....................................................................................... 32

Figure 17 Data pre-processing for optimized semantic features extraction. ...................................... 33

Figure 18 Semantic similarity measure approach in the decision process of automated mappings. . 34

Figure 19 Mapping of Abbreviations in the decision process. ............................................................. 34

Figure 20 Semantic similarity in the decision process. ...................................................................... 35

Figure 21 Data mapping and data transformation in LL8 .................................................................... 36

List of Tables

Table 1: Deliverable’s adherence to SELIS objectives and Work Plan ................................................... 8

Glossary of terms and abbreviations used

Abbreviation /

Term

Description

SCN SELIS Community Node

aPaaS Application Platform-as-a-Service

MDE Model-Driven Engineering

DDD Domain Driven Development

BPMN Business Process Modelling Notation

SC Supply Chain

SaaS Software as a Service

API Application Program Interface

JSON JavaScript Object Notation



ACE Architecture-centric Engineering

EGLs EU-wide Green Logistics strategies

WCO World Customs Organization

WSDL Web Services Description Language

REST Representational State Transfer

SaaS Software as a Service

IaaS Infrastructure as a Service



1 Introduction 1.1 Addressing the SELIS Description of Action

1.1.1 Task Description

This task will develop a toolset delivered as a web service allowing "intelligent" applications to be developed collaboratively and deployed on the cloud. The toolset will support the full lifecycle of accelerated application development, integration and deployment. The tools will be used to encode design patterns of SELIS to applications transforming designs to software deployed to web, cloud and mobile devices. The toolset will enhance reuse of existing components (building blocks) and integration of existing systems in SELIS Nodes.

Subtasks:

• ST5.3.1 Domain Modelling: A set of tools to create models for data used in analytics. Match

data sources to analytics to data object representations. Use BPMN workflows to describe

data and information exchanges, support process orchestration and automatic profile

generation for Service Oriented Architectures.

• ST5.3.2 Data Mapping and Transformations: (a) Data Transformation, to map the relevant

attributes from one domain structure to another, and consequently to produce the necessary

code for the specific implementation strategy that will realize the data transformation, (b)

Semi-automatic mapping to assist the mapping process of the data transformation tool,

leading to the formalization of the data transformation inference engine and (c) data pre-

processing and the decision process engine, that enables and builds upon the semantic

features extraction, assisted by specialized machine learning algorithms.

• ST5.3.3 API Generation: API management / Services and Semantics for Integration,

information exchanges, and process collaboration. API management tools will facilitate the

use of different approaches. RESTful approaches, especially JSON-based ones, like, e.g. Hydra.

APIs are semi-automatically generated by the Model Definitions.

• ST5.3.4 Visual Analytics, UI and Dashboard Generation: Design the user related presentation

items. Integrate available open source analytics graphics libraries for Analytics related graphs

for User Dashboards. Provide connectors to data and information as these are captured by

the Knowledge Graphs and the Big Data information repositories. Provide support for user

input and interaction to allow dynamic User Displays, and dashboard interactions. Use Open

Source libraries to create and support graphics (e.g. Python or R libraries).

• ST5.3.5 Workflow and SC Services Composition Engine: The workflow composition engine lets

the creation, test and deployment of business processes and workflows across organizations

in an efficient manner. Components and services developed within SELIS are easily pluggable

and used to support extended functionalities. The engine provides simple ways to integrate

and compose business processes provided by other systems in a SOA (service oriented

architecture) manner, e.g. using WSDL (Web Services Description Language) to enable

services provision and consumption.

1.1.2 Deliverable Description

A comprehensive set of tools for accelerated User Oriented developments, to assist Decision Support with dynamic Dashboards using a model driven architecture. Support transformations and mappings



of Supply Chain information, and the semi-automatic creation of APIs for integration purposes. Release 1 involves (a) Domain Models Constructor (b) Data Mapper and Transformer. Use Cases taken from Living Labs.

Table 1: Deliverable’s adherence to SELIS objectives and Work Plan

SELIS GA requirements

Section(s) of present deliverable addressing SELIS GA

Description

T5.3 Support Tools and Services for accelerated application development, integration and deployment

2 Design Considerations

3 SELIS Toolset architecture

Those two sections are setting the foundations of the overall design of the SELIS toolset by emphasizing on the features of accelerated development and cloud deployment as well as the enhancement of reusing existing components as described explicitly in the DoW.

ST5.3.1 Domain Modelling

4.1 Domain Modelling

4.2 Business Processes & Workflows

Sections 4.1 and 4.2 are setting the theoretical background for the domain modelling as a concept. Moreover, they explain the modelling and implementation of the Domain Constructor.

ST5.3.2 Data Mapping and Transformations

4.3 Data Mapper and Transformer

Section 4.3 sets the context of the Data Transformer tool by describing its design and implementation

1.1.2.1 Summary/ Any introductory information

This deliverable (D5.5) constitutes the version 1 of SELIS toolset. This initial part presents and analyses the SELIS solution development tools that are created to support the development of applications and dashboards, to be used by the Living Labs of the project. Their feedback, together with further input from other WPs of the projects, will be used for the further tuning and improvement of the toolset, which will be described in the final deliverable D5.6, due in Month 35. More specifically, this deliverable focuses on describing the Domain Models Constructor (with respect to ST 5.3.1) and the Data Mapper and Transformer (with respect to ST 5.3.2).

The SELIS toolset will be aligned with the SELIS architecture (developed in T4.1) and it will be used for the development of supply chain application services and data adapters. The SELIS toolset will adopt a Model-Driven Engineering (MDE) approach that will enable the adoption of domain-specific design semantics towards developing the target applications. Moreover, the toolset will expedite the sharing of information and the connectivity of the different stakeholders to the SELIS Community Node (SCN) with the provision of API Management and Data transformation modules. It will facilitate the fast adoption to the SCN with minimum effort and cost.

The SELIS toolset will be formulated to address not only the development of new applications but also the integration of Living Labs’ existing applications in the SELIS Community Node with a unique



implementation strategy. The SELIS toolset will address integration with a holistic approach which will support data transformation for heterogeneous systems and data workflows to get data from various back office systems.

1.2 Document outline

D5.5 structures as follows:

• Section 2 expresses the design considerations towards the overall design of the SELIS toolset while setting the foundations and the SELIS requirements according to DoW specifications.

• Section 3 introduces the architecture of the Toolset and its basic high-level characteristics.

• Section 4 focuses on presenting the implementation of the Domain Models Constructor tool and the Data Mapper and Transformer tool.

• In Conclusions the findings are summarized, based on the initial state of the Toolset.


© SELIS, 2017 Page | 10

2 Design Considerations 2.1 Foundations Setup

2.1.1 Application Platform as a Service

Application platform as a service (aPaaS), or simply platform as a service (PaaS), is a cloud computing service model, along with software as a service (SaaS) and infrastructure as a service (IaaS). It provides end users with the hardware, operating systems, storage or network capacity they need over the cloud to be able to run existing applications or develop new ones.

PaaS provides hosted software applications to customers with low cost of entry or even for free. It simplifies the technical aspects of creating and deploying applications because it's easier to maintain, it's scalable and it's tolerant to faults, enabling users to focus on another thing. PaaS provides many advantages for end users. For example, the operating system can be enhanced and upgraded frequently and all at once, development teams that are geographically separated can work together on software development projects through the cloud, and services can be accessed through various media and from anywhere in the world.

The right aPaaS brings abstraction and automation to the complete application lifecycle, providing a faster way to build apps. These features include:

• Visual, model-driven development for building apps in fast, iterative cycles

• One-click deployment to the public cloud, private cloud or on premise

• Reusable app components for composing the necessary building blocks versus reinventing the wheel each project

• Social collaboration tools and feedback loops that help teams get requirements right the first time and delight users

Application Platform-as-a-Service (aPaaS) tools have rapidly gained momentum in recent years and it’s no surprise why. Businesses that are facing mounting pressure to deliver proprietary apps and services in response to the “consumerization of IT movement” have found themselves needing to transform around digital technologies. Technologies such as aPaaS provide a solid foundation for the development and deployment elements of apps.

As PaaS tools continue to grow in popularity, aPaaS capabilities have helped launch renewed growth. A Gartner study found that the application infrastructure and middleware market experienced revenue increases of 7.8 percent in 2015 when accounting through constant currency terms.

Extending on the benefits of high productivity aPaaS tools, low-code platforms accelerate business transformation by enabling the rapid delivery of business applications with a minimum amount of hand-coding and minimal upfront investment in setup, training and deployment.

The aPaaS service model follows a micro-service architecture to accelerate the development and deployment of applications. Micro-services architecture enables individual service based applications to be developed and deployed on the platform independently and dynamically. In contrast to traditional monolithic architectures, an application is comprised of many small/independent services that interact by using an external published protocol (e.g. REST/messaging service) rather than limited a number of tiered monolithic units. Each service is focused on an individual targeted business capability, and thus its scope is minimized. For functionality out of scope, the micro-service utilizes another micro-service via the published protocol. Each micro-service does not depend on other


© SELIS, 2017 Page | 11

micro-services: it can be deployed, scaled, and managed independently with no effect on other micro-services. The features outline above, ensure that as new features and services are added to an application, the complexity of the codebase is not increased (as with monolithic architecture), and thus development and deployment process remains agile and flexible.

According to Gartner1 application Platform as a Service (aPaaS) “is a cloud service that offers development and deployment environments for application services.” In its recently published “Magic Quadrant for Enterprise Application Platform as a Service”2 (aPaaS), Gartner divides the aPaaS field into two distinct groups: high control aPaaS and high productivity aPaaS.

2.1.1.1 High Control aPaaS

According to Gartner’s analysis3, a high-control aPaaS is based on a lower-level programming language, such as Java, Ruby, .NET, etc, and allows application developers to design and code more advanced applications that what high-productivity aPaaS generally allows. Of course, the high-control approach also heaps greater responsibilities on the programmer when creating cloud applications, just as hand coding on-premises applications would. Developing and deploying finished cloud applications utilizing the HC approach, of course, takes longer than it would with the high-productivity approach.

2.1.1.2 High Productivity aPaaS

In contrast to high-control aPaaS, high-productivity aPaaS (low-code aPaaS) utilizes a model-driven, declarative approach to application design and development. One of the bigger differentiators among HP aPaaS vendors is their approach to model interpretation. Some vendors use the old-school code-generation approach. Others provide true, model-driven platforms that produce metadata that is interpreted at runtime. Virtually all high-productivity aPaaS vendors allow extensions to their respective platforms to be written on one or more lower level languages.

2.1.2 Model-driven Engineering

Model-Driven Engineering (MDE) is a software development approach which suggests that the functional requirements of a software solution are captured in high-level, abstract models within an appropriate toolset, and then the source code is generated automatically, based on a specified configuration. It includes a set of well-defined practices based on tools that use at the same time metamodeling and model transformations, to achieve some automated goals in the production, maintenance or operation of software intensive systems, aiming at abstract representations of the knowledge and activities that govern an application domain.

During the lifecycle of the supply chains, many actors and heterogeneous systems built on (potentially) various technologies and platforms interact with each other, which are. This fact makes it a challenge to integrate and consolidate data and processes, to improve information visibility and security through appropriate management. The interoperability of the IT systems across different partners is technically difficult, even if the underlying domain model for describing the SC is semantically the same. Thus, the MDE approach elevates the level of abstraction by using models, so that the developers can focus on the common domain model and on business side of the systems and not on the particulars of technologies and platforms. It also enables fast and convenient integration

1 Choosing an aPaaS: High Productivity, High Control or Both? , Gartner, 22/10/2015 2 Magic Quadrant for Enterprise Application Platform as a Service, Gartner, 2016 3 Choosing an aPaaS: High Productivity, High Control or Both? , Gartner, 22/10/2015

https://www.gartner.com/doc/3155125/choosing-apaas-high-productivity-high

https://www.gartner.com/doc/reprints?id=1-2C8JHBP&ct=150325&st=sb

https://www.gartner.com/doc/3155125/choosing-apaas-high-productivity-high


© SELIS, 2017 Page | 12

by addressing the relevant supply chain management challenges, such as high complexity in the programming model, limited control over existing backend applications, large variety of data schemas and standards, and lack of a single standard.

MDE technologies combine the following (Schmidt, 2006):

• Domain-specific modelling languages whose type systems formalize the application

structure, behavior, and requirements within particular domains.

• Transformation engines and generators that analyze certain aspects of models and then

synthesize various types of artefacts, such as source code, simulation inputs, XML

deployment descriptions, or alternative model representations.

These technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively. Models in software engineering help increase the mutual understanding between business and IT domains; they create a common language and thus, shared comprehension.

Following systems thinking, a system is a group of interacting, interrelated or interdependent elements forming a complex whole, while a model is the result of the observation of a system by a given agent, with respect to a metamodel, having a given objective in mind. A model is also a graph composed of elements (nodes and edges). Each such element corresponds to a concept in the metamodel.

Figure 1: Layers of abstraction in MDE

A metamodel is a simplified ontology, i.e. a set of concepts and relations between these concepts, encapsulating the semantics among the entities of the domain. Metamodels are the keystone of MDE. Existing and emerging MDE technologies apply lessons learned from earlier efforts at developing higher level platform and language abstractions. For example, instead of general-purpose notations that rarely express application domain concepts and design intent, domain-specific modeling languages can be tailored via metamodeling to precisely match the domain’s semantics and syntax. Having elements that relate directly to a familiar domain not only helps flatten learning curves but

Laye

rs o

f ab

stra

ctio

n Model

[Application-specific]

Metamodel

[Domain-specific]

Metametamodel

[Platform]


© SELIS, 2017 Page | 13

also helps a broader range of subject matter experts, such as system engineers and experienced software architects, ensure that software systems meet user needs. Moreover, MDE tools impose domain-specific constraints and perform model checking that can detect and prevent many errors early in the life cycle.

2.1.3 Architecture-Centric Engineering

The quality and performance of software systems depends not only on their functionality, but also on other properties, like interoperability, robustness and portability. These properties are determined primarily by the software structure – or the software architecture. While many architectures can satisfy functionality, delivery of sufficient quality levels on the other required properties is much more complex and demanding. Achieving quality attributes in a predicable way can only be accomplished by deliberately selecting the appropriate structures early in the development process. Thus, the focus must shift from functionality-oriented development methodologies, to the emergence of architectural structures as the center of a development effort. Architecture-Centric Engineering (ACE) provides the means for designing, evaluating, and implementing a system, based on these properties, so that it will satisfy its business and quality goals. It unites product, technology, process, and people into a cohesive lightweight, scalable development method. Its main goal is to improve product development and quality by using architecture as the mean to gain early confidence in achieving system-related business and mission goals.

The SELIS toolset will be based on the ACE approach in order to be standalone (desktop-based), accessed over the Internet using a web browser, or even web services. Developers will not need to worry about the architecture of the application (i.e. whether it is simply client-server, three-tiered and so on), as the framework automatically will create the correct type of application architecture will be based on choices made at the modelling stage. Similarly, developers will not need to be concerned about the type of clients they need to support, as all standard client environments will be supported. In fact, the architecture design of each delivered application will be defined in the modelling stage.

One of the major challenges in software engineering is to guarantee the completeness and correctness of software systems, especially as they have become increasingly complex and are often used in highly dynamic, distributed and mobile environments. Architecture descriptions provide the conceptual abstraction for modelling complex software systems during development and then during deployment and evolution.

2.2 SELIS requirements and specifications

2.2.1 Reference information exchange models

With respect to the ongoing work that is elaborated in WP1 and more specifically in T1.2, the set of tools that will derive from T5.3 will adopt the Common Information Exchange Model (CIEM) and Collaboration Rules from WP1. Due to the gained experience from related research European projects such a common information model has to be aligned with related standards, provided by WCO4 and GS15 or created in other EU projects such as the eFreight Common Framework and the CORE Supply Chain Security Reference Framework (SCSRF). The main goal of the CIEM is to shape a set of blueprints, data structures and tools towards the development of advanced ICT solutions for

4 http://www.wcoomd.org/en.aspx 5 https://www.gs1.org/standards

http://www.wcoomd.org/en.aspx

https://www.gs1.org/standards


© SELIS, 2017 Page | 14

interoperable and sustainable supply chains complying with available standards and serving demands from trade/logistics entities and enforcement authorities. With respect to standardization, the CIEM will not aim to create new standards. A critical assessment of existing standards will take place to identify areas in which the CIEM may provide input, tools or transformation services to address gaps and limitations of current standards.

The Common Information Exchange model will provide a unique domain model that links processes, data and systems into a unified structure. It will include standard information messages from relevant associations and appropriate transformation mechanisms required for data and information exchange across different systems and business processes. In this way, it will incorporate the set of classes that will be used to construct the domain model of the SELIS toolset.

The Common Information Exchange model will:

• Propose IT solutions to adhere to (inter)national laws and regulations for Supply Chain security. The IT solutions that will be generated from the toolset must adhere to these regulations.

• Provide IT models to analyse:

o authorities and trade/logistics companies involved in supply chain security and their responsibilities (actors’ models)

o interactions between actors and systems (use cases)

o processes for managing threats and vulnerabilities along the supply chain (process models)

o data requirements for messages exchange regarding B2A, B2G and B2B SC security (object models)

o Sequence of transactions that support threat management (Sequence diagrams).

• Provide details on the specifications for collaboration. The Common Information Exchange model will provide access to:

o A set of harmonised and interoperable unified information models that will be used as reference to facilitate the data mapping between heterogeneous systems

A set of choreographies (as BPMNs or other) that will describe how different e-services provided by SELIS can be combined to produce applications for managing risks in real life situations and in different parts of the Supply Chain (i.e. terminals, transport services, etc). The toolset can provide common cases of these processes as default functional processes, which can be reused, fine-tuned, or extended by the users in their own applications.

o A set of e-services offered through SCNs to stakeholders that want to use sensing technologies to detect security event, assess and manage risks, optimise SC chains to mitigate risks, etc.

• Promote International standardisation activities by harmonising frameworks from different initiatives and incorporating them within SELIS (CRMF, SAFE, Common Framework, WCO, ICAO, IMO, ISO or UPU associations’ standards).

The models will be the starting point for the application modelling within the Toolset; thus, they are going to be provided as the out-of-the-box underlying domain model for the solutions that the application developers will implement. This approach ensures that all partners share a common


© SELIS, 2017 Page | 15

(business and technological) language in describing SELIS applications and IT modules, eliminating inconsistencies and ambiguities.

Το facilitate the adoption of the Common Information Exchange model and of the SELIS framework in general, the toolset can provide out-of-the-box transformation modules to and from these formats, so that the stakeholders are encouraged to integrate their current IT systems with the SCNs. Thus, the partners can exploit the features of SELIS even without fully adopting the standardisation of the Common Information Exchange model (e.g. due to the impact on legacy systems).

2.2.2 Green Logistics Strategies and Capabilities

The information exchange models as well as the common information model should be aligned with a set of globally accepted EU-wide Green Logistics strategies (EGLs). As written in the DoW, the Living Labs are linked to these strategies. The EGLs are:

1. Collaboration Risk and Value Sharing 2. Collaborative planning for synchronous logistics 3. Supply Chain Visibility and CAPA dashboard 4. Supply Chain Financing 5. KPIs and Environmental Performance Management 6. Logistics Optimization 7. e-Compliance for Customs & applicable regulations

Through the analysis of each one of them that will derive from WP2, their high-level concepts will be addressed within the Common Information Exchange Model and subsequently within the SELIS toolset. From the beginning of the project, the Living Labs have been related to the various EGLs and in the long term, it is desired to provide through the toolset a SELIS framework with application templates (as referred in ST5.1.3) aligned with the EGLs, the Common Information Exchange model and the core requirements from each Living Lab to facilitate the production of SELIS-focused applications.


© SELIS, 2017 Page | 16

3 SELIS Toolset architecture

As introduced briefly in the previous sub-section 2.1.2, the SELIS solution development toolset adopts a faithful approach to MDE philosophy. All development activities are model-driven and all artefacts are directly generated from meta-models without the need for manual intervention, based on the appropriate technology stack (Figure 2). Moreover, as all models and meta-models in SELIS solutions are intelligible and editable by developers, there is no need for so-called round-trip engineering where modifications to the code must be reflected on the code generating the models.

Figure 2 MDE approach in SELIS toolset solution semantics transformation into software artefacts.

Figure 2 presents a holistic engineering philosophy for designing and building infrastructural components and modern software systems which are platform independent. The development toolset will produce business-driven IT systems based on an agile methodology. The produced applications will easily be maintained and could constantly be aligned with cutting edge technology trends. The web-based SELIS toolset will be used to develop applications using modeling techniques so that the user could work on a higher level of abstraction than traditional development.

Changes in the design and technology will be incorporated fast through an automation engine, using model compiler templates. This will facilitate IT and business teams’ collaboration; applications could be tested immediately after each build. In this way, business users will be able to test their application from day one and throughout the design and development life cycle. This engineering platform will embed modeling, synchronous and asynchronous communication tools, knowledge management and information connectivity within the design and development of software, improving process, understanding and visibility, which will enable reasoning about changes.

The environment will support high-level programming modelling, design validation and code generation, to automate repetitive tasks and produce consistent applications for multiple platforms.


© SELIS, 2017 Page | 17

Manual coding will only be required to satisfy business needs. Technicalities such as framework configuration, architectural decisions, connectivity between modules etc. will be all handled by the underlying Code Generation engine.

The proposed methodology is model driven, meaning that modelling, rather than coding, is the primary development activity. It will realize the key principles of model-driven engineering (MDE), by providing a completely integrated approach for modelling business requirements, workflows, business logic, data and web services, and user interfaces, and automatically generating the complete software application from these models. Its main advantage over other similar frameworks lies in the fact that it will not be tied to a programming language, and/or type of application that it can produce. The developer will have complete access and control over the generated models and code, as these will be easily manipulated using standard XML editors, or be accessed by an SDK tool and be imported to other integrated development environments.

MDE is a set of well-defined practices based on tools that use at the same time meta-modeling and model transformations, to achieve some automated goals in the production, maintenance or operation of software intensive systems. MDE technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively. In general, models in software engineering help increase the mutual understanding between business and IT/IS domains; they create a common language and thus, shared comprehension.

3.1 High-level Features

3.1.1 Collaborative Environment

It is about a collaborative agile environment where tooling, workspaces and environments will be consistent across team members. Development team members will be able to work on the same application through a web browser, without the need of any proprietary tools due to the committed and updated tools that will help them to be synchronized. Such an open and collaborative platform will allow business stakeholders to work in alignment and in closer contact with the development teams where the visual representations will help to minimize translation loss.

3.1.2 Coding in the cloud

Coding in the cloud is a key feature that will make the SELIS toolset flexible and intuitive and will offer to users the possibility to:

• Preserve their workflow

• Have no hardware restrictions

• Access any project on any device

• Build in preview mode

3.1.3 Version Control

Source Control will keep track of the changes allowing the comparison over time and by whom they are done. A notification system will be supported through the collaborative environment where participants will get notifications whenever a change is made in a shared project. The developer will


© SELIS, 2017 Page | 18

also be facilitated to comment on their committed changes to explain to the rest of the team what changes are made and how.

3.1.4 Agile Environment

Agile development is another feature that will be supported by the development toolset. Using agile in SC execution implementations is more difficult than typical implementations; simply due to the number of touch points across the entire life cycle which interact with multiple systems and have internal inter dependencies. In complex supply chain projects both agile and non-agile aspects of the implementation might be combined, e.g., infrastructure design with its upfront investment and procurement period is non-agile. For that matter, any part of the process which has dependencies on external parties outside the project group should be considered non-agile. To a certain extent, solution design analysis should also be done upfront to decide which user stories should be executed together. Given that agile itself states that user stories are to be collected upfront and then detailed and implemented in iterations, this is an extension of the spirit of agile as applicable to supply chain execution package implementations, and in that framework, it will be incorporated in the proposed solution approach.

3.2 Architecture overview

In summary, software development with SELIS solutions development environment will offer:

• Platform independence

• Incremental instantly-adaptive development

• Integrated Architecture Governance and Flexible Application Life-Cycle Management

The vision of SELIS toolset is to make it easier for all supply chain actors to architect, design and implement SELIS-conformant applications within a web services environment, utilizing standard technologies and components. The generated applications will by-design fit the SELIS Architecture and utilize the Connectivity Interfaces (see T3.3) to communicate.

The toolset will enable (see Figure 3):

• Applications to realize SELIS collaborations (i.e. a series of interactions through the SELIS

toolset) that collectively support an overall business process (e.g. planning etc.).

• Applications to communicate utilizing the Connectivity Interfaces and the content-based

publish subscribe system.


© SELIS, 2017 Page | 19

Figure 3 SELIS Toolset Overview

Figure 4 depicts the overall context for the SELIS toolset for developing integration mechanisms

between existing applications (i.e., communication ports) and new supply chain management

applications. The figure depicts a high-level application development process framework defined by

the SELIS toolset. The process encompasses an iterative development process model to provide

continuous feedback and more immediate results.

Figure 4 Overall context of SELIS Toolset


© SELIS, 2017 Page | 20

3.3 Key components of the SELIS toolset

As described in the DoW and in T5.3, the toolset will support the full lifecycle of accelerated application development, integration and deployment. The key components of the toolset are the following:

1. Domain Models Constructor: Domain modeling defines the key concepts as well as the scope of the solution, while it also provides a common vocabulary and is most effective as a communication tool within the development team and across stakeholders.

a. Workflow and SC Services Composition Engine (ST5.3.5) 2. Data Mapper and Transformer: This tool will facilitate the mapping of attributes from one

domain or system to another in a semi-automatic way leading to the formalization of the data transformation inference engine.

3. API constructor: This tool will enable the capability to define, generate and consume APIs within the SELIS toolset to facilitate the integration of existing IT modules, without the need of reengineering the interfaces that the existing applications expose. RESTful approaches, especially JSON-based ones, like, e.g. Hydra, seem to be the future in modern web services description, especially when they can be combined with schema.org properties.

4. UI Constructor: This tool will hide time-consuming details. The design of forms will be facilitated by predefined modules and their functionality will be specified with a few lines of high level code. It will enable automation and scheduling of jobs and workflows visually via a simple yet effective interface.


© SELIS, 2017 Page | 21

4 SELIS Toolset implementation

This section focuses on presenting the first two components of the SELIS toolset which are the Domain Constructor with the business workflow implementation as well as the data transformer tool.

4.1 Domain Modelling

Domain modelling is a way to describe and model entities of the real-world and their interrelationships while collectively describing the problem domain space. Domain modeling defines the key concepts as well as the scope of the solution, while it also provides a common vocabulary and is most effective as a communication tool within the development team and across stakeholders. Key Features of Domain Driven Development:

• Intuitive representation of real-life entities and their relationship

• Combination of Data (Classes/Objects) and Logic (Behavior)

• Abstraction over the level of Databases (hibernate)

• Data Mapping and automated database built

• Models are platform and technology independent

Domain modelling is a good conceptual model for the system design. It is one of the key pattern-based design approaches that manage to derive the solution object model from the problem domain while maintaining both behavior and data. Figure 5 (Fowler, 2002) shows a comparison of effort spent on enhancing software functionality versus complexity when using domain-based approach and data- or transaction-based ones.

Figure 5 Domain-oriented vs data/transaction-centric approaches

The complexity of domain logic comes with large scale solutions, thus data- or transaction-based approaches have increased cost of maintenance. One of the reasons to select a domain driven


© SELIS, 2017 Page | 22

approach for the system design is to foster reasonable usage of patterns that support maintainability and enable concurrent development.

The domain model of an application is captured as a set of Business Objects, i.e. of groups of relevant Object-Oriented Design classes. The modelling notation for capturing the semantics of the domain is a simplified class diagram notation, like the standard Class Diagram of UML.

Domain modeling defines the key concepts as well as the scope of the solution, while it also provides a common vocabulary and is most effective as a communication tool within the development team and across stakeholders. The notions that are defining what a domain model is are depicted in Figure 6 where the key components of a domain model are described in a meta-model. A domain model is composed of classes with their attributes where their interrelationships are called Associations and have pre-defined several properties as shown in the diagram below. Another important notion of the domain model is that of Operations.

Figure 6 Domain meta-model

Application designers can focus on representation of the real-world domain, while the Development Toolset handles the technicalities in the background. Key Features of Domain Driven Development (DDD):

• Intuitive representation of real-life entities and their relationship

• Combination of Data (Classes/Objects) and Logic (Behavior)

• Abstraction over the level of Databases (hibernate)

• Data Mapping and automated database built

• Models are platform and technology independent


© SELIS, 2017 Page | 23

In general, the domain model captures the entities and concepts of the business domain (tangible, e.g. an invoice message, and intangible, e.g. a transport movement) in a notation that is understandable both for technical and business personnel and that can be translated unambiguously into the corresponding software and data assets. Thus, for SELIS, the domain model links processes, data and systems relevant to the Supply Chain into a unified structure, which is based on the semantics identified in the CIEM. Using the instances of the domain model, the application user can utilize the rich semantics of the CIEM to define how the software system under development manages the instances of the domain model.

In order to make the use of the toolset and CIEM as easy as possible, mappings of the CIEM to the different industry standards will be offered out-of-the-box within the toolset in the form of Transformation Models. This approach ensures that all partners share a common (business and technological) language in describing SELIS applications and IT modules, eliminating inconsistencies and ambiguities. An example of a business object designed with the Domain Models Constructor is depicted in Figure 7.


© SELIS, 2017 Page | 24

Figure 7 The Business object “Consignment” based on ISO/IEC 19845

4.1.1 Usage of Domain Models Constructor in Living Lab 8

The Domain Models constructor tool was used in one of the SONAE use cases of LL8 which was related with stock optimization between SONAE and their suppliers for a specific set of products. After defining all the specifications and use case requirements and identifying the related EGLS, the constructor tool was used to design all the domain related concepts with respect to the SONAE technical specifications. The SONAE DSS application is responsible for demonstrating various KPIs and calculations (e.g. Order Forecast) done in the Big Data Layer within the SCN Node of SONAE.

In the Domain Models Constructor tool, the designing of how the order forecast is stored and semantically described can be seen in the following figure (Figure 8). As depicted, an Order Proposal class has several attributes like ReplenishmentCycle and OrderInventoryDays. The class is related with the class Item and Warehouse


© SELIS, 2017 Page | 25

Figure 8 SONAE Order Forecast Business Object

The relationship between two classes is expressed with the association link. Two classes can be related with:

• ZeroOrOne relationship which means that e.g. an “OrderProposal” can have zero or one “Item” (see Figure 9)

• One relationship which declares that explicitly one instance of a class can have one, zeroorone or many instances of another

• Many relationship which expresses that many e.g. “OrderProposal” instances can have one, zeroorone or many instances of the class “Item”.


© SELIS, 2017 Page | 26

Figure 9 Class Association Properties

Once a Business Object is created, the corresponding database tables are created automatically. The Constructor tool gives the option to declare specs for each BO, such as:

• Select the BO to be persisted which means to save in the database any data change occurred in the runtime

• An automatic spec within the tool is that each class has by default an Id attribute which is auto assigned

The Domain Models Constructor Tool also supports the creation of class methods which are called operations of the class. These operations are enriching the functionality of the class and the class attributes are used to several calculations from simple ones like getters to more complex like algorithmic calculations.


© SELIS, 2017 Page | 27

Figure 10 Class Operations

Another feature added in the Domain Models Constructor Tool is that for each class, there is a search function that identifies where this class is used within the application, e.g. with which other classes is associated and in which is functions is currently used. An example of this functionality is depicted in Figure 11.

Figure 11 Class Usage Search

4.2 Business Processes & Workflows

In an application development toolset, it is required to be able to design the workflow of actions and the business processes by having the following components:

• Tasks


© SELIS, 2017 Page | 28

• Roles

• Events

• Rules

• Routings

The tasks are identified through the analysis of business requirements as well as the roles that will participate in each workflow. A role is a class of actors who perform the same task and mainly it is used to direct a task to a group of users and not to individuals. In such a way, the workflow is getting more flexible and easier to maintain. The events define when an action is taken and what is triggering it. The rules determine which activities are required to process the data. The rules are implemented through workflow events. The business rules typically are also specifying which roles do which tasks. Routings specify where the information goes and what form it takes: email message or worklist entry. Routings make it possible to deploy applications throughout the enterprise. They work through the levels and departments of an enterprise to bring together all of the roles that are necessary to complete complex tasks.

In SELIS toolset, instead of keeping the core business processes untouched, developers will be able to adjust and reengineer the processes based on a new system architecture. Conceptually, the approach proposed will decouple the business process logic from the business data (domain model) and presentation logic (user interface).

Therefore, the developer will always have a “declarative” view of how various objects use their services to interact and how they collaborate to produce the desired functionality and operations. Moreover, these models will be able to be edited through visual editors and have an easy-to-use and easy-to-understand visual representation. Making modifications to business processes will therefore be easier than having to understand and modify large chunks of procedural code.

Within the toolset, the notion of workflow is defined with a workflow meta-model that designate the required entities, their attributes and methods (Figure 12).

Figure 12 Workflow meta-model


© SELIS, 2017 Page | 29

A workflow within the Toolset is composed of business blocks that are representing the business steps or/and activities and tasks. For each block, it is possible to build business logic in the background to enrich it with functionality, business rules and conditions. Such an example is given in Figure 13.

Figure 13 Sample Workflow model created in the Toolset

After creating the workflow model with the tasks participating and the essential conditions that declare the ordering and the triggering events, the tool also enables scheduling where a developer can set a job (a scheduler) and the frequency of acting. In this context, the developer can set a task to be executed within a specific time frame. An often example of such a scheduler is to program a retrieve task to run daily, hourly and so on and so forth Figure 14.


© SELIS, 2017 Page | 30

Figure 14 Enabling Scheduling within a workflow

4.3 Data Mapper and Transformer

4.3.1 Data Transformation Tool

The SELIS Toolset includes a tool for mapping different data structures. This is accomplished by mapping among classes and their attributes. The mapping is made either by the developer or automatically. Data Transformation is encoded within the Toolset based on a specific meta-model that standardize how the data transformation tool is working and how is defined conceptually (see Figure 15).


© SELIS, 2017 Page | 31

Figure 15 Data Transformation meta-model

The data transformation tool is used to map the relevant attributes from one domain structure to another and consequently it produces the necessary low-level code that realizes the data transformation, according to the selected technology stack.

Transformation engines and generators analyze certain aspects of models and then synthesize various types of artefacts, such as source code, ensuring the consistency between application implementations and analysis information associated with functional requirements captured by models. This automated transformation process is often referred to as “correct-by-construction”, as opposed to conventional handcrafted “construct-by-correction” software development processes that are tedious and error prone.

An example of data transformation is presented in Figure 16. The domain structure for the Client business object presented on the left column is the one build in the SELIS toolset with its attributes while on the right side is the existing structure of the corresponding object and its attributes as received from an external API service.


© SELIS, 2017 Page | 32

Figure 16 Example of Data Transformation

Contrary to transformation approaches that are constrained only to specific messaging schemas/languages (e.g. XSLT for transforming XML messages from one dialect to another), the Data Transformation Tool offers a higher level of abstraction and richer transformation semantics that can be applied to different message formats. Thus, it is possible to define transformations from the input of a JSON-based web service to the internal model of Common Information model and vice versa. Moreover, logic can be applied to the transformation: the real world needs for transformations across different formats are usually more complicated that just mapping data from one data field to another. Intermediate processing has to be done (e.g. when the two interacting systems use different code-tables to represent data), which is allowed in the Data Transformation Tool with the use of code in a simple scripting language.

4.3.2 Data Transformation Inference Engine

A semi-automatic mapping tool has been developed in the SELIS toolset that automates the attributes mapping process of the data transformation tool, leading to the formalization of the data transformation inference engine. The main parts of the engine are the data pre-processing and the decision process that follows the semantic features extraction and is realized with the development of a specialized machine learning algorithm. The motivation behind the automation of the mapping process is the complexity of matching concepts from one messaging schema to another. With the Inference Engine, the application developer bypasses to a large extend the tedious task of mapping concepts that have obvious semantic or lexicographic relevance. Thus, the developer can focus on the transformations that require additional processing or are not evidently related.

4.3.2.1 Pre-processing

Data pre-processing is performed to develop an abstraction by removing all the unnecessary elements and keeping only the necessary ones, for example from the name of each attribute or class. In this way, semantic features extraction can be optimized. Figure 17 shows the relevant steps in a name pre-processing case.


© SELIS, 2017 Page | 33

Figure 17 Data pre-processing for optimized semantic features extraction.

4.3.2.2 Decision Process

The semantic features extraction is performed using semantic analysis techniques, with the proper use of specialized semantic networks, such as MIT’s ConceptNet, but also taking into account domain-specific ontologies. The main effort is to keep most informant words, such as nouns and verbs, and to calculate semantic similarity score between two terms in order to identify the amount of common information these terms share:

1. “Is A”: Use of ConceptNet to use the noun in class’ or attributes’ name. E.g., “Invoice” is A

“statement of account”.

2. Synsets: Use of WordNet (Princeton’s lexical database for English) to determine if two

words share a common meaning.

3. Semantic Similarity Measure: It is a decimal score that measures how similar two senses

are, e.g., client and person. It is a pair-wise metric that is context-dependent, and it uses

WordNet and ConceptNet in combination.

This process (Figure 18) is applied to classes and to the attributes of each class, realizing the data transformation inference engine which automates the data mapping process.


© SELIS, 2017 Page | 34

Figure 18 Semantic similarity measure approach in the decision process of automated mappings.

The following two figures show examples of the decision process of the data transformation inference engine, for lexical abbreviations (Figure 19) and the semantic similarity measure estimation (Figure

20).

Figure 19 Mapping of Abbreviations in the decision process.


© SELIS, 2017 Page | 35

Figure 20 Semantic similarity in the decision process.

4.3.3 Usage of Data Mapper and Transformer in Living Lab 8

Within the same use case of SONAE that was briefly described in 4.1.1, the Data Mapper and Transformer tool was used. The target was to use an existing external application, Elasticsearch6 which is a distributed, JSON-based search and analytics engine designed for horizontal scalability, maximum reliability, and easy management. This analytics engine is used to measure application performance indicators. The SONAE DSS application which is responsible to visualize the aforementioned KPIs had to retrieve all the searches and calculations done within the Elasticsearch service. With the Data Mapper and Transformer Tool, the data structure of Elastic search was mapped in the corresponding domain model of the SONAE DSS app, designed with the Domain Models Constructor tool (see Figure 21).

6 https://www.elastic.co/products/elasticsearch

https://www.elastic.co/products/elasticsearch


© SELIS, 2017 Page | 36

Figure 21 Data mapping and data transformation in LL8


© SELIS, 2017 Page | 37

5 Conclusions

The domain of supply chain security IT introduces several challenges for the development of applications and services for supply chain integration and management. This deliverable presented and analyzed the basic features of the SELIS Toolset that address these challenges, from the abstract level of the development methodology (following an MDE approach) to the introduction of the toolset (releasing Domain Models Constructor and Data Mapper and Transformer) that is tailored to the vision, the objectives, and the approach of SELIS project.

Through the analysis and the development of MDE-based methods for the construction of the proposed toolset, we concluded on the appropriate methodologies to incorporate design semantics that allow the support of features in line with the supply chain security frameworks. These semantics, for example, facilitate the data mapping between heterogeneous systems and enable the alignment with EU-wide Green Logistics Strategies and the Common Information Exchange Model in the developed SELIS-focused solutions.


© SELIS, 2017 Page | 38

6 References

Fowler, Martin. Patterns of Enterprise Application Architecture. [Addison Wesley, 2002]

Schmidt, D.C. 2006. Model-driven engineering. IEEE Computer, vol. 39(2), pp. 25-31.

Documents

Towards a Shared European Logistics Intelligent ... · • ST5.3.4 Visual Analytics, UI and Dashboard Generation: Design the user related presentation items. Integrate available open