OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] What is coupling? [Was: 3 XML Design Principles]

[ Lists Home | Date Index | Thread Index ]

Hi.

I'll be reading the links Len sent out for a while now.  Up to now my  
practicing (and by practicing I mean semi-literate but personally useful)  
definition for coupling was this:

Coupling is an interaction between components or applications.

How tightly coupled components are is determined by the extent to which  
internal changes in one component require internal changes in the other.   
By this definition, tight coupling tends to increase maintenance costs.   
In my mind loose coupling is irrevocably associated with having good and  
consistently used APIs.

In your example, neither pattern substantially changes coupling.  Both  
have different kinds of fragility.

Furthermore, a transform can move you from one form to another with no  
loss of data.  In systems where you're using the same data lots of  
different ways, you end up with lots of end formats and automated ways to  
reach those points (many website are that now).

The questions become "what formats allow you to capture the most  
information" and "how do you transform and merge data held in those  
formats".   In this context, calling something a "best practice" carries  
little information.  Calling something "a practice that optimizes for X"  
is closer to being useful.

I associate your first use of references:

<Lot id="1">
       -- info about the lot --
</Lot>
<Picker id="John" isOnLot="1">
       -- info about the picker --
</Picker>

With relational design, where one-to-many associations are modelled as  
attributes on the many side.  Familiarity to people well versed in  
relational design is the strongest pro I can think of for it.

I associate your second use of references:

<Lot id="1">
       -- info about the lot --
</Lot>
<Picker id="John">
       -- info about the picker --
</Picker>
<Assignment picker="John" lot="1"/>

With topic maps and modelling associations with roles.  Why not have:

<association type="isBeingPickedBy">
	<participation type="picker" participant="John"/>
	<participation type="lotBeingPicked" participant="1"/>
	...
</association>

At the ellipses you can add all kind of meta data about the association.   
Time started, time ended, picking rate, etc.

----------->Nathan






On Tue, 1 Feb 2005 07:35:09 -0500, Roger L. Costello <costello@mitre.org>  
wrote:

> Hi Folks,
>
> Again, many thanks for the excellent comments.  I am working hard to
> assimilate all your comments, and will create a summary of all the
> discussion soon.
>
> One question that several people asked was, "What do you mean by  
> coupling?"
> Below I have made an attempt at defining coupling.  Do you agree with my
> definition?  Is it complete, i.e., are there other factors that should be
> incorporated into a definition of coupling?
>
> Note that I have changed version #2 to this:
>
> <Lot id="1">
>       -- info about the lot --
> </Lot>
> <Picker id="John">
>       -- info about the picker --
> </Picker>
> <Assignment picker="John" lot="1"/>
>
> The Lot component just contains information about the Lot.  And the  
> Picker
> component just contains information about the Picker.  The Assignment
> element connects the Lot and Picker.  ["Assignment" is not really the
> correct name.  Can someone think of a better name?]
>
> Okay, now for my definition of coupling:
>
> What is Coupling?
>
> Definition: There exists a coupling between two components if there  
> exists a
> "dependency" between the components.  The greater the dependency, the
> greater the coupling.
>
> An obvious dependency is physical dependency.  In version #1 the Lot and  
> the
> Picker are physically dependent (coupled) on each other:
>
> <Lot id="1">
>       <Picker id="John">
>             .
>       </Picker>
> </Lot>
>
> The Picker is a child of Lot.  The Lot is the parent of Picker.  There
> exists a definite physical co-dependency between the Picker and Lot
> components.
>
> A more nebulous dependency is semantic dependency.  In version #1 not  
> only
> does there exist a physical dependency, but there also exists a semantic
> dependency.  Namely, the Picker is located on the Lot.
>
> Now consider version #2:
>
> <Lot id="1">
>       .
> </Lot>
> <Picker id="John">
>       .
> </Picker>
> <Assignment picker="John" lot="1"/>
>
> The Lot and Picker components are physically completely separate.  There  
> is
> no physical dependency.  The Assignment element creates a semantic
> dependency between the Lot and Picker, by identifying that the Picker is  
> on
> the Lot.
>
> So, in version #1 there exists both a physical and semantic dependency
> between the Picker and the Lot.  In version #2 there exists only a  
> semantic
> dependency.  Thus, there is a stronger coupling between the Picker and  
> Lot
> components in version #1.  We say that there exists a tight coupling  
> between
> the components in version #1.  There exists a loose coupling between the
> components in version #2.
>
> Comments?  /Roger
>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>



-- 


.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.

Nathan Young
A: ncy1717
E: natyoung@cisco.com




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS