The Potentials of Software Recycling using Semantic Web Technologies.doc

the potentials of software recycling using semantic web technologiesphilip tetlowibm global business sabstract the following paper presents an informal positioning discussion on how semantic web technologies can be applied in the area of software recycling; also known as legacy software modernization. it focuses on the challenges and potential rewords associated with this field and outlines the attraction of axiomatic data representation (as can be implemented with semantic web languages) for use in implementation agnostic software transformation practices.keywords: legacy systems, transformation processes, canonicalised data representation, software assets, axiomatics, systems and software complexity.1 introduction for some considerable time the automatic transfer of knowledge into software has proved a tantalizing possibility, but a reality too far. traditional software engineering is concerned with the specification, design, coding, testing and maintenance of software. it also implicitly deals with the issues of transforming real-world knowledge into software in the sense that gathering knowledge about a problem domain is incorporated in the requirements analysis stage of the software life cycle. often informal knowledge acquisition techniques are used, but the valuable semantics extracted are poorly represented from that point on. nevertheless the struggle with semantics goes on much deeper into the software life cycle. it is often forgotten, fir example, that when software designs, or the actual software itself, is eventually realised, it has to contain a wealth of meaning by default or else it will not serve its ultimate purpose. yet still methods for dealing directly with semantics are thin on the ground in traditional software engineering circles.the importance of knowledge and semantics in software is paramount. as kurt gdel showed in 1931, all formal expressions can be treated as natural numbers and by such a token both data and functionality can be considered as being mathematically the same, singularly being just information masquerading under different types. although we might pretend differently, the process of computation is really one of pure mathematics, so, in truth, every computation basically represents the mathematical interplay of information through various patterns. it is all about automatic acquaintance with facts, truths, and principles. it is the mechanization of knowledge, and knowledge is nothing without meaning. the significance of pattern in software is also often underplayed. from a purely compositional persecute, software can be thought of as patterns linking information of one form to another. patterns themselves implicitly contain semantic detail by their very position and structure. a program is constructed from some basic patterns, and the constitution of rules can in turn be expressed as other types of pattern. with grammars, formal languages and automata there are many ways to describe these patterns and how they might be compounded into useful systems of data and software. indeed even natural language itself can be thought of in terms of pattern, although the rules needed to extract meaning from everyday pros are many time more complex than those necessary for common software.recent years have seen significant pressure to increase technical capabilities in the area of rigorous information semantics. in particular the rise of the world wide web has seen quantities of publicly available computer-based information that could never have been imagined before. just cataloguing this complex volume has proved an almost insurmountable task, requiring radically different methods for both information retrieval and information management. to assist with the problems the world wide web consortium (w3c) started the semantic web initiative to create a web-friendly medium for information exchange using documents with computer-processable meaning .the semantic web embodies the concept of a network of actionable information information derived from data through a semantic theory for interpreting symbols. this provides an account of meaning in which the logical connection of terms establishes interoperability between systems. this was not a new vision. tim berners-lee articulated it at the very first world wide web conference in 1994, but it has taken since then to make it a reality.in the early days of the semantic web efforts predominantly focused on the expression of meaning in domain specific knowledge bases; smaller sub-webs more formally referred to as ontologies. these were intended to link together concepts and web resources (typically web pages) in areas like the life sciences or drug therapy. it was not until some time later, in around 2002, that software engineers began to realise the potentials of using semantic web technologies. hence both the w3c and the object management group (omg) both now run activities intended to bring together the semantic web with good software engineering practice. in fact the semantic web provides an ideal partner for software engineering. source code and a significant proportion of design schematics have always been captured in some form of machine readable document. furthermore the semantic web is all about the linking of information to create something more wholesome, as is all software. given the vast volume of code that has been written across the planet to date, this implies that an enormous treasure trove of experience and capability is frozen out there, waiting to be rediscovered and reapplied. however, there is an unfortunate problem for those who wish to partake in the treasure hunt using conventional means.in most cases, rather then being seen as an asset, the knowledge contained in software or its design documentation is deemed to have lost its luster. this is not because it has depreciated in any meaningful way, but rather it is because:the personal expertise needed to extract and understand it was never documented in the first place, has moved on with the personnel who engineered it , orbeen replaced by those with knowledge of more up to date programming languages. to be frank, the decline of old software is taking an awful lot of invaluable business knowledge with it. if one could find ways to automatically extract the knowledge locked in existing software or its designs, then agnostically analyze and transform it back out into more contemporary and useful forms, then surely the dream of automated software engineering would be much closer? this paper hence discusses the opportunities for software recycling using a mixture of semantic web technologies and acknowledged software engineering practice. 2 the underlying problemsmodern historians often like to talk about the phenomenal rise of it and freely associate it with an accelerated advancement in most fields of human endeavour. even so, if one were to step back from this whirl of technology growth, significant irony can be found. it is certainly true that computing has enabled great advances in mankinds capabilities, but in doing so it has also created its own self-perpetuating cycle - the more change achieved, the more change expected, the faster the pace of change, the greater the accelerated growth of expectation. nowhere is this problem more profound than in the commercial arena. the capability to achieve change quickly has led to modern businesses needing to be agile, accurate, coordinated and exceptionally well informed merely to survive. businesses wanting to create and maintain a competitive edge have to go further and demonstrate an extreme flexibility and quick-wittedness; a capability psychologically unnatural to most individuals and almost near impossible to sustain in social groups larger than a handful. yet many organisations still have to face this reality daily, with thousands of employees, dispersed across multiple continents all trying to work to an ever-changing set of agendas. no wonder that so much reliance has been placed on it in recent times. as is always the case, however, the real help provided by it is not without its problems. by enabling ever increasing change, the systems required to support human expectation have become larger and more complex in tandem with their increasing maintenance overhead providing an a substantially greater burden. it really is a case of icebergs chasing their own personal titanic and the bad news is that collision time may well be just around the corner. feeding the fire of change is now starting to become a real problem for the it industry. unless we start to do things differently, systems complexity and pace of change will soon start to outstrip the very limits of mankinds natural potential. we are quite simply starting to become the weakest link in our own processes of innovation and change2.now new approaches are needed to accommodate our accelerating expectations. many organisations can no longer afford the time or the cost of custom development projects to service requirements each time their business changes. so they have turned to the growing trend to buy commercial off-the-shelf (cots) packages and attempt to integrate them with existing systems instead. but there are still weaknesses with this alternative. when approached incorrectly, as is unfortunately all too common, cots implementations can be just as cumbersome as full custom builds. this can be for a number of reasons, but is frequently due to incomplete requirements capture and poor communication essentially the human element of the process breaks down yet again. in simple terms there really is only one answer increased automation of the change process itself.3 software reapplication not reuseto quote the software engineering pioneer grady booch: “software development has been, is, and will likely remain fundamentally hard. to that end, the entire history of software engineering is one of rising levels of abstraction - for abstraction is the primary way we as humans deal with complexity - and we see this reflected in the maturation of our programming languages, platforms, processes, tools, and patterns. indeed, every well-structured software-intensive system is full of patterns, ranging from idioms that shape the use of a particular programming language to mechanisms that define the collaboration among societies of objects, components, and other parts.”this quote is indeed profound for it not only highlights the major successes of software engineering to date. it also alludes to one of its most fundamental mistakes; software engineering is still primarily interested in the engineering of software! this statement may appear sublime to the point of being ridiculous, but if you think about it properly it makes a great deal of sense. in recent years we have achieved competency at levels of technical abstraction far removed from the point where the cutting of program code is key. today we not only understand the value of patterns in software, but we are also able to rise further and employ richly semantic metapatterns and inference logics to extract such structures from raw software itself. once you realize that the grammar of any source codes language is merely a pattern itself, it soon becomes apparent that a shift of emphasis is not only relevant, but that the old dream of automated software engineering is now within reach. furthermore if you accept that most of the software we will ever need has already been written, then a number distinct and significant opportunities in software re-engineering start come to light. no longer is there an overriding need to diligently hand craft software from scratch. in fact there is distinct advantage in taking the engineer directly out of the equation. no more need we be retarded by our own foibles as designers and programmers, now the key is to find suitable donor software and transplant its virtues into new systems in such a way as best fits ongoing requirements. quite literally the future of software engineering lies with specification, discovery and automatic transformation based around semantics and pattern; not design and construction based on individual engineering expertise and effort.this is not software reused in the strictest sense, it is more the capability to automatically recognize, extract and reimplement the underlying characteristics of existing software implementations, warts and all if necessary a kind of software recycling if you like. implicit to this is the need to store such characteristics in a suitably independent and expressive manner. this has been a problem for software engineering in the past, as expressivity demands rigorous semantics and technologies with sufficient capabilities have been rare until recent times. with the advent of new xml-based technologies like rdf and owl, however, this deficiency is fortunately being more than adequately addressed and a way forward for true software reapplication has now been opened. 4 the increased availability of new software technologiesone of the unfortunate realities in computing has always been the fact that the software implementations we believe to be relevant today will probably not be tomorrow. most certainly the technologies of yesterday serve as platforms to climb higher, but the more experienced we become with technology, the more rapid and far reaching the pace of change becomes. not only are we regularly faced with upgrades, but these soon gang up together to create complete diversions of approach. paradigm shift is awful phrase, but the history of computing is littered with such occurrences. the problem is that paradigms can be as implicit as a set of assumptions, a part of our modus operandi as individuals, as groups or as a complete profession. by the time specifics have emerged, been documented and ratified as standards they are usually well behind the current wave of innovation. their very being therefore threatens the life expectancy of any implementation using them. so there is always a need for nervous immediacy with their arrival. take the recent emergence of service oriented architecture (soa), and in particular the fashionable trend for web services for instance. both are of real benefit to the software engineering community, but there are still few recognized yard sticks available to suggest how they might be realized properly. furthermore, as soon as proper guidelines do emerge, old fashioned engineering practices could undoubtedly cause dangerous delays between their publication and eventual real world use. the term guideline is, of course used loosely here. what we are really taking about is the emergence of recognized patterns for implementation, be they expressed in terms of a new programming language, communication protocol, systems architecture or whatever. nevertheless, express their underlying semantics in an appropriately machine readable form and they can very quickly become parameters for use in an automated engineering process. this obviously helps remove the chances of implementation latency and further rewards with the advantages of improved software quality and reduced labour overhead. 5 are lemmings really philosophers?two zoologists stand at the foot of a cliff, bemused by the vertical torrent of lemmings streaming to their death before them. “why do you think they do that,” asks one to the other, “surely they can see the edge of the cliff?” “maybe they can”, replies his friend, “but perhaps they just dont understand what an edge is in the first place.” this anecdote may appear misplaced when discussing the fineries of software engineering, but when considered in a little more detail it can be seen to cut right to the heart of one of the biggest problems in the software construction industry today.engineers of all kinds tend to be an easily mislead bunch. this is not because of some weak personality trait, but rather is a consequence shallow teaching. at the end of the day, engineering its nothing more than the pragmatic application of scientific principles and for those who choose to study conventional computer science, the world is often portrayed as a safe and dependable place. for them, their comprehensions are based on fundamentally discrete simplicities. george boole and alan turing showed the world a set of realities that were that way when they laid down their thoughts on algebraic rules and computability and thus pointed the way forward for the modern digital revolution. ordinarily such understandings are sound and practical, but it would be a miscalculation to cling to them in the hope that all computation can be neatly pigeonholed. in fact all science is just one huge paradox; very rarely can absolutes ever be found in any field we choose to label under this heading. yet still science relies on an abundance of such absolutes for its very existence. this problem is compounded further when extended to real world application through engineering. here measurable certainties form the very substance from which entire disciplines are formed. after all if you were to build anything and then were not able to understand it via accurate measurement, how could you ever know if that thing were as intended?but still one of the great things about science is its assumption that what it thinks it knows today will probably be proved wrong tomorrow. in all fields of science the real lesson to be learned is that truth is merely a transient property, retaining its respect only until the moment that a better truth comes along. and even when truth appears absolutely unquestionable there are always subtleties of definition, interpretation and application to take into account. this is not the only reason to be pessimistic. if there were any absolutes in our world then they would probably be horribly self-reflexive