Smalltalk and Object Orientation: an Introduction - Free
Smalltalk and Object Orientation: an Introduction - Free
Smalltalk and Object Orientation: an Introduction - Free
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