Team 2 Project - Spring 2002 - for 91.522 OOAD - Prof Lechner
by Kishore Vanapalli, Vasu Deva R. Sathu, RamaKrishna Thirividhi
[$CASE/02s522/Team2/
02s522Team2ProjRept{.doc,.htm}]
Introduction:
Hominoid Problem:
This project deals with the moving hominoid along a predefined path which is along a square path with four units size. It project was developed in various phases. The first step towards developing the project was defining UML class diagram with HM (Hominoid), PA(Path Assigner) and a navigation algorithm. The navigation algorithm was responsible for navigating the hominoid along the path specified. The hominoid object contains the properties of hominoid like x-loc, y-loc and face direction. And the object path contains the properties of each cell of the grid(whether it is a path or not) through which the hominoid has to traverse.
The theoretical implementation was aimed towards attaining abstraction so that the user will have the same feeling when the implementation of the program is done. The project was then developed towards achieving graphical representation of the hominoid in the grid for representing the Hominoid and Grid in BDE. The object FO (Font option) was responsible for defining the shape of the node(square,rectangle or ellipse) HG(Horzgraph) gives the details of the author name, time of creation and title.HN (HorizontalNode ) is responsible for node label and geometry of data flow diagrams.
HA(Horizontal Attribute) is responsible for node attribute HL(Horizontal link) to link information for data flow diagram nodes. HI (Horizontal Indent) is responsible for link identification label for data flow diagram. CG (graph cap) is responsible for text display over the entire graph.
LCP Phase II implementation:
In the LCP Phase I (Asgnt 4) the main concern was to initiate and set up the state models for Hominoid Direction and Hominoid Location with their associated states, event types and transition between the states for their corresponding events.
The project LCP Phase II of the Hominoid was an extension of LCP Phase I deals with state models (Hominoid Direction State Model -HD and Hominoid Location State Model -HL) and generation of various events (Advance, TurnRight, TurnLeft –for HD and Increment, Decrement – for HL) and processing them through a queue. Events are generated as event instances with references to active instances of direction and location state models. Each event instance is associated with an event type and two active instances of the state models.
We now focus on the description of generating the events and processing them in a Event Queue Order :
- The main program calls the Single step Navigation algorithm which is responsible for generating one event for each call. The navigation algorithm generates three events (EI rows) Advance, Turn Right and Turn Left (ET’s) to the active instance of the HD state model.
- The next step is to handle or process these events. The processevent.c file contains the implementations of handling these events in Event queue order The function ProcessEventsInEventQueueOrder is called with the EIid for the event that is to be processed. This function in turn calls ProcessOneEvent which is responsible for processing the event.
- The ProcessOneEvent function then gets the Event type and the Active Instance of the State Model to which the event is generated. The function then loops through the State Transition table to determine the state to which the transition is to be made for the Generated Event. Dotransition function calls the HdActions or the HlActions associated with the Generated Event for handling the transition from one state to the other state.
- The hdaction.c
file contains the implementations of the actions associated with the
Events on each the nine state of the two StateModels.
The actions associated with the Location State Model simply make a pr_add of the transition from one state to the other. The actions
associated with the Direction State Model are quiet different. Apart from
its Events TurnRight and TurnLeft,
they also receive the Event Advance which is considered to be an Event
associated with the Location State Model. But the actions associated with
the
Resolving 32 bit Action Routine Pointer
problem:
The actions HdAction0, HdAction1, HdAction2 and HdAction3 which relate to the Direction State Model and the actions HlAction0, HlAction1, HlAction2, HlAction3, HlAction4 which relate to the Location State Model are located in the hdaction.c file and have their prototypes defined at the beginning of the C file. These actions were defined as extern in the file processevent.c from where we actually call these Action Routines from the DoTransition function. This indeed worked well without actually storing the 64 bit address pointing to the action routines. We started resolving this problem by calling the action routines as (*HdAction0)(EIid) which also worked well. We then tried to define the prototype declaration of the action routines as extern in the calling file to the called filed which also worked. Because this declaration of function prototype as extern appeared more appealing we preferred this method and the program is working well.
Contributions of individuals to the project work
Kishore Vanapalli has dealt with
the handling the 32 bit problem for the Action Routines along with the
implementation of the Hd and the Hl routines to
generate EI rows. Vasu Deva
R. Sathu has dealt with processevents and DoTransition functionality to handle EI. RamaKrishna Thirividhi has dealt
with unifying the LCP phase #2 with the Assignment 4 bde
work.
There are four figure in this document which show the State Transition Diagrams, Sequence Diagrams, Object Communication Diagrams and finally the ER- Diagrams.
NOTE : IF U CANNOT SEE THE DIGRAMS PLEASE WAIT
FOR FEW SECONDS FOR THE
DIAGRAMS TO REFRESH ON THE SCREEN.
References?