S-CASE Blog | Hackathon4business

2

The S-CASE project coordinators, Aristotle University of Thessaloniki (AUTH), organised a set of hackathons this month to help showcase the final S-CASE solution. Aimed at two sets of key users the aim was to shape the development process while putting the S-CASE solution in the hands of potential future collaborators.

The two hackathons, titled ‘S-CASE hackathon4business’ and ‘S-CASE hackathon4students’, targeted web developers and undergraduate students respectively. Centre for Research and Technology Hellas / Information Technologies Institute (CERTH/ITI) participated in the hackathons as well, with a session on the Web Service Composition tool.

In this blog post we will focus on the results of the Hackathon4business, which specifically targeted web developers of companies and organisations in the vicinity of the Thessaloniki area.

Pre-hackathon survey results

Before starting the S-CASE hackathon we asked the registered developers to fill out a survey. We got 19 responses and the results can be found below:
pre-info1

pre-info2

pre-info3

pre-info4

pre-info5

pre-info6

pre-info7

pre-info8

pre-info9

pre-info10

Post-hackathon survey results

After the hackathon has finished and the developers have seen the platform and the procedure, we asked the attendees to fill out another survey. Fifteen (15) developers responded and the results can be found below.

post-info1

post-info2

post-info3

post-info4

post-info5

post-info6

post-info7

post-info8

post-info9

Through the hackathons 6 minor bugs were identified, which is a good number based on the fact that S-CASE was tested for more than 2 to 3 hours by 63 individuals on both days.

If you want to start using S-CASE today, or simply want to get in touch to find out more, please contact us

S-CASE Ontology Repository

In today’s blog we take a look at the S-CASE Ontology Repository being developed by CERTH.

The S-CASE ontology repository is intended to facilitate interoperability by standardizing a series of logically well defined relationships that act as a connectivity tissue for bringing together heterogeneous ontologies.

In this way, domain ontologies remain independent from the network as a whole and so can each undergo development processes without impacting on one another in complex and difficult to control ways.

This approach can be seen as a continuation and extension of several research and development threads begun in a range of large-scale engineering areas, including software engineering and the efforts within ontological engineering of other European projects.

Each operation will be supported through the web user interface along with the corresponding REST API for accessing the functionalities remotely by any application or module. It will host all ontologies that will be developed within the S-CASE project and will be provided as a Cloud Service over the S-CASE Cloud infrastructure.

The technical infrastructure will support among others the operations of ontology navigation, browsing, searching, visualization, uploading and downloading.

Find out more about the S-CASE concept.

 

S-CASE | Meet The Project – AUTH

In our latest blog we chat to project coordinators Aristotle University of Thessaloniki about the S-CASE concept and what they have set out to achieve with the project. Watch this short film to find out more.

Project Coordinator Andreas Symeonidis, Assistant Professor at the Aristotle University of Thessaloniki, explains:

“S-CASE practically is a tool for developers. When I say a tool for developers I mean a tool that will help software engineers to build software, find software that resides already in the Open Source community – but also in appropriate data services – and re-use all these in a very friendly and a very easy way.”

Technical Coordinator, Kyriakos Chatzidimitriou, added:

“S-CASE is about creating software services out of multi-modal requirements. We try to aid the developers in taking their development efforts towards building such services.”

To find out more about the S-CASE concept then you can read Kyriakos’ latest blog.

Familiar Bedfellows | The Automation engine, Model Driven Engineering and Victorian buildings (Part 2)

In this blog post, (you can read part one here), we will move back to S-CASE and the way MDE is utilised so as automated construction of RESTful Services is achieved.

In the S-CASE MDE engine, we encounter all the four discrete software construction stages that the 19th century civil engineer had to go through in order to build a Victorian house. These four phases of MDE have been already presented in part one. Only now, the S-CASE MDE engine does not build Victorian houses, but software of a particular architectural style.

The style that S-CASE follows for the web services it produces, is the REST architectural style (instead of the Victorian Style), enhanced with some design patterns and concepts. But what is REST anyway? It is a software architectural style for the web, which Roy Fielding introduced in 2000. In the same way the Victorian style has some characteristics like steep roofs, sash windows etc. that differentiate it from others, REST has some distinct properties as well (figure 1):

scasepic1

Figure 1: Image courtesy of http://martinfowler.com/

  1. Every RESTful web service (house) comprises only of resources (rooms)
  2. Each such resource has a unique URI (address) at which it is accessible.
  3. Every such URI is accessed with the common HTTP verbs. In contrast to other styles though, the HTTP verbs are used in the intended way. In any case, the POST HTTP verb is used to create a new resource, the GET verb is used to retrieve an existing resource, PUT is used to update an existing resource and DELETE to delete one.
  4. The resources are interconnected with hypermedia links.

The hypermedia links are probably the property that differentiates REST the most from other styles. But what are these links for? They are pretty much the same thing with the navigation arrows in an old-fashioned adventure video game similar to the one shown in figure 2. In this case, no matter wherever you are in the house (web service), you are always given the next possible actions. This means that you do not have to know them a priori, which in turn increases a lot the flexibility of the interaction between web services and clients. In this example, you may open any of the three doors, follow the corridor or go up the stairs. However, you absolutely have to take one of these specified actions! Thus, you may not stand in front of the painting on the wall to take a look! That is, should there exists a bedroom door upstairs, you may not open it from the position shown in figure 2. Instead, you first have to go up the stairs following the provided link and then open the door by using the link that you will be given once you go up the stairs.

Furthermore, the S-CASE’s MDE engine embeds to the REST style some more design patterns. One may think of them as additional decorations in every room other than those already introduced by the Victorian style. For example Model View Controller (MVC) is used in order to further apply the divide and conquer as well as the separation of concerns design principles. Additionally, the repository pattern is used to offer a uniform way to store stuff. This is like every Victorian house also had a storekeeper. That way, whenever anyone living in the house wants to store something in the warehouse, does not have to know where to store it (or from where to retrieve it). He simply gives it to the storekeeper instead.

scasepic2

Figure 2: Image courtesy of www.geffrye-museum.org.uk

So, how would a conversation be between a modern times customer, who wants to buy an e-shop service, and an MDE engine that knows how to build RESTful web services? The customer would probably say to the MDE engine what that service (house), which he wants to buy, should have. In particular, he could ask for some specific resources (rooms), like user accounts, user profiles, product inventory, the capability to pay with credit cards, search the products database or even have email notifications enabled. Additionally, he would probably ask for some properties to be added to those resources. For instance, he may ask that the user profile should contain some text placeholder where the user can write a description of himself. Moreover, the user accounts should have a username, a password and an email. Lastly, the product inventory should have a price and a textual description for each product. Once the customer specifies his needs to the MDE engine, the e-shop web service CIM is formulated.

One should recall at this point that like in the case of Victorian houses, nothing that has to do with software architecture, design patterns or even programming languages and web frameworks is discussed yet. At this initial stage of MDE that S-CASE goes through, only concepts of RESTful web services domain are examined, like resources, their relations and/or some properties of them, period!

From this point on, the MDE engine of S-CASE begins to apply the REST architectural style as well as the extra design patterns to every single concept that its customer included in CIM. For instance, the MDE engine would add to all the resources specified in CIM a controller entity that will handle all the incoming web requests with some type of protocol. Then, it would assign to each one of them a unique URI and input/output representation handlers of some type. Moreover, it would design an RDBMS database schema of some type that is sufficient to store the envisioned e-shop’s data, which is going to be accessed in a uniform way by means of a repository controller. Once the MDE engine transforms every single CIM concept by applying to it the described architectural style, the envisioned e-shop’s PIM is formulated. It must be stressed though, that likewise the Victorian house engineer did not specify the exact make of the materials, the MDE engine does not specify any specific technologies to be used at this point either. Instead, it used an abstract generic form of each of them (some type of protocol, some type of database schema etc.).

Similarly to the Victorian house case, the next step is to pick specific technologies (materials) with which the service will be constructed. In the S-CASE MDE engine for example, one possible combination of technologies could be the JAXB framework to handle the parsing and marshaling of incoming/outgoing representations, the JAX-RS one to handle incoming web requests of the HTTP 1.1 protocol, the Hibernate one to handle RDBMS database schema of (for example) POSTGRESQL and the Java language as the language to code the envisioned service. Once MDE engine applies a specified technology to every PIM component, the e-shop PSM is formulated. Of course, there could be many other combinations of technologies that could be used to form different PSMs. Other customers might choose another one from the available ones! Similarly to the Victorian house case and in any case, the relationship between PIM and PSM is always one PIM to many possible PSMs.

At this point, the appropriate, for the selected PSM, code generators (specialized builders of a Victorian house) write the actual software code. Once this is done, the process of building the e-shop RESTful service ends. Of course, like in the case of Victorian houses, some resources will end up to be fully implemented (fully built and decorated rooms), whilst some others will need some additions so as to be completed or there may be even some resources that are simple wrappers (empty rooms) interconnected with the other resources of the service. Such resources would require human developer intervention to get completed pretty much like the Victorian house garden would need a gardener to plant some flowers etc. to it.

Summing up, S-CASE utilizes MDE to automate the procedure of building RESTful web services. Once S-CASE parses the multi-modal requirements (UML diagrams, semi structured text etc.), it attempts to understand the needs of its “customer” in order to formulate the CIM. Later on, it applies the REST architectural style to transform the CIM to its according PIM. Then, according to user preferences, it transforms the PIM to one of the possible PSMs and finally, it initiates its code generator to produce the actual service code. The crucial point to stress one more time though, is that this process is an automated one. So the customer that “told his needs” to the MDE engine of S-CASE by providing his multi-modal input, would then get back the according RESTful service automatically and instantly.

This pretty much concludes the demonstration of the way the S-CASE’s MDE engine builds a RESTful service. At this point many possibilities arise. Which should be the acceptable concepts in CIM? What should be the enforced design of the PIM etc. Such issues will be discussed in the next entries related to meta-model engineering and automation trade-offs within the S-CASE MDE engine.

Read part one of this series.

Familiar Bedfellows | The S-CASE automation engine, Model Driven Engineering and Victorian buildings

In this blog post, the first of a series, Christopher Zolotas attempts to demonstrate the cornerstone technology used in S-CASE for automation, namely: Model Driven Engineering (MDE) using the analogy of Victorian architecture.

Object Management Group (OMG) has introduced MDE since 2000 and pretty much aspires to change the software design and construction paradigm. Its principal concept is the transition of code-centric software engineering to a model-based one, so as to achieve higher consistency, increased level of automation and productivity. In a nutshell, it aspires to deliver software in less time and at lower cost.

That said, the abstract nature of MDE concepts often makes it difficult to fully grasp the whole procedure. Therefore, in this blog post we will use an extensive metaphor taken from civil engineering domain through which we will gradually build up the concepts of MDE. Once this is done, in part two of this blog post we will examine the way S-CASE embeds MDE in order to automate the building process of RESTful services.

For the sake of this metaphor, we will use Victorian era buildings, which have a lot of distinct design characteristics and properties. Although there are quite many variations of Victorian Style buildings, we will examine the ones found in figure 1.

http://en.wikipedia.org/wiki/Victorian_house

Figure 1: Common Victorian style houses

Just by taking a look at the exterior of a Victorian house, we observe some common properties and patterns that differentiate it from all the others. For example, they have steep dark colored roofs and a lot of ornamentation details. Additionally, they are built with bricks and have a lot of fancy sash-windows with large glass panes.

Moreover, Victorian houses share a lot of common characteristics in their interior. Figures 2 and 3 illustrate two such examples. The wallpapers and the carpets are rich in patterns with either of them dyed in rich dark ruby reds or forest greens. The interior also exhibits heavily upholstered furniture that is usually overstuffed, while the woodwork is usually dark colored. Finally, when such houses were introduced, during the reign of Queen Victoria, they had gas-fuelled ceiling luminaries, gradually replacing the ones with candles.

http://en.wikipedia.org/wiki/Victorian_house

Figure 2: Demonstration of Victorian interior decorated with heavy patterned wallpapers

Of course, the point of this blog post is not to fully examine the Victorian style or even be absolutely accurate about it. The purpose is to clearly demonstrate that this specific style, as any other one, embeds some distinct characteristics and properties that differentiate it from the other ones. As a consequence, once you decide to buy such a house you expect it to have the aforementioned properties.  For the shake of this metaphor, let’s assume that we are hidden spectators of a conversation between some 19th century customer, who wants to buy a house, and a civil engineer. We will also assume that this civil engineer designs only Victorian houses. Furthermore, he will also play the role of a Victorian style decorator of the building interior. Therefore, since this customer picked this specific engineer, it means that he knows that what he is going to buy is a Victorian house with the aforementioned properties.

http://en.wikipedia.org/wiki/Victorian_house

Figure 3: Demonstration of a Victorian drawing room

During this conversation, the customer would probably explain his needs to the engineer. For instance he would probably want a spacious drawing room, a kitchen, a lavatory, a luminous dining room, one master bedroom and two child bedrooms, one for a boy and one for a girl. During this early stage of this collaboration however, no one considers any design issues or any specific materials that should be used for the building. They are focused on concepts related to the domain of house buildings. Thus, they are discussing only about the type and number of rooms it should have and probably some more details and properties of them. That’s it!

This is actually what happens during the first stage of MDE, which is the formulation of the Computational Independent Model (CIM). Nothing that has to do with the design of the actual piece of software is discussed, let alone specific implementation technologies or coding. It is only a discussion on what should be included in that house which is going to be built and nothing more.

Once the civil engineer is given the desired CIM concepts from his customer, he patiently and meticulously starts to design the building having in mind that the Victorian style must be applied to it. This is a step-by-step process that this civil engineer has to follow in order to create the design of the house in such a way that all the concepts his customer asked for in the CIM (3 bedrooms, 1 drawing room etc.) are taken care of. In particular, he will design a boy bedroom by applying to it Victorian properties like heavily patterned wallpapers and carpets, dark-coloured wood furniture for any closets/chest of drawers etc. and of course fancy sash-windows with big glass panes and a gas-fuelled ceiling luminaire!

However, the engineer does not yet bother to pick the specific materials with which the house will be built. He merely writes on his design that for the house exterior there will be used some sort of bricks. Additionally, the interior walls will be covered with some sort of patterned wallpapers, whilst the furniture will be of some type of dark-colored wood and the lighting will be of some sort of ceiling gas-luminaire. Full stop! Once he is done applying the Victorian style to every concept his customer asked for in CIM, he knows that he is done with the second phase of MDE, which is the Platform Independent Model (PIM) formulation or more appropriately the transformation of the CIM to its according PIM. In other words, in this second phase the design of the whole house that satisfies the customer needs, which were prescribed in the CIM, is introduced. Full stop!

Once the engineer is done with the PIM and before he calls his construction team to build the house, he still has to decide the specific materials to be used for that specific house. How does he decide that? This information originates principally from his customer. The customer will have to pick a specific combination of material brands that his engineer is able to handle. He is the one who pays after all!

http://en.wikipedia.org/wiki/Victorian_house

Figure 4: Some parts, like a garden, will need specialised personnel like a gardener.

Once the engineer knows his customer selection, he is able to proceed to the next phase. At this point he knows that the parts of the building that consist of bricks should be build with bricks of make X, the wallpapers should be of make Y, the ceiling gas lighting should be a specific 1897 model of make Z etc. In fact, when this point is reached, the engineer knows that he has transformed every single component of the house PIM to its specified counterpart, which is the Platform Specific Model (PSM). In other words, the engineer has specialized the materials with which the building of that specific design described in PIM is going to be implemented according to one of the available material combinations. Other customers could possibly pick other material combinations though (other PSMs). Thus, there is a relationship of one PIM to many PSMs. One PIM that embeds a specific design may be transformed to any number of different PSMs (different combinations of specific materials).

The final step is to employ a specific construction team that knows how to construct the Victorian buildings with the specific kind of materials that were selected. For example, he will have to hire builders that know how to handle bricks of make X following the Victorian Style. Similarly, he will hire an interior decorator that knows how to apply on the walls make Y wallpapers that are heavily patterned etc. Of course, it is quite probable that some parts of the building may be partially completed or even empty. For example, parts like a garden (figure 4) will need specialized personnel, like a gardener, to get completed. This final step is the analogous phase in MDE of the code generation from a PSM. Some parts of the code will be fully implemented, whilst others will need programmer intervention to get completed.

This is pretty much MDE. It comprises of four phases through which the MDE engine (civil engineer) has to go through. The CIM formulation with the high level domain concepts, then the transformation to the PIM in order to introduce the appropriate design, followed by the transformation to a PSM where specific materials are picked up for every aspect of the subject that is going to be built. The final step is the code generation (the action of building) and the revision by developers (specialized experts). It must be stressed though, that this procedure is automated. That’s the point! For instance, if a customer was able to speak to an imaginary MDE engine that knows how to build Victorian houses, he would say his needs to it and then the MDE engine would return to him the building automatically and instantly! In other words, the transformations, transitions from phase to phase, are automated.

In the following blog post, the second part of the MDE introduction, we will build upon the concepts demonstrated in this one through this metaphor. Thus, we will attempt to show how S-CASE embeds MDE in order to build RESTful web services or in other words, pieces of software that follow the REST architectural style.

S-CASE Blog | S-CASE Development fuel booster

We have just finished hosting the 4th meeting of S-CASE here in Athens and feel excited to have a pilot contributing to our big and exciting development goals.

Not only that, the project and consortium itself has been a tank of inspiration, feeding us with new ideas and food for thought. As the first year comes soon to a wrap and after a lot of creative preparations, our pilot has now a clear positioning and connection to the Watchtower API’s offering, which will be soon available for use from our clients. The API’s environment is designed in a way that the Watchtower platform becomes the backend analytics for the customers, who need automated intelligence in their systems without having to develop their own analytics infrastructure. This way they go fast, low cost and with reliability, since the services consumed have been already tested and in production.

The vision of S-CASE is to provide tools for developers, along with the underpinning technologies that will support the insertion of rough system requirements in a variety of structured, semi-structured or unstructured formats for seamlessly generating draft software prototypes that will form the basis for complete software development.

S-CASE is seen as a rapid prototyping realm aiming at providing automated solutions for (a) the extraction of system specifications and low-level architecture, and (b) the discovery and synthesis of composite workflows of software artefacts from distributed open source and proprietary resources that fulfil the inserted system requirements in the best possible way.

Through the innovations it introduces, S-CASE is expected to have a significant impact on the reduction of the time that is required between the conceptualisation of a software system and its first prototype, thus improving the SE process in terms of development costs.

The S-CASE pilot – Unleashing the power of WISE

 

The power of the Watchtower lies to a big extend in our analytics engine called WISE (Watchtower’s Intelligent System Engine). Inside WISE lives all the automatic orchestration that takes of the shoulders of energy management teams the “discovery” part and lets them focus on their operations. The pilot will actually take our API’s one level down from today, inside the WISE. That means that our partner and customer developers will be able to create their own orchestrations instead of only using the ones that WISE exposes. This is taking us closer to a data analytics as a service model, where different customer needs and discard data sets can be analysed as customised as needed.

The Watchtower SAAS technology stack is an MVC architecture using javascript from end to end (MySQL, Express.js, Angular.js, Node.js) with the combination of WISE core functionality developed in Java. Every rule of the WISE core is being exposed with RESTful web services, creating an ecosystem of intelligence that depending on the functionality needs, separate orchestrations of the web services are being composed. The S-CASE platform like a fuel booster, will rapidly improve our productivity in developing these new web services and the development of new intelligent orchestrations inside WISE.

S-CASE Blog | The S-CASE concept

In our latest blog entry, project technical coordinator, Kyriakos Chatzidimitriou, takes us through the world of S-CASE, highlighting the project components and demonstrating how S-CASE will be realised.

The S-CASE project is about semi-automatically creating RESTful Web Services through multi-modal requirements using a Model Driven Engineering methodology. The world of web services is moving towards REST and S-CASE aims at facilitating developers implementing such web services by focusing mainly on requirements engineering. The figure below depicts the basic components and basic flow of events/data in S-CASE.

 

In order to better understand the practical application of the S-CASE solution, let’s take a look at a typical use case example.
Through the S-CASE IDE the user imports or creates multi-modal requirements for his/her envisioned application. The requirements may be:
  • Textual requirements in the form “The user/system must be able to …”,
  • UML activity and use case diagrams created in the platform or imported as images,
  • Storyboards for flow charting, and
  • Analysis class diagrams to improve the accuracy of the system to identify entities, their properties and their relationships.

The requirements are then processed through natural language processing and image analysis techniques in order to extract relevant software engineering concepts. These are mainly the identification of RESTful resources, their properties and relations and Create-Read-Update-Delete (CRUD) actions on resources. All these concepts are stored in the S-CASE ontology.
The above procedure also identifies action-resource tuples that can be created automatically by the system like the action-resource “create bookmark” (automatically built) or others that need more elaborate processes like “get the weather given geolocation coordinates” (semi-automatically build or composed). The latter are send into the Web Services Synthesis and Composition module.

The Web Services Synthesis and Composition module tries to synthesize elaborate processes by composing 3rd party web services into a single S-CASE composite web service. To perform such a computation, S-CASE provides a methodology for semantically annotating 3rd party web services using S-CASE domain ontologies, so that they can later be matched to the requirements of the composite service. The composite service is deployed to the YouREST deployment environment and registered in the directory of S-CASE web services for future reference and re-use.

Upon completing the stages above, the model driven engineering procedure initiates. The first step is to create the Computational Independent Model (CIM) out of the S-CASE ontology. The CIM contains the bare minimum information needed to scaffold a REST service that adheres to the requirements imposed by the user, i.e. it includes all the problem’s domain concepts.

After that model transformations take place transforming the CIM into PIM (incorporate design constraints, but platform independent) and PSM (Add support for implementing the PIM into a specific suite of software tools like: java, jax-rs, hibernate, json, jaxb, postgresql etc.). The final step is to automatically generate the code of the web service. Calls to composite services are wrapped inside the generated code. The code is build and deployed to YouREST for others to use.

In order to support software re-use, every software artefact created from this procedure is stored into the S-CASE repository for future retrieval.

Through S-CASE we plan to develop an ecosystem of services, along with the appropriate tools for service providers to develop quality software for SMEs with an affordable budget.

S-CASE Blog | Towards the design of user friendly search engines for software projects

In our latest blog S-CASE Project Coordinator, Andreas Symeonidis, takes us through the world of search engines for software projects as we take a deep dive into making software development more user friendly.

Usually, when developers begin the planning and designing of software they find they have too few appropriate tools that enable them to reuse the optimal set of functional requirements and well engineered software modules which satisfy said requirements.

In Toward the design of user friendly search engines for software projects we suppose that were such tools available and this information properly stored, developers would be able to access other Software Engineers’ solutions to similar projects and could reuse them as off-the-shelf components, or could adjust them to their own needs.

Taking this argument one step further, one could argue that such “search engine: for software projects could be interactive, allowing users to progressively identify the required software contructs, and adaptable, in order to increase its knowledge base. Question Answering (QA) systems could provide the means to realise such search engines, given that they illustrate these types of features.