KNOWLEDGE-BASED SOFTWARE ENGINEERING phần 4 ppsx

Forces - For integrating and reusing the existing applications we need to access them programmatically - Through the API access we can reuse data and functionality of the existing applic

M.B Juric et al / Patterns for Enterprise Application Integration 91

interfaces The interoperability interfaces define what services the client applications canrequest from the server applications

Interoperability interfaces define the relations between applications on which theapplications depend Interfaces define the coupling between integrated applications as longliving contracts They provide a facade through which the client applications access theinteroperability services and encapsulate the applications As long as the interfaces stayunchanged we can replace parts or the whole server application without influencing any clientapplication Therefore a lot of effort has to be put into the definition of the interoperabilityinterfaces

BusmessComponent

NewGeneration

I ApplicationFigure 1: Integration broker pattern

Integration Broker should support one or more of the following communication models:

- Synchronous one to one communication, where the client requires immediate responsefrom the server and waits (blocks) for the response

- Deferred synchronous one to one communication, where the client asks for a responselater or is notified by the server (call back or event)

- Asynchronous one to one communication, where the client does not require an answerfrom the server, nor does it require for the server to be online by the time of submitting therequest

- Asynchronous one to many communication, where a single client can communicate withmore servers This model is also called "publish and subscribe"

Typical representatives of Integration Broker pattern are common middlewaretechnologies, particularly remote method invocations (object request brokers) and messageoriented middleware Integration Broker pattern is usually implicitly used in integration Thispattern requires one or more middleware products, which implement the functionality Astoday a high level of abstraction is achieved, this pattern is not modeled in the design time.However, the architecture has to be aware of this pattern and should adapt the communicationrequests between the components

2.5 Consequences

- The number of connections between applications is reduced, which also reduces the level

of coupling between the integrated applications

- The dependencies between the applications are defined as contracts in form ofinteroperability interfaces

- If the interfaces are carefully designed we can replace parts or the whole applicationwithout influencing other involved applications

- The location transparency is achieved

92 M.B Juric el al / Patterns for Enterprise Application Integration

— The maintenance effort and costs are therefore reduced to an acceptable level

3.2 Problem

If we want to reuse the functionality of the existing application, we have to access themsomehow The most obvious possibility is to access them through the applicationprogramming interfaces (APIs) that existing applications provide Sometimes, however,existing applications will not provide any APIs to access their functionality, not even theproprietary ones Or, they will provide only a subset of functionality through the APIs, but wewould need to access the other functions as well

3.3 Forces

- For integrating and reusing the existing applications we need to access them

programmatically

- Through the API access we can reuse data and functionality of the existing applications

- Accessing the application through the APIs is better than going into the database directly.because we do not avoid the business logic

3.4 Solution

The Integration Wrapper pattern is about layered approach to adding APIs to existingapplications This means that the services and the functionality of the existing applications areexported to the other applications, thus enabling interoperability and integration Itsmotivation lies in the Adapter pattern (GoF), however the goal of Integration Wrapper is toprovide reusable interfaces for multiple clients to access the wrapper simultaneously

Figure 2: Integration Wrapper pattern

To develop the wrappers, we will build a layer around the existing application and add thenecessary interfaces We will call the added application interfaces a wrapper and the modifiedexisting application will be called a "wrapped existing application" The Integration Wrapperhas two major objectives First, it should provide open, reusable interoperability interfaces.Second, it should convert the calls to the reuse the services and functionality of existing

M.B Juric et al / Patterns for Enterprise Application Integration 93

application For the latter the Integration Wrapper can reuse the already provided APIs, orneed to add such APIs The structure of the Integration Wrapper is shown in the Figure 2.Generally, the wrapper can add APIs in an intrusive or non-intrusive way There are twopossibilities how to add wrappers to the existing applications:

- We can modify the existing applications and provide the missing access

- We can use screen scraping or terminal emulation to access the functionality though theuser interfaces

One criterion that will influence the decision between modifying the existing applicationsand using screen scrapping or terminal emulation will be the availability of source code andthe required tools We have to make sure that the versions of source code are complete andreflect the current executable code If we do not have the source code and all the tools and thelibraries necessary to build the working executable of the existing application our only choicewill be to utilize the user interface wrapping (discussed a little later)

Even if we have the source code and all the required tools, we might choose not to modifythe existing applications and rather use screen scraping or terminal emulation The reasonscan be that we do not want to risk introducing bugs into existing application, that we are notfamiliar with the technology of existing application, and so on

Even before we select one of these choices, we have to identify the operations throughwhich we will access the existing application functionality We will figure this out with theanalysis of the existing application We have to analyze the application, and we must focus onwhat we actually need The Integration Wrapper pattern is related to the Integration Brokerpattern The structure of the wrapper depends on the type of communication If we usesynchronous communication style, such as remote method invocation, then the infrastructurewill force typed communication and will check the operation signatures When using theasynchronous communication, the wrapper is responsible for decomposing the messages

3.5 Consequences

- Integration Wrapper enables programmatic communication with existing applications

- It enables reuse of the services and the functionality of the existing applications

- It hides the details of internal structure of the existing applications, their technologies, theprogramming model, and the communication details

- It reduces the complexity and decouples the clients

3.6, Related Patterns

Integration Broker, Virtual Component, GoF Adapter

4 Integration Mediator Pattern

4.1 Context

When integrating applications, the integration logic often needs to be separated from all theinvolved applications and also needs to be encapsulated, which minimizes dependencies,increases the reuse, and simplifies the maintenance

4.2 Problem

In cases when we have the existing applications, which need to be integrated with eachother, or where a common functionality is distributed among several applications and/or

94 M.B Juric et al / Patterns for Enterprise Application Integration

duplicated in several existing applications, we often need integration logic, which will solvethese problems and represent a service or a functionality in a common way to its clients Theclients should not be aware of the complexity, hidden inside the mediator

4.3 Forces

- The existing applications often need to be integrated among each other

- Certain functionality is often distributed among more than a single existing application

- Certain functionality is often duplicated in more than one existing application

- The interaction between the applications is complex

- The clients should not be aware of this complexity

4.4 Solution

The Integration Mediator acts like a controller for the involved existing applications andprovides an interface for the clients It should be aware of the existing applications andinclude the interaction logic to fulfill certain higher-level operations which require complexinteraction with the existing and/or newly developed applications The integration logic,contained inside the Integration Mediator can be used for different integration levels, such asdata level integration or function and method level integration The Integration Mediatorshould not access the existing applications directly Rather, it should use the integrationwrappers The structure of the Integration Mediator is shown in the Figure 3, and shows theclient, integration wrappers, and the mediator

Generally, there are two forms of the integration mediators: Single step or Stateless; andMulti step or Stateful Stateless mediators are used for those integration scenarios, where themaintenance of the state during an interaction with the existing applications is not necessary.This means that the way the mediator acts depends only on the response from the existingapplications Examples are routing and brokering, and vocabulary transforming A typicalexample of stateless mediator is an XSLT engine

Stateful Integration Mediator is used when we have to keep track of the previousinteractions with applications The mediator then accumulates the data about the previousinteractions and uses this information for further interactions Stateful Integration Mediatorsare also those based on events, where they remember events and after all required events havebeen triggered, they perform a certain action on the activity

Stateful Integration Mediators require that the state is managed and sometimes evenpersisted State persistence might be needed for the interactions with the existing applications,which take a longer time and thus must be able to survive system shutdowns Such longlasting interactions might be very complex, lasting from a few minutes to hours or even days

Figure 3: Integration Mediator pattern

M B Juric et al / Patterns for Enterprise Application Integration 95

4.5 Consequences

- Application dependencies are minimized

- The integration logic is encapsulated and decoupled from the participating existingapplications and new clients

- Maintenance is simplified as the integration logic is centralized rather than distributedamong existing applications

- Services can be built on top of the functionality, provided by the mediator, thus they donot have to be aware of the complexity of the existing applications

4.6 Related Patterns

Integration Wrapper, Virtual Component, GoF Mediator, GoF Facade

5 Virtual Component Pattern

5.1 Context

Accessing the services of an integrated information system can vary, particularly if theintegration system uses a variety of existing applications, implemented in differenttechnologies Accessing these services directly would require that the clients possesses theknowledge of the internal structure of the information system Virtual components provide acommon, unified access point to the services, thus acting as a fa9ade to the existingapplications

5.2 Problem

Clients, accessing the integrated information system should not be aware of the complexity

of the existing applications and should not access them directly Integrated informationsystem is also more than just connected existing applications Integrated information systemshould provide new services and functionalities They should be exposed to the clients in acommon, uniform way If clients would access the existing applications directly, they would

be too highly coupled with them, making the maintenance and the replacement very difficult

5.3 Forces

- Existing applications do not provide the high level services and functionalities, required

by clients

- Clients should not be aware of the complexity of the information system

- Client should use high level services

5.4 Solution

Virtual Component pattern provides a solution for integrating the existing applicationswith the clients The pattern has its motivation in the Facade pattern, however, the VirtualComponent pattern is targeted towards the integration and provides reusability and the ability

to re-engineer and replace the applications behind the virtual component with the actual,modern implementation Integrated information system based on the Virtual Componentpattern is a system that looks like a newly developed information system where in fact itreuses the functionality of the existing applications

96 M.B Juric et al / Patterns for Enterprise Application Integration

Virtual components do not differ from the newly developed components from theperspective of the clients Both provide the functionality through the interfaces The concept

of virtual components will therefore allow us to make existing applications look like newdeveloped components and to mix existing and new applications in all and any possible way.Virtual Component pattern encapsulates the details that the existing applications contribute

to satisfying requests and the methods by which they are satisfied On one side, the virtualcomponent presents the exiting application through abstract interoperability interfaces On theother side, the virtual component communicates with the integration wrappers and theintegration mediators This is shown in the Figure 4

Figure 4: Virtual Component patternVirtual component might be for example an order placing component, which provides asimple interface to place an order and internally accesses the existing systems like a paymentsystem, an inventory system etc Virtual component, together with the abstractinteroperability interfaces present an application view that is implementation independent If

we keep the abstract interface constant, the other applications are not aware of any changesthat are done on the original application Thus, there is no need for modifying otherapplications that depend on the original application when a change is made In other words,client virtual components are unable to determine how the server virtual components areimplemented

The Integration Broker pattern influences the way in which a virtual component will beactually implemented In each case the virtual component masks the complexity of theexisting applications that implement the high level business functionality in the background.Virtual components are deployed on the business logic tier They will be built in severalstages during the integration The different virtual components will expose the interfaces thatwill offer different abstraction levels to access the functionality Therefore, we will organizethe virtual components into several sub tiers on the business logic tier

The virtual components on a lower level will take care of the technology adoption, and will

be built on data level and application interface level integration Virtual components on higherlevels will transform the high level business request into a series of lower level calls todifferent low level virtual components for the existing applications High level virtualcomponents will also do some data conversions and adoptions to finally reach the goal ofimplementing the functionality through the reuse of existing applications

We will typically use virtual components for one or a combination of the followingfunctions:

- Virtual components encapsulate functionality of existing applications and present them inthe same way, or some rearranged way Virtual components can, for example, presentexactly the same functionality that can be found in the existing application APIs In this

M.B Juric et al / Patterns for Enterprise Application Integration 97

case they just mask the technology differences and are called lower level virtualcomponents

- Lower level virtual components implement the code that translates the method invocationsinto one or more calls to APIs of the existing applications and databases accesses Thiscode will often have to do parameter transformations, alignment of data types, and othertransformations to mask the technology differences between the J2EE technologies andthe technologies used by the existing applications In more simple terms, the lower levelvirtual components will act as adapters between the new and the existing applications

- Virtual components can provide a different, higher level interface and thus mask the wayexisting applications implement their APIs, too Such virtual components are called higherlevel virtual components and their interfaces should be defined based on a global designmodel, which we will discuss later in this paper

- Virtual components can encapsulate several existing applications and help in maintainingthe transaction integrity and the security

- Virtual components are also useful to encapsulate or abstract persistent data For thispurpose the virtual components can access EIS databases directly or though providedprotocols In this case they will often also implement the validation logic This is an extralevel of security, which might not have been handled by the old application that will keepthe database in a consistent state

- Virtual components can provide a unified access to several EIS databases and can handledifferent combinations of databases in the background Alternatively, they can use APIs toaccess data, if those APIs are provided by the existing applications

- Virtual components will often be layered, thus higher level virtual components willaggregate the behaviors of lower level virtual components and provide the higher level ofabstraction required for multiple levels of abstraction of EIS application functionality

- Virtual components can also be used to map technical differences A particularly usefulscenario is to adapt synchronous and asynchronous communication models

5.5 Consequences

- Virtual components provide a unified view on the services and the functionality of

integrated information system

- Virtual components abstract the details of the information system, thus providing a sort offacade

- Virtual components provide high level, business process oriented interfaces forinteroperability

- They enable easy replacement with newly developed components as long as the interfacesremain unchanged

5.6 Related Patterns

Facade, Integration Wrapper, Integration Mediator, Integration Broker

6 Data Mapping Pattern

6.1 Context

When integrating the existing applications, the data often needs to be moved from oneapplication to other Access to the databases of existing applications varies from the type of

98 M.B Juric et al / Patterns for Enterprise Application Integration

datastore (relational, object, hierarchical, flat files, and so on.) and the way data is accessed(directly to the database, through application, physical, and so on.)

6.2 Problem

The data mapping logic can become complex, therefore it is preferable if it is encapsulatedand decoupled for the existing applications This way the data mapping logic is less coupledwith the existing applications, which improves maintenance

6.3 Forces

- Data needs to be moved between the existing applications

- Data is stored in different formats in the existing applications

- Accessing the data varies from the type of storage and the access technologies

- The data mapping logic should be separated and should not be complicated with technicaldetails

6.4 Solution

The Data Mapping pattern is used to encapsulate and abstract the data mapping logic fortransferring, replicating and updating data between the related integrated existingapplications This pattern accesses the data store, either directly through DAO, or wrappers.The Data Mapping pattern comes in two variations: the Direct Data Mapping; and theMulti Step Data Mapping The Direct Data Mapping pattern handles the mapping, where dataneeds to be moved from a certain data store to the other, without transformations The MultiStep Data Mapping also transforms the data The structure of the pattern is shown in theFigure 5

DataSource uses ' DataMapping •

BusinessComponent uses uses DAO

uses lntegralionWrapper

DirectData ' MultiStepData

Mapping MappingFigure 5: Data Mapping pattern

6.5 Consequences

- The data mapping logic is encapsulated and decoupled from the participating existing

applications and their data stores

- Data dependencies are minimized

- Maintenance is simplified as the data mapping logic is centralized rather than distributedamong the existing applications

- Business components can use the functionality, provided by the Data Mapping pattern,thus they do not have to be aware of the data complexity of the existing applications

M.B Juric et al / Patterns for Enterprise Application Integration 99

6.6 Related Patterns

Integration Wrapper, Integration Mediator, Data Access Object

7 Process Automator Pattern

7.1 Context

System interactions should often be hidden and abstracted by the process controller Thedependencies between the business process controllers and the system logic of theinformation system should also be minimized

7.2 Problem

The services of an integrated information system should be exposed to the clients thoughhigh level methods, which reflect their business processes A typical business process methodwill require an interaction with different virtual components and integration mediators Thisinteraction should not be delegated to the clients, because this enhances the complexity,increases the maintenance effort, and does not allow us to use declarative transactionmanagement

- Clients should not be responsible for making the necessary operation invocations

- Business process logic should often be performed inside transactions

- The dependencies between process automation control and the information systemtechnology should be minimized

7.4 Solution

Process Automator pattern enables to gather and encapsulate the business process logic andthus enables to minimize the dependencies between the business process automation logic andinformation technology system logic All interactions are hidden by the process automatorcontroller This pattern helps to improve the quality of business processes, reduces the processexecution costs and reduces the necessary time Therefore, this pattern is highly appropriatefor defining integration process within and between the companies

The Process Automator pattern sequences the activities of a business process and delegatessteps to the corresponding parts of the information system It does this using virtualcomponents and integration mediators, through which the automator components access thefunctionality of the existing applications The process automator, however, can access thenewly developed components as well The structure is shown in Figure 6

Common uses for the Process Automator pattern are the definition of the businessactivities, the timers, and process context informators It comes in two variations: ClosedProcess Automator; and Open Process Automator The difference is exclusively in thesemantic understanding of both types of processes The Closed Process Automatorimplements a process, which is managed internally and externalizes the key process activities

100 M.B Juric et al / Patterns for Enterprise Application Integration

only through the data exchange The clients are able to monitor the activities within theprocess, but cannot actively participate in their execution The Open Process Automatorenables sharing of business process between the clients Such processes are managed by morethan one client and are particularly useful for inter EAI, or B2B integration, where a singleprocess is shared by more than one company

ProcessAutomator

Figure 6: Process Automator pattern

7.5 Consequences

- The architecture allows easy analysis of business processes, their bottlenecks, utilization,

downtime, and so on

- Flexibility is achieved for redefining the business proceses

- The process automator components are aligned with the business managers view, whichreduces the semantic gap between IT and management

- With the connection to the virtual components and the integration mediators, a highlyflexible integration architecture can be defined

The presented integration patterns are useful for intra-EAI as well as for inter-EAI andB2B integration We have followed the principle that successful inter-EAI and B2Bintegration can be built on a well-defined intra-EAI only Therefore, the integration patternshave to be applied step by step, first to enable the intra-EAI integration Then we should buildB2B interactions on top of an integrated architecture In this context all the presented patternsare important However, the process automator pattern is the one that deserves a specialconsideration Typically, we will apply this pattern when implementing shared business

M.B Juric et al / Patterns for Enterprise Application Integration

processes Our future research will be focused on how to apply these patterns using the mostimportant component based architectures

Knowledge-based Software Engineering

T Welzer et al (Eds.) /OS Press 2002

A Proposal of Class Cohesion Metrics

Using Sizes of Cohesive Parts

Hirohisa AMAN1, Kenji YAMASAKI1, Hiroyuki YAMADA1, Matu-Tarow NODA1

Department of Computer Science, Ehime University.

Bunkyo-cho 3, Matsuyama, Ehime 790–8577, Japan

aman@cs.ehime-u.ac.jp

Abstract Cohesion is one of traditional and important software attributes This could

be used to assess object-oriented class design Several metrics have been proposed in

order to capture class cohesion in terms of connections among methods within a class.

These metrics are based on (1) the number of sets of connected methods, or (2) the

density of method connections within the class, but they do not consider sizes of sets

of connected methods In this paper, two new metrics for class cohesion have been

proposed, which are focusing on sizes of sets of connected methods, with considering

strength of method connection These proposed metrics are analytically verified using

have been proposed : 'Lack of Cohesion in Methods' (LCOM)[5]-[S], 'Tight Class Cohesion (TCC), 'Loose Class Cohesion (LCC)'[7], 'Information flow-based Cohesion (ICH)'[9]; see

[4] for details of them These metrics are based on (1) the number of sets of connected ods, or (2) the density of method connections within the class, but they do no consider sizes ofsets of connected methods In this paper, two new metrics for class cohesion have been pro-posed, which are focusing on sizes of sets of connected methods, with considering strength

meth-of method connection The proposed metrics satisfy the mathematical properties meth-of cohesionmetrics proposed by Briand and others[10]

2 Models and Metrics

Preliminary to developments of metrics, we present several underlying definitions

102

H Aman et al /A Proposal of Class Cohesion Metrics 103

Definition 1 (binary relation on methods).

Given a class Let M be the set of methods within the class We define a binary relation

S : M M as

5 = { (u, v) e M x M | u invokes v } Then we define the reflective transitive closure S* : M M as

V u Snv] } , (1)

where S n = S n– l oS (n > 2), and S1 = S ("o" indicates the composition of relations[11].)

Based on S*, we represent indirect relationships between method and attribute, as well as

direct relationships between them

Definition 2 (method accesses to attributes).

Given a class Let M be the set of methods, and A be the set of attributes, within the class For any m M, a A, we define the following predicates ac, wr and re :

The predicate ac considers not only direct access to attribute but also indirect access to tribute via access-methods, wr and re are focusing on data-writing and data-reading through

at-attribute access Using the above three predicates, we introduce two graph models

Definition 3 (weak-connection graph).

Given a class Let M be the set of methods, and A be the set of attributes, within the class.

We define weak-connection graph as an undirected graph G W (V, E), where V — M and

E = { {u,v} € M x M |3a € A s.t ( ac(u,a) A ac(v,a) ) } (5)

Definition 4 (strong-connection graph).

Given a class Let M be the set of methods, and A be the set of attributes, within the class.

We define strong-connection graph as a directed graph G S (V, E), where V = M and

E — { (u, v) € M x M | 3a A s.t ( wr(u, a) A re(v, a) ) } (6)

When two or more methods access to one attribute, those methods seem to share theattribute The weak-connection graph represents attribute-sharings

Furthermore, accesses to attributes include data-readings and data-writings If a methodwrites data onto an attribute, and another method reads data from the attribute, then a depen-dent relationship might be occurred between the methods Such relationship is emphasized

by the strong-connection graph

public class C {private int al, a2;

public void ml (int x){ al = x; }public void m2(int y){ a2 = y; }public int m3(){ return al + a2; }public void m4(){ ml(0); }

Figure 1: An example of class written in Java.

(a) Weak-connection graph for Fig 1 (b) Strong-connection graph for Fig I

Figure 2: Weak-connection graph and strong-connection graph for the class shown in Fig.l.

For example, consider a class shown in Fig 1 According to Defs.3 and 4, we obtain the

weak-connection graph and the strong-connection graph shown in Fig.2 :

a c ( m l a l ) , ac(m3.al) and ac(m4.al) are true, so that the edges {ml,m3}, {ml,m4} and

{m3,m4} are shown in Fig.2(a);

'm4 invokes m l ' , 'ml writes data onto al' and 'm3 reads data from a l ' , so that w r ( m l a l ) ,

w r ( m 4 a l ) and r e ( m 3 a l ) are true Thus the edges (ml,m3) and (m4,m3) are shown in Fig.2(b):

etc

While the strong-connection graph is sensitive to directions of attribute accesses, the

weak-connection graph is insensitive to them In other words, the weak-connection graph

seems to be optimistic about method connections, but the strong-connection graph looks

pes-simistic about them

Using the weak-connection graph and the strong-connection graph, we propose two

met-rics for class cohesion

Definition 5 (Optimistic Class Cohesion (OCC)).

Given a class C Let M be the set of methods, and A be the set of attributes, within

C Consider the weak-connection graph G,,.(V E), where V" = M and E is in Eq.(5) Let

H Aman et al /A Proposal of Class Cohesion Metrics 105

\R w (m i )\/(n — 1) denotes the percentage of methods to be reachable by mi on the

weak-connection graph (' — 1' means excepting itself) OCC is the maximum value of them That

is, OCC quantifies the maximum extent of attribute-sharings among methods within the class.

For example, in the case of Fig.2,

R w , (ml) = {m2, m3, m4}, R w (m2) = {ml, m3, m4},

R w (m3) = {ml, m2, m4}, Rw(m4) = {ml, m2, m3}.

Thus | R w ( m l ) | = • • • = |R w (m4)| = 3 We can calculate as OCC = max[3/(4 – 1)] = 1.0.

Definition 6 (Pessimistic Class Cohesion (PCC)).

Given a class C Let M be the set of methods, and A be the set of attributes, within

C Consider the strong-connection graph G S (V, E), where V = M and E is in Eq.(6) Let n= | M |

For each method mi M(i = 1, , n), let Rss(mi) be the set of methods which arereachable by mi on G S (V, E) :

R s (m i ) = { m j M | 3mk1l , , m kp e M s.t

(mks.,mks+1) e E (s = l , , p - l ) , m i = m k 1 , m j = m k p t i = j }

We define Pessimistic Class Cohesion (PCC) for class C as

•

R s (m i )|/(n — 1) denotes the percentage of methods to be reachable by m i on the

strong-connection graph PCC is the maximum value of them That is, PCC quantifies the maximum

extent of dependent relationships among methods within the class This would be the mum size of highly cohesive part of the class For example, in the case of Fig.2,

maxi-R s (ml) = {m3}, R ss (m2) = {m3}, R s (m3) = {}, R s (m4) = {m3}.

Thus |Rs(ml)| = |R s (m2)| = |R s (m4)| = 1and|R ss (m3)| = 0 We can calculate as PCC =

m a x [ l / ( 4 – l ) , 0 / ( 4 - l ) ] = 1/3

3 Analytical Evaluation of Metrics

Briand, Morasca and Basili have proposed a mathematical framework (BMB framework)including properties to be satisfied by several types of software metrics[10] The supportedtypes of metrics are 'size', 'length', 'complexity', 'coupling' and 'cohesion' Note that BMBframework provide necessary conditions of software metrics, because the framework doesnot include the all properties to be satisfied by those metrics

In BMB framework, a software is represented by a graph model in which vertexes arecorresponding to software components, and edges are corresponding to coupling relationshipsbetween the components BMB framework have suggested the following four properties to

be satisfied by cohesion metrics For the sake of convenience, we will write the cohesion of

class C as

Property 1 : u(C) e [0, max] , where max is a positive constant number.

106 H Aman et al /A Proposal of Class Cohesion Metrics

Property 2 : Let G(V, E) be the graph model of a class C Then E = o => u (C) = 0 Property 3 : Consider two classes C and C' whose models are G(V E) and G(V E'), re

spectively Then E E' =» u(C) < u(C1)

Property 4 : Consider two classes C\ and C2 whose models are G1(V1.E1} and G2( V2 E2),

respectively Let C 12 be a class whose model is G1 2(V1 U V2 E12), where E1 U E2 E12,i.e., C12 is composed of C1 and C2 Then (E1 U E2 — E12) A ( E 1 n E 2 = o) =>

max[ u(C1) u/(C2) ] (C1 2)

3.1 OCC

OCC satisfies the above four properties We now show the proof for the property 4 only, for

the lack of space; the proofs for the remaining properties could be derived from the definitions

of OCC and Rw easily.

Proof for Property 4 :

Let C\ has n 1 methods m,1 (i = 1 n 1 ), C 2 has n2 methods mt2 (i = 1 n2), and C12 has

n12 methods mi12 (i = 1 , ni 2), respectively Let R 1u (m 1i) be the set of reachable methods by mi1

on GI (V1, E1) , R 2w(m12) be the set of reachable methods by mi2 on G2(V2, E 2 ) and R 12u (m i12 ) be the

set of reachable methods by mi12 on Gi2(V'i U V2, £]2), respectively

(i) Case n1 = n2 = 1 : From the definition and property 2, OCC(C1) - OCC(C2) = OCC{C!2) =

0 Thus, max[OCC(Ci).OCC(C2)] - OCC(C 1 2 )

(ii) Case n1 > 1 or n2 > 1 : This case may be n 1 + n2 > n12 Let ni + n2 - n12 = p (> 0) We will

describe m 1n1 _ p+k = m2k (k — 1 p), without loss of generality In constructing C!2 from Ci and

C2, we add no edge to their weak-connection graphs Thus

3.2 PCC

In the above proof, replace 'OCC" with 'PCC', 'R w ' with 'R s ', and, 'weak-connection graph'

with 'strong-connection graph', respectively Then we can get the proof for PCC.

4 Conclusions and Future Works

We have proposed two metrics for class cohesion, OCC (Optimistic Class Cohesion) and

PCC (Pessimistic Class Cohesion) If two or more methods access to one attribute directly or

indirectly, those methods seem to share the attribute Such sharing is a kind of connections

among methods OCC quantifies the maximum extent of such connections within a class.

This would be the maximum size of cohesive part of the class

When methods access to attributes, those accesses include data-readings and data-writings

By focusing on such differences in accesses, we can consider dependent relationships among

methods, which would be strong connections among methods PCC quantifies the maximum

extent of such dependent relationships within a class This would be the maximum size ofhighly cohesive part of the class

According to BMB framework, we have showed that OCC and PCC satisfy necessary

conditions of cohesion metrics

The future works include the followings : (1) to study relationships among OCC, PCC

and existing metrics using many experimental data; (2) to discuss the usefulness of BMBframework in the software engineering discipline

References

[1] G.J Myers, Software Reliability-Principles and Practices, John Wiley & Sons, Inc (1976).

[2] M Page-Jones, The Practical Guide to Structured Systems, 2nd ed., Yourdon Press (1988).

[3] E Yourdon and L Constantine, Structured Design, Englewood Cliffs, Prentice Hall (1979).

[4] L.C Briand, J W Daly and J Wust, A Unified Framework for Cohesion Measurement in Object-Oriented Systems, Empirical Software Eng : An Int'l J 3(1) (1998) 65–117.

[5] S.R Chidamber and C.F Kemerer, A metrics suite for object-oriented design, IEEE Trans, on Software Eng 20(6) (1994) 476–493.

[6] M Hitz and B Montazeri, Chidamber and Kemerer's metrics suite : a measurement theory perspective, IEEE Trans, on Software Eng 22(4) (1996) 267–271.

[7] J.M Bieman and B.-K Kang, Cohesion and reuse in an object-oriented system, Proc ACM Symp ware Reusability (1995) 259-262.

Soft-[8] B Henderson-Sellers, Software Metrics, Prentice Hall (1996).

[9] Y.-S Lee, B.-S Liang, S.-F Wu and F.-J Wang, Measuring the coupling and cohesion of an object oriented program based on information flow, Proc International Conference on Software Quality (1995).

[10] L.C Briand, S Morasca and V.R Basili, Property-based software engineering measurement, IEEE Trans,

on Software Eng 22(1) (1996) 68-86.

[11] D.F Stanat and D.F McAllister, Discrete mathematics in Computer Science, Prentice-Hall (1977) [12] H Aman, H YamadaandM.T Noda, A Proposal of Class Cohesion Metrics focusing on Sizes of Cohesive Parts, Technical Report of IEICE KBSE2001-19 (2001).