Frank Tsui

Decoupling Metrics for Services Composition

The decoupling is one of the most important features of service components that make Web services successful in the future. Decoupling metrics can be used to measure and evaluate the decoupling attributes of a distributed service oriented software architecture that has very significant impacts on the understandability, maintainability, reliability, testability, and reusability of software components. The decoupling metrics can also be used as a criterion for selection of existing service components for compositions. Many measurement metrics for decoupling have been proposed, however most measures are not specific for service component decoupling. This paper provides a practical guide for evaluating decoupling between service-oriented components in the service composition such as business process execution language (BEPL). Coupling was originally defined as the measure of the strength of association established by a connection from one module to another. Most of the existing techniques and measuring coupling metrics are classified by procedural programming and object-oriented programming. In this paper we propose a decoupling metrics based on the black-box parameters of service stateness (stateless/stateful), interaction (one-way, two-way), service interface required, service interface provided (supporting/supported interface), invocation modes (sync/async), self-containment (stand-alone/indirect dependent), implicit invocation (blocking/non-blocking), and binding modes (static/dynamic)

Software protection with increased complexity and obfuscation

While many software solutions are provided through open source, the question of proprietary interest still remains. When outsourcing parts of a products software development, theres a risk that the outsourcing partners will become competitors in the future. In this paper we propose an approach to protect proprietary software by increasing its complexity, to prevent reverse engineering. We introduce four Conjectures for protecting our software through obfuscation and explore and provide rationale for why these four Conjectures make logical sense and should be considered for further formal experiments.

A discussion on security typing and measurement for SOA

In a service oriented environment, using SOA technologies, different business entities and services are combined together. Such an environment introduces various security vulnerabilities. This paper proposes an innovative approach to address SOA application security through security typing. We first define security typing concepts, its declaration and definition, with a simple security type, SST, as an example. We then explore various operations under this concept including type equivalence, type compatibility, and type inference. We show, through unary and binary operational examples, that measuring security characteristics requires a clear understanding of the metric scale level and that often times extending an ordinal scale metric to ratio level can be misleading. Our idea and approach to SST may be generalized in the future to more sophisticated security typing.

On Inter-Method and Intra-Method Object-Oriented Class Cohesion

Cohesion has been a topic of interest since structured design [20, 23] in the 1970’s. Today, there are numerous researchers continuing this work into object-oriented designs [1, 3, 5, 7, 9, 10, 12, 13, 16, 18, 19, 22]. Most of the current research has focused on the interaction of methods within a class, the inter-method cohesion. In this paper we consider both the inter-method cohesion and the intra-method cohesion of a class. We have utilized the concept of program slice [21] and extended Functional Cohesion [2] to devise a new intra-method cohesion metric, ITRA-C, for measuring cohesion of each method within the class. This intra-method cohesion is based on the notion of effects and chaining in an effect-slice. We further combine the (inter-method, intra-method)-tuple into one combined Class Cohesion, which provides a quick view of bands of cohesion for classes. A sample of a commercial bank account class is then provided to illustrate these concepts and metrics.

Analysis of software cohesion attribute and test case development complexity

In this paper we report on some of our findings in our on-going research in relating Object Oriented code cohesion to test case development complexity. It is conjectured that the more cohesive the code is the easier it should be to develop test cases for the code. We studied a small ATM application software and measured the cohesion attribute using two existing cohesion metrics, LCOM5 and ITRA-C [6, 12, 14]. We then measured the test case development effort using TCD-Complexity metric [13]. Our measurements showed high correlation between ITRA-C and TCD-Complexity for OO Classes of relatively large size, but not between LCOM5 and TCD-Complexity. This result shows high potential for using certain code cohesion metric as an indicator for test complexity.

Improving software project decision-making process

There are studies that provide empirical data on how communication affects team productivity and decision-making but they do not provide practical approach to quantification of the communicated information. We need more specific and detailed guidance as to what information to communicate and when and how to communicate it.With this paper we initiate our work on developing more detailed communication model by taking into consideration the specifics of the human thinking process.