uebe.Q is a managing software for solid referential information systems, such as ISO 9000 (for quality) and ISO 1400 (for environment). This is a long-term developed software, encompassing extensive and solid business logic with a long and successful record of deployments. A recent business model change imposed that the evolution and con guration of the software, shifts from the company (and especially the development team) to consultants and other business partners. The so far acceptable rigidity, fragility, immobility and opacity of the software became a problem. This paper describes the approach adopted in re-engineering the software by using (i) ontologies for the speci cation of business concepts, (ii) closed-world assumption (CWA) rules for the speci cation of the dynamics of the system and (iii) DSL for the con guration of the system by domain/business experts.
uebe.Q3 is an information managing software for solid referential information systems, such as ISO 9000 (for quality) and ISO 1400 (for environment). This is a long-term developed software, encompassing extensive and solid business logic with a long and successful record of deployments in di erent business areas and countries. Currently and for the last decade, when uebe.Q software is deployed for/on a customer, an extensive and speci c con guration process takes places involving the customer's business experts and the DigitalWind's software development and operation teams. So, typically, DigitalWind is the developer, the seller and the business consultant altogether.
A recent business model change determined that the con guration and adaptation tasks of the software shifts from the DigitalWind's development and operation teams to third-party consulting and other business partners.
However, uebe.Q con guration and deployment requires strong business and technological expertise, thus constraining the adoption of the new business model.
In addition, because con guration often requires speci c re nement of the
software, its rigidity, fragility, opacity and immobility [
Consequently, the goal of the project is to facilitate the software con guration by business experts and consultants while improving the con gurability and adpatability of the software. For that, it is prescribed an approach combining: { ontologies, that allows the con guration of the business concept according to the enterprise's business, department or individual employee; { rules, that allows the speci cation of business rules/constraints upon the ontological concepts, which goes beyond the expressivity of the ontological constraints. { DSL (Domain-Speci c Language), developed with the purpose to facilitate the business experts/consultants to con gure the system with minimal or no technical skills. 2
The legacy software (left-hand side of Fig. 1) adopts a client-server architectural style, whose backend (i.e. the server part) evolved into a large monolithic , developed in a myriad of frameworks (e.g. ASP, ASP.Net) and programming languages (e.g. C#, VB.Net). The backend is responsible for the data access (from/to relational database), business logic and server-side generation of the Rich Internet Application client-side UI pages (in HTML and JS).
Ontology, rule and DSL-based software re-engineering: a case study
While the business logic captured by the backend is a relevant asset, it su ers
from rigidity, fragility, opacity and immobility [
The dySMS Core component reads data directly from the legacy database, but the original business logic might be needed to update, delete or create data.
The DSL-based Con gurator allows the business consultant to de ne the domain-speci c ontology (model) and respective (business) rules. The DSL has been developed in the JetBrains Meta Programming System 4 which provides a projectional editor that drives the con gurator tasks according to the DSLcaptured structure and semantics (Fig. 3).
The semantics de ned through the ontology and rules follows a hierarchical policy, in which the semantics de ned at a hierarchy level binds to the semantics de ned in top hierarchy levels, promoting organizational reasoning consistency.
Fig. 2 depicts the inner architecture of the backend, including the identi cation of the parts/responsibilities and the details of the con guration interfaces. The system has the following components: { Model, is the set of classes and respective instances that are managed by the system. The classes, associations and constraints corresponds to the ontology(ies) de ned by the consultant using the DSL-based Con gurator (cf. Fig. 3). A re ection-based approach generates on-the- y the con gurationtime-de ned classes, allowing the system to operate with whatever classes structure is required.
{ ORM, which is responsible for the data access of the relational database and
the instantiation of the classes. The mapping between the ontology and the
database schema is de ned by the business consultant using the DSL-based
con gurator (cf. Fig. 3) complemented by an ontology mapping information
integration decision support system (cf. [
The combination of ontology, rules and the CWA reasoning provided by Drools allows adopting the same con guration/speci cation approach to di erent dimensions of the system, such as business rules, ORM, authorization and rendering. Running e orts are focused in adopting the approach in further customers and its adoption to other software.