Software quality model, quality measurement
Bad smells, antipatterns, technical debts
Software patterns, design patterns, requirements patterns
Software evolution and maintenance
Application of machine learning and natural language processing in software engineering
User interface and user experience design
1. Evolution Transparency for Distributed Service Types
I have done work on evolution transparency for distributed service types in my PhD years. It is about providing evolution transparency for clients in a distributed environment when the interface of the service they use has evolved. The problem is the new service interface is not recognised as compatible by the type system of the underlying distributed architecture although the new service version still preserves the original functionality somehow. In this situation, those clients are required to change their programs and this is something very difficult to do in a distributed environment since the clients can be dispersed and there is no record of all the users of the changed service. Also, those clients are autonomous and may not want to evolve themselves if the old service has been sufficient for their operation. It is also the case that client conversion cannot be conducted immediately. I propose a mediator object called a mapping operator as an ad-hoc support for the clients. This mapping operator will intercept old-version requests from old clients, transform them into new-version request before forwarding them to the new-version service. To do that, the mapping operator requires a set of mapping functions from a human evolver. The mapping functions describe how to map the request in one format into the other. This mechanism is useful as it allows clients to continue using the old service until they are ready to evolve. This work has been implemented on ANSAware which is compliant with the RM-ODP distributed architecture standard.
2. Change Management Supporting Environment
Support for Service Providers. In a distibuted environment, it is possible that several service providers instantiate their own service objects from the same predefined service interface to reflect different implementations, different detailed functionality, or different groups of users of that service. I assume that when a service interface is changed (abstraction is changed), all of its instances should be changed too. Then, we require a system that can track down where all the instances of the changed interface are so that we can notify the providers who are responsibility for the operation of those instances to evolve them accordingly. This task may be helped by the naming service if those instances are registered with it. Also, the notification should cross network boundary as now there is much effort on standardising interfaces of the services used in specific application domains (e.g. CORBA Domain Facilities). With such effort, no matter where the instances of the services of a particular application domain are, they should conform to the same standardised interfaces. This means we may assume that the change in an interface may affect instances of this interface in several subnets so our notification system is will work across subnets too. This work has been implemented on CORBA platform.
Housekeeping System. This small piece of work directly relates to my past research on the mapping operators. We develop a system that can clear up the mapping operators that will no longer be used when all the old clients of that particular version have all evolved. (It will cooperate with the monitoring system for clients below) Basically, the system will check the idleness of each mapping operator object and destroy it if it reaches some predefined time threshold. The clearup also involves clearing the equivalence information retained by the type repository and its entry in the directory services. This work has been developed on CORBA platform.
Support for Clients. We start with the development of a notification system for clients to subscribe for change events of services in which they are interested. The system adopts CORBA notification service to filter change events and inform clients involved so that they can take appropriate action for the change. This notification system will support both push and pull model. This work is done on CORBA platform.
3. Information Integration
Schema integration in object-oriented databases. This work is different from other topics but yet somehow relevant. Schema integration is one aspect of object interoperability. If there are two database schemas and we want to integrate them into one global schema, we must know how similar they are and how they can be related. We improve the methodology for schema integration by using heuristics, richer sets of semantics, and richer analysis of class relationships.
Ontology integration for enterprise information. Ontologies can be used to annotated semantics to each piece of information within an enterprise. To provide an integrated view for every piece, an ontology integration algorithm will be developed to integrate those pieces together based on their semantics. This will be a basis for development of a framework that supports integration and query of multiple data sources within an enterprise.
4. Equivalence-Relationships-Supporting Type Repository
I see those mapping functions I used in my past research as a concrete instance of equivalence relationships. That is, one object of an interface can create an illusion of (i.e. can be made to behave like) another object of another interface as long as some set of behavioural mapping functions can be defined. I think if we extend the type repository of a distributed system with such equivalent information, then we can make service selection more flexible, e.g. when a trader realises this equivalent relationship, it can select equivalent service to substitute for the requested service and then we can have a mechanism that will enable client invocation to this equivalent service transparently. This work is done on CORBA platform.
5. Enhancements to Discovery Service
Bringing Out Information to the Internet. As a CORBA trader is resourceful for information on available services, it should not be restricted to a particular underlying distributed architecture. We make service descriptions (service types and service offers) in a trader easier to access and use in other environment like the Internet by transforming them into XML.
Clients’ acquisition of knowledge on services. Current models on service selection are based on prior knowledge of the client on the service to be used. That is, the client is assumed to have known the service type name it is requesting. With this information, the trader trades an appropriate instance of the named service and the client programs are then written to invoke such instance either statically or dynamically. What is lacked and unclear in this model is the acquisition of the knowledge of the service types. It is at the moment assumed that the trader admin will distribute the catalogue of the services available in that trader to all the users in its domain so that the users can study the functionality of all available services and later can trade for the specific service it requires. This work aims to make the acquisition of the knowledge on available services more systematic and automatic by registering more information on the behaviour of a particular service with the trader. The client will offer the trader with some kind of requirement specification that it desires. This specification will be compared with the specifications of the services in the trader and the results are the names of the services that might suit the client’s requirement. This work is done on CORBA platform.
Framework for federation contracts negotiation and modification. We define a template for import/export contracts for federated traders. With the standard template, the process of negotiation to set up the contracts as well as their modification can be more automated by the traders.
Service description templates. There has been a survey on the current status of component software vendors and component software descriptions on the Internet. It is seen that the result from this survey could help identifying templates for service descriptions in a trader. The templates generally specify what properties the service providers should describe their services. The templates can be classified by application domains or purpose of use of the descriptions.
6. Modelling Business Processes
Business process components. We propose the concept of reusable business process components where a business process can be subdivided into smaller subprocesses and we reuse these small components to build other business processes. The technique based on genetic algorithm is used to design business process components.
Process-based composite contexts development for mobile platforms. We adopt the concept of business process execution in Web Services to design a process-based language for building composite contexts to be used in context-aware applications on mobile platforms. Based on MDA, PIM-to-PSM and PSM-to-Code metamodels are defined for modelling composite contexts for Android and Windows Mobile.
7. Semantic Web Services
Semantic discovery of Web Services. Description model of Web Services is enriched so that a Web Service can be described by richer set of non-functional attributes as well as semantic information. The richer set of non-functional attributes is based on the result from the survey of service properties. For semantics, a Web Service is described by the general knowledge of the domain of the Web Service, its behaviour, and certain rule-based constraints. Richer description means discovery of Web Services can be based on a more fine-grained query or semantics-related query.