Design Fest Solution For The French Fry Processing Control System
This Activity Was Part Of The Advanced Object Oriented Programming Topics Course
IME/USP - Institute of Mathematics and Statistics of the University of São Paulo - Brazil

Team

André Kowaltowski (webdesigner)

César Seragiotto

Daniela Akizuki

Elisa Kameda (recorder)

George Silva

Marcos Nakashima (moderator)

Problem Description

Problem Overview

Some of the major components of a food processing plant are machines that sort good food products from bad ones. With the advent of faster networks, object oriented techniques, and especially the notion of distributed objects, food processing plants are ready to move to the level where a set of machines, interoperates with one another to achieve a desired sorting goal for the plant, ultimately, allowing the machines to be treated and controlled as a single system, rather than a set of individual entities. This design problem deals with architecting the distributed objects that would be required for such a distributed control system, applied in particular to the process of sorting french fries.

Full Description

The full description of the problem can be found at the offical design fest homepage.

Mission

To create a system for order input, analysis, manipulation and (re)configuration of the Tegra and ADR machines to reach the specifications of the customers order.

Assumptions

We assume the existence of a Scale at the end of the conveyer belt that wheighs the processed potatoes and sends a signal to the Administrator when it has reached the specified weight.

We also assume the existence of a standard initial configuration for both the Tegra and the ADR machines.

Class Model

CRC

We began our design using the CRC (Class Responsability Collaborator) cards technique.


Class: Scale
Responsibilities Collaborators
knows current order's weight Administrator
notify end of order

Class: Order
Responsibilities Collaborators
knows order id Administrator
knows order weight
knows order customer
knows potatoes average size
knows order defect tolerance

Class: DataManager
Responsibilities Collaborators
asks machines data Tegra and ADR
resets machines data
provides data Configurator
keeps configuration history and its justifications

Class: Administrator
Responsibilities Collaborators
receives end of order notification Scale
receives report request human operator
generates report DataManager
changes order specifications Configurator
human operator
keeps an order's FIFO Configurator
generates orders human operator

Class: StatisticalModel
Responsibilities Collaborators
trend evaluation Configurator

Class: Configurator
Responsibilities Collaborators
chooses statistical model StatisticalModel
generates new configuration
sends new configuration Tegra and ADR
requests history DataManager
knows machines specifications  

UML

After establishing the basic ideas for the class model through the role-playing using the CRC cards as a responsability guide we created the following UML class diagram:

Design Patterns

These patterns were used in the design:

Builder

One of the applicability of this pattern is when the construction process must allow different representations for the object that's constructed. In our design it was used to generate different types of reports.

Observer

This pattern is used when an object should be able to notify other objects without making assumptions about who these objects are. We used this pattern to notify events from SCALE to ADMINISTRATOR.

Strategy

Strategy is useful when you need different variants of an algorithm that uses data that clients shouldn't know about. In our design, this pattern was used to present several statistical models.

Use Cases

Use Case 1

Description

Statistically equivalent incoming stream of potatoes. PID loop maintains thresholds so that spec is met.

Behaviour

When statistically similar potato shippings are used, the StatisticalAnalysis returns similar results. When the configuration reaches the quality level desired, there are no machines reconfigurations.

Use Case 2

Description

The past couple of days have been spent processing potatoes that were recently harvested. The control system has made only minor fluctuating adjustments to keep the sort "in grade." Today though, they began processing potatoes stored over the winter. These potatoes are turning into fries that are signifigantly more defect ridden. The control system notes the sudden spike in the trend data gathered from the Tegra and ADR. Tegra is adjusted to sort more stringently (i.e. the defect threshold are lowered). The ADR is instructed to shred fries more readily (to just keep trying to remove the increased load of defects, would result in a change in the histogram of output fry length).

Behaviour

The control system notes the sudden spike in the data and the StatisticalAnalysis estimate trends that stricts the machines' configurations. Tegra rejects potatoes more strictly and ADR shreds fries more readily.

Use Case 3

Description

The plant has been sorting fries for MuckRonalds for the last hour. MuckRonalds specifies, among other things, that they want their fries to be a very tight distribution centering around 10.5 cm. A new order to process fries for BellyAcher Queen comes in. Said vendor wants fries that are loosely centered around 13cm fries. New length histogramming bins are set. The control system analyzes past history data, decides on new minimum and maximum thresholds for Tegra and ADR and sets them. The system then begins to iteratively control these thresholds to achieve new length distributions.

Behaviour

The control system uses the StatisticalAnalysis and the order specs to reconfigurate the machines, relaxing the size thresholds, until an appropriate configuration is determined.

Use Case 4

Description

The current fry customer decides that to gain a competitive advantage, they need to reduce all of their allowable defect percentages by 1%. The new spec is generated. The system begins trying to adjust the size thresholds to maintain the new defect specs.

Behaviour

To reconfigurate an Order, the user gives the Order's identification and the new configurations. The Administrator receives these data and reconfigurates the Order even if this is the one that is being produced. If this Order is in the orderQueue it's reconfigurated with no effects in the production.

Slide Presentation

A ppt version of our slide presentation can be downloaded here.

Lessons Learned

Design Patterns

Although already familiar with the Gof Design Patterns, during the fest we were able to identify parts of the class model where such patterns would simplify and enhance our design.

Role Playing

The usage of CRC cards was usefull during the initial modeling stage for defining the basic necessary classes. After this period, we found it very usefull to role play the execution flow. This "enactment" brought up a few other interaction details that hadn't been identified during the CRC phase allowing us to fully understand the system requirements.