Logical View

~ ~ There are three views that can be discussed when referring to a logical view of SNEAKERS. These are the control flow, the data flow, and the agent communications. Each of these views had to be taken into account simultaneously during the implementation of SNEAKERS, but for the purpose of the design, they can be looked at separately. The views presented in the next three sections are the ideals. The changes that had to be made when implementing SNEAKERS are shown in Chapter .

Control Flow

~ ~ The control flow is the order in which the computer controls various pieces of the system. The system can be broken down into major subsystems, as shown in Figure . This figure shows how control passes from one subsystem to the next. For our purposes, the user is considered a subsystem with the ability to add information to the system and affect the control and data flows.

The User interacts with the system through a user interface. Design choices made by the user through the interface are handled by different modules, depending upon the choice. For the sake of simplicity, these are all contained in the subsystem labeled Design Choice Handler in Figure . This module translates the choice into a fact that the expert systems use in the Blackboard System. The blackboard system is described in greater detail in Section . It is essentially the collection of agents, representing each of the aspects, pulled together in one package. These agents communicate using the blackboard to develop various criticisms, suggestions, and advice, which are then fed back through the user interface to be displayed as messages to the user. The Message Handler subsystem handles formatting the output to the user, so that it will be presented properly. After this, the Graphics Display subsystem must update the picture of the tower on the screen to reflect the design choice that was made. When all updates are complete, control is returned to the User.

This control structure allows the user of the system to have a great amount of influence on the system. If the system provided completely automatic design, the user might be totally cut out of the design process. As this is a demonstration system, it is deemed an appropriate design decision to keep the user in the control flow loop at all times.

Data Flow

~ ~ A data flow diagram shows how information is passed between subsystems in a system. The data flow of SNEAKERS is shown in Figure . The subsystems are broken down as they were in Section . Direct communication includes local data storage and explicit data passing through arguments. Indirect communication is simply writing a change to the design database. When each subsystem in the loop has control, it can read the change from the design database.

The User makes a choice which is given directly to the Design Choice Handler subsystem. This system then writes to the Design Database. The Blackboard System reads from the database, and makes changes or adds more complete information. It also passes messages to the Message Handler subsystem, which outputs them to the user. The Graphics Display subsystem updates the view of the tower, by reading changes from the Design Database, and outputs the new view to the User.

The data flow described in this section shows how the various subsystems communicate. This communication scheme is useful in determining the kinds of data that will be available to the subsystems as they are built.

Blackboard and Expert Systems

~ ~ The blackboard system is designed according to the details given in Section . A view of the blackboard system is shown in Figure .

This figure shows the separation among the various expert systems. Though they are separated, they communicate through the blackboard. Each expert system posts information to the blackboard, and reads relevant information (i.e., concerning its aspect) from the blackboard. Each expert system reacts, if possible. The communication between the user and the blackboard is a logical one only. As was shown in Sections and , the information to and from the user passes through several other subsystems to achieve the required communication. However, this does not change the view of the system that the user gets when interacting with a blackboard. The user is still able to get information from other agents and post information to them, just as if they were using a blackboard.

The blackboard is used to keep the agents separated at the logical level, so that they can represent different ``people''. This maintains the view of concurrent engineering as being the combined efforts of many different design agents. By having the agents share information they simulate a group of people checking the design. Information is placed where everyone can see it and each agent is allowed to add any relevant information to it.

Some of the problems which must be tackled with a traditional blackboard approach include information routing to individual agents and agent control. At the design level, it appears that the agents decide what information they need, have access to all information, and are autonomous.