Xref: utzoo comp.object:2589 comp.lang.c++:11778 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!rust.zso.dec.com!shlump.nac.dec.com!subsys.enet.dec.com!cote From: cote@subsys.enet.dec.com (Michael P.A. Cote) Newsgroups: comp.object,comp.lang.c++ Subject: Re: Object-Oriented Metrics Message-ID: <20423@shlump.nac.dec.com> Date: 21 Feb 91 19:06:59 GMT References: <1991Feb21.073010.8592@ithaca.uucp> Sender: newsdaemon@shlump.nac.dec.com Reply-To: cote@subsys.enet.dec.com () Followup-To: comp.object Organization: Digital Equipment Corporation Lines: 74 > From: drich@klaatu.lanl.gov (David O. Rich) > When it comes time to review a particular OO-Design, or even an > OO-Implementation, what kinds of qualitative/quantitative measures are > used? Do people talk in terms of object coupling, cohesion, etc? > (seems like personal preferences tend to dominate here) The fact that personal preferences tend to dominate is merely an indication of the current maturity level of OO technique. :-) There are most definitely coupling and cohesion metrics that can be applied to objects. (See below) Appropriate coupling and cohesion metrics should apply to each and every level of abstraction of the problem space. Therefore, object coupling and cohesion metrics should be taken in addition to metrics based on the individual methods. After all a strongly cohesive object with terrible coupling between methods will not help out the maintainability of the system as a whole. > From: pkr@media01.UUCP (Peter Kriens) > You are very right. Last year I tried to start a discussion abour "object- > normalisation". I always liked the fact that the database people had a > rather nice mathematical technique to to see how good the data model was. I also like the idea of "object normalisation". In fact, I have done some designs that start with a logical data model of the "virtual database" basis of the application and then normalize that logical data model. From that point, I was able to simply assign objects to represent each of the entities in the logical data model. This technique is nice for defining the core objects of an application that is based on some type of Object Oriented Database. However, as you extend the application analysis to cover the fringes, you need some better metrics to guide you. I found a good reference on Object Oriented Coupling and Cohesion. This article was recommended to me by Larry Constantine. Embley, D., and Woodfield, S., "Cohesion and Coupling for Abstract Data Types", Sixth Annual Phoenix Conference on Computers and Communication. Phoenix, Feb 1987; 229-234 They provide 5 levels of cohesion for objects: (from best to worst cohesion) Model - Only one Domain; only operations defined on one domain; No other data abstractions are enclosed. Concealed - More than one useful data abstraction completely encapsulated within an object. Undelegated - A method is defined that operates on only a subset of the entire data domain. Multifaceted - Multiple data domains are joined by common operations. Separable - Unrelated data domains encapsulated within single object. In addition, there are 5 levels of coupling: (from best to worst coupling) * Items are not talked about in the article. Export - Uses only exported methods/domains independent of representation or implementation. * Overt - Uses implicitly exported method * Covert - Uses private domain or operation of another object. Surreptitious - No direct reference but implicit use of privileged knowledge of implementation of another object. Visible - Violate encapsulation with direct reference to internal implementation of another object. MPAC Brought to you by Super Global Mega Corp .com