 |
|
The Dynamic Functional Model
Oracle Tips by Burleson Consulting
|
The Dynamic Model
The dynamic model will show how objects interact
with each other and change their "state". A state is defined as a change in an
object's values. Unlike the object model that dealt with the static environment
of the system, the dynamic model deals with the dynamics of the system and
illustrates how the changes to object values are controlled. The dynamic model
deals with the events that transpire within the system how an object's variables
will change as a result of these events. Basically what we are describing here
is what the "state" of an object will be after some event takes place, and this
is why the dynamic model is sometimes referred to as a "state transition
diagram". In the dynamic model, each class will have a state transition
diagram.
For example, if we continue with our ordering
system from figure 3.4 we will examine two sample state transition diagrams,
one for the order class and another for the item class (Figure 3.5).
Figure 3.5 A Rumbaugh dynamic model for an order
processing system
The first example shows how an order may change
state from a regular order to either a pre-paid order or a COD order. As we can
see from this very simple example, the presence of a value in the
form_of_payment field will determine the change in state for the order entity.
Looking at the item class in figure 3.5 we can
see that every item has a default value as an in-stock item, but the event of hi
sales would make the item a back ordered item. However the event of getting a
new shipment of the item, would make the item an in-stock item.
The Functional Model
The functional model is the third and final
component of the object modeling specification. The functional model shows the
processes that are performed within an object and how the data changes as it
moves between methods.
Experienced analysts will immediate notice the
similarity between the functional model and the traditional data flow diagram.
Essentially, Rumbaugh's functional model corresponds to a functional primitive
data flow diagram.
The model will show the result of an action, but
the model will not display the details on how the action is performed. Again,
like the object and dynamic models, the functional model is a visual display of
processes and the path of data within the system. To continue with our ordering
system example we describe the processes involved in placing an order. (Figure
3.6).
Figure 3.6 A Rumbaugh functional model for an
order processing system
The material in figure 3.6 describes the
internal processing that is done when a customer places an order. When a
customer fills out an order form, the system will check the customer's credit by
going to the credit history data store and return the customers credit history.
If the customer has bad credit then the order will be rejected. However, if the
customer has approved credit then the system will "loop" through each item in
the order, checking inventory levels for each item. If the items are in stock
then the order will be filled and out of stock items are immediately
back-ordered. The system will then go to the inventory data store and subtract
the item quantities that were shipped from inventory. The system will also
create an invoice that will be sent to the customer with the order.
Summary of object analysis
This section should give the reader a feeling
for the approaches that are taken to describe the basic logical functionality of
their systems. Once the logical model has been created and validated, the
developer will then move on to show the physical details of the model. Remember
the polestar of systems development; analysis is concerned with the logical
model, the design is concerned with the physical representation of the model.
