18.01.2013 Views

Objects, Components, and Frameworks with UML The Catalysis ...

Objects, Components, and Frameworks with UML The Catalysis ...

Objects, Components, and Frameworks with UML The Catalysis ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

© ICON Computing<br />

Collaborations as Architectural Units<br />

❒ A collaboration is an architectural package that contains:<br />

• a set of related interacting types<br />

• characterized by set of interfaces <strong>with</strong> behavior specifications<br />

package patterns.SpellCheck;<br />

interface SpellChecker {<br />

void attach ( target: SpellCheckable);<br />

void spellCheck ();<br />

}<br />

interface SpellCheckable {<br />

Word nextWord ();<br />

void replaceWord (replacement: Word);<br />

}<br />

© ICON Computing http://www.iconcomp.com<br />

Collaboration<br />

A collaboration is an architectural unit or package that contains a set of related interacting types, characterized by<br />

the appropriate types (interfaces <strong>with</strong> behavior specifications).<br />

This slide shows some Java code for the spell-checking collaboration (well, pseudo-Java).<br />

<strong>The</strong> package,called patterns.SpellCheck simply to emphasize that this is a design pattern for implementing spell<br />

checking in any application (<strong>and</strong> to set the stage for an upcoming discussion), contains two interfaces:<br />

SpellChecker: any object playing this role must be able to attach to a target that provides the SpellCheckable<br />

interface, <strong>and</strong> then to spellCheck that target.<br />

SpellCheckable: any object playing this role must be able to provide sequential access to the words it contains,<br />

<strong>and</strong> to replace the word at the current position in that sequence.<br />

Note that this package is purely a design description. It contains no implementation code at all. If we wanted, we<br />

could provide a default implementation class for each of these interfaces. We would most likely put this default<br />

implementation into a separate package. A particular implementation could decide whether or not to use that default<br />

implementation; if it did not, it could still implement this design pattern.<br />

48<br />

48

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!