Int. J. Business Process Integration and Management, Vol. 3, No. 4, 2008
239
Software engineering within a dynamic digital business ecosystem G. Marcon, H. Okada and T. Heistracher* Department of Information Technology and System Management, Salzburg University of Applied Sciences, Urstein Süd 1, A-5412 Puch/Salzburg, Austria Fax: +43-(0)50-2211-1349 E-mail:
[email protected] E-mail:
[email protected] E-mail:
[email protected] *Corresponding author
A. Corallo and M. De Tommasi e-Business Management School, Università degli Studi di Lecce, Via per Monteroni s.n., 73100 Lecce, Italy Fax: +39-(0832)-297-211 E-mail:
[email protected] E-mail:
[email protected] Abstract: The goal of fast adaptations and modifications according to continuous change requests is common to all software engineering methodologies. In most cases, sooner or later this results in a mismatch between the software specification and the actual implementation with related disadvantages such as the impossibility of performing validations of related models. We present here an aspect of the digital business ecosystem concept that gives incentives for more responsible software engineering approaches in general by offering a platform for automatic composition of services and re-adaptation of the specifications based on actual changes. The main innovation is a natural language based modelling notation that enables ecosystems of companies to use software described in a high-level language that can also be understood by non-technical users. Keywords: semantics of business vocabulary and business rules; SBVR; digital business ecosystems; extended enterprise; automatic code generation; business process integration; round-trip engineering; small and medium enterprises; service-oriented architecture. Reference to this paper should be made as follows: Marcon, G., Okada, H., Heistracher, T., Corallo, A. and De Tommasi, M. (2008) ‘Software engineering within a dynamic digital business ecosystem’, Int. J. Business Process Integration and Management, Vol. 3, No. 4, pp.239–247. Biographical notes: Giulio Marcon obtained his honours in Computer Science from the Ca’ Foscari University of Venice with a thesis in computational biology in 2004 and gained practical experience in both the industrial and academic context as a software engineer, system architect, teacher and research assistant with focus on theory and application of algorithms and data structures. His last years’ research is characterised by a rather interdisciplinary approach in particular in computer science and biology. His current research interests embrace natural language based software engineering, complex systems and computational biology including process and ambient calculi. Hisanaga M. Okada is currently involved in the Digital Business Ecosystems project at the Salzburg University of Applied Sciences in Austria. His previous work in a research institution in Canada has included bioinformatics positions in genomics, data mining and mapping. This is related to his studies in computing science, molecular biology and biochemistry at the Simon Fraser University in British Columbia, Canada. Thomas J. Heistracher obtained his PhD in Physics and Biophysics from the University of Salzburg in 1996 with work related to modelling of biological systems. In industrial projects, he gained expertise in systems integration and adaptive metadata systems for commercial use. Since 1999, he has been tenured Professor at the Salzburg University of Applied Sciences and Head of the Department of Informatics and Software Engineering. He is leading national and contributing to international research projects. He is also active as steering committee member for the Ministry of Innovation and Technology.
Copyright © 2008 Inderscience Enterprises Ltd.
240
G. Marcon et al. Angelo Corallo is a Researcher at the University of Lecce. After receiving his degree at the University of Lecce in High Energy Physics, he won a Fellowship Research Position in Naples in the European Space Agency space mission Rosetta. Currently, he collaborates with eBMS ISUFI where he coordinates research and development projects about e-business and knowledge management and about the impact of technology on innovation and organisational problem solutions. He collaborates with OMG for the development of metamodel and standards for business enterprise integration. Maurizio De Tommasi has research experience in MDA business modelling for enterprise systems and business rules engineering. He is involved in design and development of e-business distributed systems based on SOA and MDA. Currently, he collaborates with the OMG Business Modelling and Integration Domain Task Force on development of metamodels and standards for business enterprise integration. He received his degree in Software Engineering at the Università degli Studi di Bologna in 2001 with dissertation titled ‘Web services: a new distributed computation paradigm’, for the development of interoperable loosely coupled applications based on the XML web services paradigm and service-oriented architectures.
1
Introduction
The widespread usage of internetworking technologies enables companies to easily expand their business and to transform it in a decentralised organisational form denominated ‘extended enterprise’ that takes full advantage of modern telecommunication technologies and tools for managing processes, coordinating activities and optimising return on investment. As a side effect, the increased communication leads to the creation of huge networks of business relationships, naturally linked in structures comparable to natural ecosystems, where products and services offered by companies take the place of individuals and their sector and location takes the role of the environment. This ecosystems structure has many advantages, for example: •
it is more ‘flexible’, as the orchestration of processes can easily adapt to market changes by involving new partners or substituting the ones that do not perform
•
it gives more ‘balanced opportunities’, as small players can team up to compete against bigger players
•
it is more ‘cost-effective’, as it simplifies processes and exploits a broader marketplace.
In 2002, the European Union started fostering an idea based on the existence of such an ecosystem-like network of companies and the widespread use of web services (Nachira, 2002). The ideas consisted of populating the network with services as ‘digital creatures’ and have them evolve and compete against each other the same way it happens in nature, using models like predator-prey and co-evolution for software services. This digital dimension from the extended network adds a whole new set of possibilities as it enriches the service-oriented architecture (SOA) with an ecosystem structure that enables automatic service combination, evolution and optimisation (Erl, 2005). In this paper, we analyse the effects of a digital business ecosystem as an incentive system for responsible software engineering: first, we present the language used to express
software specifications; we then detail the benefits for a software-oriented architecture focusing on the software engineering and adaptive aspects; finally, we envision a system capable of code generation and of self-adaptation of the software specification based on its actual implementation.
2
Natural language software specification
In software engineering, it is a current practice to formulate in writing the requirements and high-level specifications for software solutions, where the aim is the achievement of a common understanding of the terminology involved and to obtain a clear picture of the functional requirements that at this stage are still far from the technical details. The resulting documents are then gradually transformed into the technical specification expressed in modelling notations such as UML for software or, to give an example for hardware, in VHDL. At that point, the link between the natural language description and the technical specification is broken and the customer loses the possibility to influence and verify the ongoing work (see Figure 1). Figure 1
Software specification using standard current practices (UML, to the left) and natural language based techniques (SBVR, to the right)
Note: From an initial natural language requirements analysis, current practices drop very soon below the level of understanding by the customer, whereas with natural language software engineering the customer can follow most of the process.
Software engineering within a dynamic digital business ecosystem Several authors recognised this fallacy of software engineering processes. In the past, the use of natural language for software design was tacitly accepted as an informal modelling technique but still raised the question of whether a formal approach to natural language software engineering was feasible. Starting with the ‘70s, there have been some efforts in dealing more formally with natural language specifications (Halstead, 1977; Zachman, 1987; Saeki et al., 1989; Carasik et al., 1990; Sowa and Zachman, 1992; Boyd, 1999, as cited in Boyd). For instance, metrics for measuring software complexity were defined over natural language specifications. Some authors suggested the possibility of a mapping between natural language and a programming language offering some specific primitives. Following the same line of research, some strategies were defined for writing code in specific programming languages (like Ada) starting from a natural language description. Other programming languages supported directly some sort of natural language constructs: Smalltalk, for instance, has an extensible keyword syntax supporting expression of the type subject-verb-object. Lisp, a functional programming language, uses s-expressions that mimic natural language so well that it became the favourite language for artificial intelligence applications. Most of the past approaches were trying to find a direct link between the specification and the code, while current ones make use of intermediate steps in the transformation. Specifically, the approach that we present here considers a structured version of natural language and a progressive model transformation leads to the final code. Modelling notations for software are unfortunately required to avoid the ambiguity of natural languages: to bridge this gap, OMG started defining a modelling notation based on natural language called semantics of business vocabulary and business rules (SBVR) (OMG1, 2006). This recent effort aims at defining the desired computational independent modelling language for the model driven architecture (MDA) (Frankel, 2003, see Figure 2). A business or process model written in SBVR satisfies the implementers and the customer, as it is both formal and understandable. The formal structure of SBVR comes from logics and is completely integrated in the language: every SBVR statement can be transformed in a higher-order logic proposition (for an example of an SBVR statement, see Figure 3). Figure 2
Positioning of SBVR in the MDA, according to the vision of the Object Management Group
Note: Picture adapted from the SBVR specification.
241
The capability to define vocabularies and rules in different languages (e.g., English, German, Italian…) is another possibility given by SBVR. The business models can be automatically translated, although at the time of writing only the structured English vocabulary is defined in the specification. Global software development processes will strongly benefit from the use of SBVR with multiple structured and interlinked vocabularies. Communication among partners with different cultures and languages can happen transparently and without the risk of misinterpretation, improving the overall software quality, cutting down communication problems and lowering production costs (Heistracher et al., 2006). Distributed software development presents several advantages over monolithic approaches, in particular for competitiveness, flexibility and risk management and quality assurance (Kurz et al., 2005). Using distributed resources for the development allows the implementer to sub-contract to partners having specific expertise and to improve the overall software quality. Having several tasks clearly split among partners constrained by formal contractual agreements helps in handling and managing risks. When using SBVR, the customers can easily influence the requirements analysis process up to a later stage compared to processes utilising UML: the development of tools for editing the vocabulary and rules gives them independence from the analysts (see Figure 1). Currently, at least a commercial1 and an open-source2 implementation are being developed for this aim. The SBVR specification defines a meta-model designed to be used for business purposes, independently from the design of the IT systems. It addresses row 2 of the Zachman framework, related to the ‘business model’ or ‘conceptual level’, managed and decided by the owner of the enterprise (Zachman, 1987; Sowa and Zachman, 1992). SBVR has been created to provide a means of interchanging business information among organisations without ambiguity. SBVR is self-described: SBVR itself is used to describe the foundation of the language. The basic mechanisms to define new models are not instantiation, like it strictly would be in the MDA architecture, but by ‘extension’. Creating a model means to take the basic SBVR vocabulary and to extend it. A vocabulary should contain (formalise) all the concepts shared by a particular community, called the ‘body of shared meaning’. An SBVR vocabulary is composed of two main parts: ‘concepts’ (including fact types) and ‘business rules’. With SBVR, it is possible to define concepts in several ways, for instance as taxonomies, categorisation schemes, specifying synonymous forms, abbreviations or comprehensions. Fact types are concepts that specify the form that a fact can have and are used to establish relationships among concepts. A concept can be provided a definition, that is a semantic formulation making use of specific keywords and other concepts defined in the same vocabulary. Business rules can be structural, defining the necessity of some business concept, or operative, defining a business
242
G. Marcon et al.
obligation. A business rule in SBVR is, rather loosely, a ‘rule that is under business jurisdiction’. A rule is always built with necessity or obligation operators (respectively, ‘alethic’ and ‘deontic’ logic). Figure 3 shows that SBVR has a normative syntax that is based on fonts and colours consisting of a list of concepts with their specifications.
SOAs. First of all, a user with little particular technical skills can perform the requirements analysis for software and submit it as a request. The request can then be satisfied in several ways: •
some implementer finds the request and offers to develop it
Figure 3
•
several components existing in the digital ecosystem can be re-used to satisfy the request and the additional parts necessary are developed by some implementers
•
all the necessary components are already in the digital ecosystem and only fine-grained optimisation prior to deployment needs to be done.
An example of a part of an SBVR model (see online version for colours)
branch Concept Type: Definition: car movement Definition:
organization function rental organization unit that has rental responsability planned movement of a rental car of a specified car group from a sending branch to a receiving branch
receiving branch Concept Type: role Definition: branch that is the destination of a car movement sending branch Concept Type: role Definition: branch that is the origin of a car movement car movement has receiving branch Necessity: each car movement has exactly one receiving branch car movement has sending branch Necessity: each car movement has exactly one sending branch rental car is assigned to car movement Necessity: At most one rental car is assigned to each car movement car movement being international Concept Type: characteristic Definition: car movement having country of sending branch that is not the country of receiving branch of the car movement.
Figure 3 shows that concepts are underlined and coloured light green, special keywords in typewriter font and coloured red and semantically interpretable statements are italicised and coloured blue. A concept can have specifications, each composed of: the specification name, a colon and the value for that specification name. Also fact types (also known as verb concepts) are concepts. Facts, necessities, possibilities, obligations and permissions are on the contrary ‘propositions’. Both concepts and propositions are part of the body of shared meaning. SBVR has a normative syntax that is based on fonts and colours consisting of a list of concepts with their specifications. Concepts are underlined and coloured light green, special keywords in typewriter font and coloured red and semantically interpretable statements are italicised and coloured blue (see Figure 3). A concept can have specifications, each composed of: the specification name, a colon and the value for that specification name. Also, fact types (also known as verb concepts) are concepts. Facts, necessities, possibilities, obligations and permissions are on the contrary ‘propositions. Both concepts and propositions are part of the body of shared meaning. SBVR addresses also the issue of semantic interchange in the MDA architecture by defining a vocabulary-to-MOF/XMI rule set. SBVR models have thus a corresponding MOF model that can be used to generate a XML schema.
3
These solutions go from a low to a high degree of automation. We foresee that the more automated the system is, the more components the digital ecosystem will consist of. These components will gradually become very small and loosely coupled so that by interaction among them, they will be able to satisfy most requests. To move to such a level of automation, the system needs to proceed along the following steps (see Figure 4): •
decompose the request/specification in atomic units
•
match the atomic components of the request to the ones available in the digital ecosystem
•
offer the best solutions to the requester, so that he can choose the most suitable one
•
combine the components to satisfy the request and create the necessary glue code using the semantic information in the SBVR descriptions (initially this can be done through a graphical manual composer)
•
open bids for developers to implement components that are still missing.
The first three steps define an optimisation problem known to be very difficult to solve. Choosing the minimal set of services to fulfil all requested features is an abstraction of the set covering problem (SCP), which is NP-hard in the strong sense (Garey and Johnson, 1979; Karp, 1972) and hard to approximate (Lund and Yannakakis, 1994; Feige, 1998). Figure 4
Automatic decomposition of service specifications and automatic composition of already available components and custom implementations
An ecosystem of companies and components
The digital business ecosystem is an interconnected environment where companies offer and consume services. When the description of such services is done in SBVR, there are some advantages with respect to more classical
Additionally, when working directly with the higher-order logic statements of SBVR, the problem becomes even harder to solve, as the underlying logic is not decidable (Henkin, 1950; Gallier, 1986). Strong heuristics
Software engineering within a dynamic digital business ecosystem have to be developed to deal with the specific problems of SBVR. The SCP is solved by reducing the search space through a distributed optimisation. The current approach consists of creating a zero-one matrix in which the features available from the services are mapped. A simplified version of SBVR can then be used to reduce request features and descriptions to binary strings. Research in this field has been ongoing with the digital business ecosystems project through the use of various estimation of distribution and genetic algorithms. Namely a genetic algorithm (GA) proposed by Beasley and Chu (1996) and a univariate marginal distribution algorithm (UMDA) proposed by Mhlenbein and Paa (1996) adapted for the SCP are being tested for its performance and effectiveness. The UMDA strives to solve the SCP by adding and removing services until the SCP is solved, then at the last step, drop services that are overlapping with other services already present. The GA, on the other hand, strictly modifies every instance so that at each iteration a valid solution exists. The goal over time is to minimise the number of services needed as the algorithm iterates. To give preliminary results, we conducted performance tests regarding both approaches. In Figure 5, the number of services used is plotted over time for using GA (lower curves) and UMDA (upper curves) for different instances of the SCP. It can be seen clearly in this instance that the GA, which steadily finds solutions which require less services, outperforms the UMDA in which the drop in services used in the last step of the algorithm does not drop below those solutions used by the GA. Figure 5
Preliminary test results of the comparison of the UMDA and the GA
Notes: This test plotted the number of services used for both algorithms for three SCP instances denoted by the problem reference number. The upper curve corresponds to the UMDA in which services are added until the SCP is finished. When solved, all services whose features are already covered by other services used are dropped. The lower curve corresponds to the GA in which at each iteration, the SCP is solved but favours those with less services. Thus, services used follow a downward trend as the algorithm proceeds.
243
The fourth step, combination of components, will initially be done manually through the help of a graphical tool that will allow to define the input/output flows and to interpose data transformation filters. Later on, the composition will be made automatically, making use of the information in the SBVR models, as the body of shared knowledge will contain all reasonable data transformations and logic reasoning on the semantical descriptions can provide the remaining transformations and flows needed. For the composition to happen, an appropriate linkage between an SBVR model and the actual services provided has to be defined. For example, the SBVR description of a hotel should have reference to the computational services for checking the availability of a room, getting a rate and booking a stay. The last step, implementation of components by software developers, can be assisted by diagrams and code generators that make use of the semantic information of the SBVR models. The same technology can be used to provide the glue code binding components, including the adaptation layers for appropriately transforming the data depending on the context of instantiation of the component. In the next section we will sketch how such generators could be implemented and how they could be symmetrically used to keep the software specification synchronised with the implementation.
4
Code generations
It is envisioned that the progress of research and tools for digital ecosystems will eventually reach automatic code generation to satisfy any software specification given in structured natural language. For this to happen, there is the need of a solid foundational theory for digital ecosystems that takes into account interactive computation aspects. Until recently we would have proposed a combination of λ-calculus, a foundational theory of algorithmic functions (Barendregt, 1984) and π-calculus, a model for processes interactions (Sangiorgi and Walker, 2001), but a new formalism is starting to gain consensus among researchers as the new paradigm for computation (Wegner, 1998; Goldin and Wegner, 2005). This formalism takes the form of a modified Turing machine, called ‘persistent Turing machine’ that is able to take into account interaction with the environment during the computation. The digital ecosystem theory can build on top of an interactive computation model. Specifications and implementations based on these models are easily achievable and already being implemented: as an example, the web services choreography description language by the W3C consortium is based on π-calculus (Kavantzas et al., 2005).
244
G. Marcon et al.
Figure 6
Research steps toward the achievement of code generation: single service consumption, services composition, services adaptation and automatic code generation (see online version for colours)
code (see Figure 7). Generating UML class diagrams from SBRV models is a jump of one step in the MDA (from CIM to PIM), while generating code is a jump of two steps (from CIM to PSM). Unfortunately, a UML class diagram does not carry enough information for code generation: it would need thus to be annotated or to be used in conjunction with the original SBVR models for this aim. Figure 7
Generation of UML class diagrams and code from SBVR models
Once a foundational theory is established, the following research and implementation steps are necessary (see Figure 6): •
Single service consumption: This step has already been achieved as the basic functionality of every SOA. It consists of the ability to consume distributed services in a transparent way.
•
Selection of services for composition: Given a software request (in the form of a software specification), finding the best combination of services satisfying the request is an optimisation problem. Architecture for this optimisation is currently being developed3. This architecture makes use of a two-fold optimisation: a ‘local’ one, based on GAs that searches for an optimal combination of known services and a ‘distributed’ one, based on neural networks that diffuse information on services to peers that can take advantage of them.
•
Adaptive service generation: Once an optimal combination of services is known, the first step for automatically combining them is to adapt their interfaces so that they can interact properly. Adaptation is defined as data transformation and use of input from the environment. For instance, combining a plane ticket booking for a particular destination with a car rental booking once the plane arrived for a particular user would create a service where the customer data are already filled out (known from the environment) and the arrival information is passed on automatically to the car rental booking service.
•
Code generation: The adaptive service generation concept already provides basic functionalities for creating choreographies of services. These functionalities can be extended further up to a completely automated creation of executable service combinations. This will foster the creation of reusable services that will consequently focus on specific functionalities and provide a rather loose interface with an extremely rich semantic description. Thanks to this ‘cloud of components’, every software request will be eventually satisfiable just by what is present in the overall system.
These steps can seem more visionary than they actually are: it is not so unconceivable to think of transformations from SBVR models to UML class diagrams or even directly to
The example in Figure 7 shows how an SBVR statement (in this case the definition of a ‘characteristic’) can be transformed into code: the characteristic ‘being international’ pertains to the concept ‘car movement’ and thus will be represented in the class corresponding to that concept (‘CarMovement’ in our case). As the characteristic has cardinality two4, the method will return a Boolean and will be called ‘isInternational’, following the standard getter syntax for Boolean values. The return value of the method can be the content of the private field ‘international’ in the class ‘CarMovement’ if no executable definition is provided. In this case, the definition can be implemented: using a transformation from the logical proposition provided in the definition to code, we can generate a statement checking that the two fields ‘sendingBranch’ and ‘receivingBranch’ are different. Other possible transformations include: •
Business rules to UML activity diagrams: The semantic information contained in business rules can be used to generate UML activity diagrams. A UML activity diagram together with a UML class diagram would represent most of the information an implementer needs to generate the system. If appropriately annotated, it could be used to automatically generate the code or most of it with tools like the IBM Rational Suite or MagicDraw from No Magic.
•
Business rules to xUML diagrams: SBVR business rules could also be transformed into xUML programs. Some steps toward this direction have been done but further research is needed (Schacher, 2006; OMG3, 2005).
Software engineering within a dynamic digital business ecosystem Transformations from SBVR models to other models, more common to software engineers, can be done consistently through a systematic approach. The models involved in the proposed transformations have all a MOF model. Transformation among MOF models can be defined formally by means of a suitable language like ATLAS5 (Jouault and Kurtev, 2005). ATLAS has been developed in response to an OMG request for proposals on query/views/transformations in the MDA and allows to formally defining transformations among MOF models (OMG2, 2007).
5
245
software: this is the inverse direction of code generation that is commonly called ‘reverse engineering’. Model inference makes sense in particular when modifications are done on the generated code that contains annotations with references to the original model. These modifications can then be used to automatically adapt the model/specification (see Figure 8). Figure 8
Re-adaptation of software specification after change requests are directly implemented
Synchronisation of specification from adapted software
There are several reasons for maintenance of software: for implementing requirements that were missing in the original analysis, for the correction of incorrect behaviours, or to adapt to changes in the organisation and/or processes. In spite of the great availability of theories, models and systems for change management processes, these adaptations of the process rarely pass through the whole software engineering process (Rajlich, 1999). Many changes in fact are not cross-cutting through different parts of the system/company and are implemented directly at a lower level. Good change management procedures suggest that each change should follow a precise path: a change request is first issued, it is then analysed and evaluated to be consequently planned, implemented and finally verified. A system that is not updated becomes less useful, reducing its cost-benefit performance. Changes in software systems are thus extremely relevant, also from the financial point of view: it has been estimated that an enterprise resource planning systems maintenance costs yearly around 25% of the initial costs (Ng et al., 2003). We believe that SBVR to models generators would help in decreasing these costs. Several subsequent changes on the system have the undesired property that they augment the architecture complexity and often reduce usability. Simplifying and reengineering the architecture to properly abstract the changes that were not considered in the risk analysis often requires more effort than implementing the changes themselves. A model-driven approach based on SBVR should help in making a thorough risk analysis and in keeping the system easily adaptable. In many cases, companies do not follow a proper change management practice resulting in deployed software that does not correspond to the original specification anymore. This is true in particular for changes in the orchestration of components. Business models, including business rules descriptions, are then not connected anymore to their actual implementation, implying that the ‘practice’ is not anymore in line with the ‘theory’, with all the related risks. Exploiting the capabilities of the digital ecosystem and SBVR, it is possible to automatically synchronise a software specification from modifications done to the annotated
This approach is very similar to ‘round-trip engineering’, where source code and its model are kept in synchronisation. In common practices, round-trip engineering is used in the following way: 1
source code is reverse engineered to UML diagrams
2
re-factoring or other software engineering processes are applied to the models
3
the code is generated from the models.
As presented, we consider the reverse path more useful with SBVR models for the following reasons: 1
an SBVR model is created
2
the corresponding UML models and source codes are generated and modified
3
the original SBVR model is updated.
Clearly, also generating an SBVR model from code or UML models would be feasible but we guess that it would result in a very poor and unnatural specification, as it would probably not carry business meaning but only its computational implications. This is true in particular for obligation business rules that can be implemented in different ways (or they can actually not be enforced at all through code). A possible application of SBVR round-trip engineering is for contracts among companies; SBVR is a perfect and fair way to write a contract as it is unambiguous. In this sense, round-trip engineering can be used to verify that the contract is still honoured or to update it to reflect current practices and conditions. Another example is for quality control: an implementation of an SBVR model could consist also in an internal work flow of a company: a work flow that has changed can be verified against the quality control specification or can be used to update the specification. A clear example of the improvement of transparency and fairness in the use of SBVR round-trip engineering is the usage of tacit business rules with customers. Common customer handling processes are usually specified by internal rules that do not correspond to contractual terms. In the car rental sector for instance, a common unofficial rule
246
G. Marcon et al.
is in use when a customer brings in the rented car after the expected drop-off hour without notification: some hours are usually allowed without any consequence, while after that the competent authorities are notified of car theft. Another case is that of utility providers offering yearly contracts: a premature termination of the contract is allowed by paying a percentage of the amount due. These rules are never specified in contracts, empowering the companies offering the services and abusing the customer rights. SBVR modelling would enforce making these rules explicit and possibly public, leading to non-discriminatory contractual arrangements.
6
Conclusions
We have shown that the use of SBVR can promote a more responsible software engineering practice where the software documentation and specification is always up to date with the implementation. With its use of unambiguous natural language, SBVR provides a stronger link for end user with the software development process. Additionally, software developers’ efforts are relieved by the digital ecosystem enhanced SOA, thanks to its strong MDA approach and to the automatic code generation capabilities. Using the ideas of SBVR, the digital business ecosystem and code generation, we have shown how these can be combined to create a powerful tool. With the use of components and companies dispersed in the digital business ecosystem, we can combine their different uses to ultimately have a system where code generation takes place automatically for any software specification and with the use of the natural language in SBVR open to those not directly in the software development domain. We also suggest the research and implementation steps to achieve a full fledged digital ecosystem making use of current technologies and standards, mainly SOAs and natural language based business modelling. The research directions suggested here are compatible with those of the ‘digital ecosystems’ cluster of projects of the European Union. Two projects in particular, the ‘digital business ecosystem’ integrated project and the ‘open philosophies for associative autopoietic digital ecosystems’ network of excellence, will pursue these lines of research.
Acknowledgements This work was funded in part under the European Union’s 6th Framework Program contracts No. 507953 and No. 034824.
References Barendregt, H.P. (1984) The Lambda Calculus: Its Syntax and Semantics, North-Holland, Amsterdam. Beasley, J. and Chu, P. (1996) ‘A genetic algorithm for the set covering problem’, European Journal of Operational Research, Vol. 94, pp.392–404.
Boyd, N. (1999) ‘Using natural language in software development’, Journal of Object-Oriented Programming, Vol. 11, No. 9, pp.45–55. Carasik, R., Johnson, S., Patterson, D. and Von Glahn, G. (1990) ‘Towards a domain description grammar: an application of linguistic semantics’, ACM SIGSOFT Software Engineering Notes, October, Vol. 15, No. 5, pp.28–43. Erl, T. (2005) Service-Oriented Architecture, Concepts, Technology and Design, Prentice Hall, Crawfordsville, IN. Feige, U. (1998) ‘A threshold of ln n for approximating set cover’, Journal of the ACM, Vol. 45, No. 4, pp.634–652. Frankel, D.S. (2003) Model Driven Architecture, Wiley Publishing, Indianapolis. Gallier, J.H. (1986) ‘Logic for computer science: foundations of automatic theorem proving’, Harper & Row Computer Science and Technology Series, Harper & Row. Garey, M.R. and Johnson, D.S. (1979) Computers and Intractability: A Guide to the Theory of NP-Completeness, W.H. Freeman. Goldin, D.Q. and Wegner, P. (2005) ‘The Church-Turing thesis: breaking the myth’, in Benedikt Loewe S., Barry Cooper and Leen Torenvliet (Eds.): CiE of Lecture Notes in Computer Science, Springer Berlin/Heidelberg, Vol. 3526, pp.152–168. Halstead, M.H. (1977) ‘Elements of software science’, Operating and Programming Systems Series, Elsevier Science Inc., New York, USA. Heistracher, T., Kurz, T., Marcon, G. and Masuch, C. (2006) ‘Collaborative software engineering with a digital ecosystem’, in Proc. International Conference on Global Software Engineering, Costão do Santinho, Florianópolis, Brazil, October, pp.119–126. Henkin, L. (1950) ‘Completeness in the theory of types’, Journal of Symbolic Logic, Vol. 15, pp.81–91. Jouault, F. and Kurtev, I. (2005) ‘Transforming models with ATL’, in Jean-Michel Bruel (Ed.): in Proceedings of the Model Transformations in Practice Workshop at MoDELS, Montego Bay, Jamaica, Springer Berlin/Heidelberg, October, pp.128–138. Karp, R.M. (1972) ‘Reducibility among combinatorial problems’, in R.E. Miller and J.W. Thatcher (Eds.): Complexity of Computer Computations, Plenum Press, pp.85–103. Kavantzas, N., Burdett, D., Ritzinger, G., Fletcher, T., Lafon, Y. and Barreto, C. (2005) Web Services Choreography Description Language Version 1.0, November, available at http://www.w3.org/TR/ws-cdl-10/, candidate recommendation. Kurz, T., Marcon, G., Masuch, C. and Heistracher, T. (2005) ‘A network of SMEs for competitive services’, in Proc. Managing Global Trends and Challenges in a Turbulent Economy. Lund, C. and Yannakakis, M. (1994) ‘On the hardness of approximating minimization problems’, J. ACM, Vol. 41, No. 5, pp.960–981. Mhlenbein, H. and Paa, G. (1996) ‘From recombination of genes to the estimation of distributions i, binary parameters’, in H-M. Voigt, W. Ebeling, I. Rechenberg and H-P. Schwefel (Eds.): Parallel Problem Solving from Nature, Vol. 4, pp.188–197. Nachira, F. (2002) ‘Toward a network of digital business ecosystems fostering the local development’, Discussion paper, September, available at http://www.digitalecosystems.org/doc/discussionpaper.pdf.
Software engineering within a dynamic digital business ecosystem Ng, C.S., Gable, G. and Chan, T. (2003) ‘An erp maintenance model’, in Proceedings of the 36th Annual Hawaii International Conference on System Sciences (HICSS’03) – Track 8, pp.234.2, IEEE Computer Society, Washington DC, USA. OMG1 (2006) Semantics of Business Vocabulary and Business Rules Specification, First interim specification, March, available at http://www.omg.org/docs/dtc/06-03-02.pdf. OMG2 (2007) MOF Query/Views/Transformations Specification, Final adopted specification, July, available at http://www.omg.org/cgi-bin/apps/doc?ptc/05-11-01.pdf. OMG3 (2005) Semantics of a Foundational Subset for Executable UML Models, Request for proposal, April, available at http://www.omg.org/docs/ad/05-04-02.pdf. Rajlich, V. (1999) ‘Software change and evolution’, in J. Pavelka, G. Tel and M. Bartosek (Eds.): SOFSEM ’99: Proceedings of the 26th Conference on Current Trends in Theory and Practice of Informatics on Theory and Practice of Informatics, Springer-Verlag, London, UK, Vol. 1725, pp.189–202. Saeki, M., Horai, H. and Enomoto, H. (1989) ‘Software development process from natural language specification’, in ICSE ’89: Proceedings of the 11th International Conference on Software Engineering, ACM Press, New York, USA, pp.64–73. Sangiorgi, D. and Walker, D. (2001) The π-Calculus: A Theory of Mobile Processes, Cambridge University Press. Schacher, M. (2006) ‘Moving from Zachman row 2 to Zachman row 3: business rules from an SBVR and an xUML perspective’, Business Rules Journal, June, Vol. 7, No. 6. Sowa, J.F. and Zachman, J.A. (1992) ‘Extending and formalizing the framework for information systems architecture’, IBM Systems Journal, Vol. 31, No. 3, pp.590–616. Wegner, P. (1998) ‘Interactive foundations of computing’, Theor. Comput. Sci., Vol. 192, No. 2, pp.315–351. Zachman, J.A. (1987) ‘A framework for information systems architecture’, IBM Systems Journal, Vol. 26, No. 3, pp.276–292.
Notes 1 2
3
4
5
Unisys Rules Modeler by Unisys Corporation, http://www.unisys.com/businessrules/. SBeaVeR – Business Modeller by the e-Business Management School Department of the Institute for Advanced Interdisciplinary Studies at the University of Lecce, http://sbeaver.sourceforge.net/. In the Digital Business Ecosystem project, funded under the European Union’s 6th Framework Program, Contract no. 507953, http://www.digital-ecosystem.org/. ‘being’ implies that it can be or not be in a closed world interpretation of the logic statement, while in an open world interpretation could also assume the value of ‘maybe’. http://www.sciences.univ-nantes.fr/lina/atl/atlProject/.
247
