Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Reusable Associations


Popularity Cycle of Graphical Tools

We have observed an interesting cycle. Programmers write programs that grow bigger and more complex until their own authors cannot debug or modify them safely. Graphical tools become popular to manage the complexity, but then a new programming language or new programming paradigm is invented, programmers return to the more compact textual programming, and a new cycle begins.

In "The Inevitable Cycle: Graphical Tools and Programming Paradigms" (IEEE Computer, August 2007; www.codefarms.com/OOPSLA07/workshop/cycles.doc), we describe three historical cycles:

  • Flow charts were used to manage spaghetti logic in the code but were eliminated by structured programming.
  • Diagrams of table indices helped to manage Fortran programs but were eliminated by the introduction of C structures and pointers.
  • Pointer diagrams representing C data structures were eliminated by the introduction of class libraries.

Software complexity is a serious problem and the prevalent use of graphical tools including UML fits this observation. If this popularity cycle really exists, it implies that the arrival of a new programming technique is imminent and a new paradigm will eliminate or reduce the use of UML class diagrams. The new paradigm would have to include the major improvements that UML gave us:

  • Instead of programming with collections, UML uses more general associations.
  • Associations and classes are both treated as first-class entities.

There is more to UML than just the UML class diagrams though, and the new paradigm would also have to cover those other areas to provide the same utility as all of UML.

A Matter of Control

Most associations need an iterator class, and these iterators can be implemented in the same style as collection iterators. However, when implementing associations, reusable or not, the question is where to keep the methods, which operate on the association.

The commonly used practice today is to add individual methods to classes where the implementation of the method is easiest or seems natural:

void SourceXtoX::    add(Terminal *t,Net *n);
void LinkXtoX::remove();

// USING THE METHODS
Block *b; Terminal *t; Net *n;
b->blockNets.add(t,n);
t->blockNets.remove();


This may look elegant, but it adds to the problem of having parts of the associations scattered throughout the classes and no guidance on where to find them.

The second possibility is to select one class, preferably the "main" or "most important" class of the association, and keep all the methods in it. In the case of ManyToMany, there isn't any clear difference between the Source and Target, which mirror each other. Let's choose the Source:


void SourceXtoX::    add(Terminal *t,Net *n);
void SourceXtoX::    remove(Target *t);
// USING THE METHODS
Block *b; Terminal *t; Net *n; 
b->blockNets.add(t,n);
b->blockNets.remove(t);

This interface is similar to the interface we use for collections today.

Alternatively, for each association, we introduce a new class just to keep the association methods (Listing Three, available online; see "Resource Center," page 5). This association control class (ACC) is a completely different concept from the UML association class (UAC) commonly used today. ACC provides the interface for the association, while UAC represents the data or state associated with the association.

Note the paradigm shift. The user interface commonly used today:

    
     b->termByBlock.add(t,n);


reads "for Block b and the collection termByBlock on it, add a link that connects it (meaning b) through t to n," with emphasis on b.

The new centralized control has a different order of parameters:

          
     blockNets::add(b,t,n);


reads "for association blockNets, add a link from b through t to n," with emphasis on the association.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.