Model-Assisted Software Development: Using a 'semantic bus' to automate steps in the software development process
Review 1 by Axel Polleres:
This vision paper proposes to use domain knowledge and ontologies for software engineering and system design process both in terms of business knowledge and technical design patterns. The paper proposes the general concept of a "semantic bus for software development" and how it could assist different pahases of software development.
I like the posed problems which give rise to interesting research in this ares. I would suggest a more comprehensive overview of starting points/related work. I think that these position papers in the first issue of SWJ should not only discuss visions and challenges, but also strive to give interested researchers who want to pick up those challenges the necessary entry points, not necessarily restricted to the author's own work.
Detailed suggestions and also some smaller editorial issues below:
*
"Given the complex, knowledge driven nature of the work in these phases, it is strange to see that there are hardly any commercial tools that support the use of semantic models for the specification and design of enterprise systems."
is it really "strange"? I wouldn't call it "strange", people just don't know these technologies well enough, they aren't mainstream, I'd reformulate this a bit, e.g. just:
"Despite the complex, knowledge driven nature of the work in these phases, there are hardly any commercial tools that support the use of semantic models for the specification and design of enterprise systems."
*
"we envision a tool that will automatically detect gaps and conflicts among re- quirements and enable complex tasks such as estimation and impact analysis."
[...] later on
"For instance, a business analyst is asked to create a well-structured, natural langue requirements specifi- cation."
Will need NLP technology, ontology extraction (lots of work around in thes areas some of which should be cited, to give the interested reader pointers).
*
in synch
->
in sync
*
You mention "models for representing the artifacts produced by the various phases of software engineering." I suggest following recent, successful models for creating lightweight ontologies, e.g. the FOAF or SIOC projects. Identifying small core onotlogies has in these areas enabled tools and useful applications, although those ontologies consist only of a handful of concepts and properties. I think it would be helpful to start with some small core ontologies could also be a useful approach here.
* How do you envision to implement the "the semantic bus for software development" ? It is a nice metaphor, but what real tools do you envision on top of it? It would be nice if you gave a concrete example of such a tool,
how you envision them to work... or (How) can concrete existing tools benefit from it?
along these lines, e.g.
"One example would be an ontology that describes the typical decision points in the Apache Axis Framework."
It would be nice to make this example more concrete/tangible. I (and probably) many other readers don't know which decision points there are in this framework. Also, a reference would be good.
* A basic reference for MDD for the non-software-development semantic Web guys would be nice.
* "A human, skilled one space [...] uses MDD tool to create [...]" -->
"A human, skilled *in* one space [...] uses *an* MDD tool to create [...]""
* "System automatically performs a trans- form on parts of that model to generate artifact in downstream space (such as design)." --> "The system automatically performs a transformation on parts of that model to generate artifacts in downstream space (such as design)."
* "Another human, expert [...]" --> "Another human expert" (no comma)
just guessing here with the suggested reformulations, basic point: the bullet points are too "keyword-style", not really English sentences.
* As for related works: Note about projects on the support of semantic Web technologies for software design, such as: http://www.ict-romulus.eu/web/romulus (just finished) or related work in the s.e.a.l. group in Zuerich, http://seal.ifi.uzh.ch/ e.g. cf.: Harald C. Gall, Gerald Reif, ICSE 2009 Tutorial - Semantic Web Technologies in Software Engineering , 31th International Conference on Software Engineering (ICSE 2009), May 18 2009
* "In spite of years of research in this area," [...] "As with requirements, there is some previous work in this space," ... see above, would be nice to add more references.
Review 2 by Krzysztof Janowicz:
This is a very interesting topic and I fully agree with the authors that classical tools for software engineering have been developed with coding support in mind rather than supporting developers in creating domain specific models, sharing, and reusing them. I think this work aligns well with the work on ontology design patterns, see e.g., the work from Aldo Gangemi.
As the paper is only 4,5 pages I would propose to add some more details about the developed tools - such as RAT and ProcGap. Moreover, I would also like to see some more discussion on information versus knowledge which is very important in terms of re-usability of domain models.
'it is strange to see that there are hardly any commercial tools that support the use of semantic models for the specification and design of enterprise systems.'
--> There are some, e.g., see Uschold's work on "Ontology-Driven Information Systems: Past, Present and Future" from FOIS 2008 in which he discusses challenges, presents recent tools, and introduces an agenda for ontology driven (system) development. How does this work align to the proposed BUS?
'First, the practitioners in an area such as requirements often find thinking in terms of a formal modeling notation very unnatural. Business Analysts, for example, are used to writing sentences, not creating models. Furthermore, the stakeholders who must sign off on these requirements are used to reading sentences, not model diagrams. [...] For instance, a business analyst is asked to create a well-structured, natural language requirements specification. The structured model of the requirements is automatically generated by analyzing the requirements text. The model then lives alongside the human-generated document, and automatically kept in synch. The text document is used by human analysts and stakeholders, while the model is available to support automated reasoning, and generation of downstream transformations.'
--> IMO, this is the crucial and probably also most difficult step and I would love to read some more details about it. The users, domain experts, and developers do not speak a common language and therefore it is difficult to ensure that the final product, e.g., an ontology used during the requirements analysis, meets the initial conceptualization of the users or domain experts. NLP will only be of limited use here as even small modeling decisions on the ontological level may have a critical impact on further reasoning and so forth. We addressed this challenge in a paper for FOIS 2008 called 'Similarity as a Quality Indicator in Ontology Engineering'. While it only covers some aspects, it may be a first step towards quantifying these differences in conceptualization.