29.11.2014 Views

Smalltalk and Object Orientation: an Introduction - Free

Smalltalk and Object Orientation: an Introduction - Free

Smalltalk and Object Orientation: an Introduction - Free

SHOW MORE
SHOW LESS

Create successful ePaper yourself

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

20.2.2.5 Specify optimization criteria<br />

Specify <strong>an</strong>y data values which should be maximized (for example, process as m<strong>an</strong>y orders in <strong>an</strong> hour as<br />

possible), minimized (for example, ensure that system response is < 2 milliseconds) or otherwise<br />

optimized.<br />

20.2.3 Adding operations<br />

It is only at this point that the operations in the <strong>an</strong>alysis models are considered. Note how this differs<br />

from the procedural approach in which the operations to be performed would be considered right up<br />

front. The operations are summarized by the object model (but rel ate to functions, actions <strong><strong>an</strong>d</strong> events in<br />

the functional <strong><strong>an</strong>d</strong> dynamic models). The criteria used for identifying operations are:<br />

• operations implied by events,<br />

• operations implied by state actions <strong><strong>an</strong>d</strong> activities,<br />

• operations from functions,<br />

• application / domain operations,<br />

• simplifying operations.<br />

20.2.3.1 Operations implied by events<br />

All the events in the object model correspond to operations (although a single operation may h<strong><strong>an</strong>d</strong>le<br />

multiple events <strong><strong>an</strong>d</strong> vice versa). OMT suggests that during <strong>an</strong>alysis “events are best repres ented as<br />

labels on state tr<strong>an</strong>sitions <strong><strong>an</strong>d</strong> should not be explicitly listed in the object model”. However, if you find<br />

it clearer to list the operations corresponding to the events in the object model; then do so.<br />

20.2.3.2 Operations implied by state actions <strong><strong>an</strong>d</strong> activities<br />

The actions <strong><strong>an</strong>d</strong> activities in the state diagrams correspond to operations. These c<strong>an</strong> be listed in the<br />

corresponding classes in the object model.<br />

20.2.3.3 Operations from functions<br />

Each function corresponds to one or more operations. The functions should be org<strong>an</strong>ized into operations<br />

on objects. This is not as straight forward as it might at first seem since we have not yet associated the<br />

functions with objects.<br />

20.2.3.4 Domain operations<br />

There may be additional domain operations which are not immediately obvious from th e problem<br />

description. These should be identified from additional domain knowledge <strong><strong>an</strong>d</strong> noted. For example,<br />

although a cash point system (ATM system) does not allow you to open <strong><strong>an</strong>d</strong> close accounts, such<br />

operations are appropriate within the domain <strong><strong>an</strong>d</strong> may be import<strong>an</strong>t for underst<strong><strong>an</strong>d</strong>ing the domain or for<br />

aspects of the application which have yet to come to light.<br />

20.2.3.5 Simplifying operations<br />

Examine the object model for operations which are essentially the same. Replace these operations with<br />

a generic one. Note that earlier steps may well have generated the same operation but with different<br />

names. Therefore check each object’s operations to see if they are intended to do the same thing even if<br />

they have very different names. Adjust the other models as appropriate.<br />

165

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

Saved successfully!

Ooh no, something went wrong!