I'm developing ( in JAVA ) a food costing application.

I've got the following as basic ideas, but if anyone can offer more 
features, ideas, etc please jump in...

Specifications for food-costing application:

Program must be able to do the following:
*	Accept user input of data
*	Accept user modification of data
*	Delete data
*	Calculate food cost per item
*	Access MySQL database via web
o	Perform Queries
        	Select, Insert, Delete, Update
*	Create custom conversion units based on weight associations 
and use these conversion in calculations as needed
*	Generate reports
*	Inform users of updates to database 

Potential Objects

*	Recipe->is a collection of ingredients prepared in a specified 
manner
*	MenuItem -> is the result of executing a recipes? instructions
*	Ingredient ->is a specific item used in a recipe
*	UnitOfMeasure -> the weight applied to an ingredient
*	User
*	CustomConversion

Objects::fields
*	Recipe
o	   Ingredient(s) array
o	   Instruction(s)
o	   FoodCost
o	   RecommendedSellPrice
o	   Yield
o	   MenuItemCategory

*	MenuItem extends Recipe
o	   menuLevel (lunch, special dinner etc?)
o	   actualSellPrice
o	   menuClass ( app, entrée, special, desert etc?)

*	Ingredient 
o	   nameOfIngredient
o	   costOfIngredient
o	   yieldOfIngredient 
o	   weightOfIngredient
o	   inventoryCountingFactor
o	   prepNote //an ingredient specific instruction

*	UnitOfMeasure
o	   unitName
o	   unitWeight
o	   unitWeightType

*	CustomConversion
o	   conversionIngredient
o	   conversionMultiplier
o	   conversionWeight
o	   Ingredient
o	   ingredientMultiplier
o	   ingredientWeight
*	User 
o	   userNameFirst
o	   userNameLast
o	   userUserName
o	   userPassword
o	   userAccessLevel
o	   lastLogin
o	   accountCreationDate
o	   userEmail

Hi there,

I've some suggestions:

1.  From the spec. I can see a hierachy of "Data" -- objects that has some
basic "Data"-bahaviors like: updating/retrieving the contained data to DB or
returning the data.  At the top, is the class that models only those
behaviors.  Going down the hierachy would be those with overriding behaviors
that are more specific for themselve according to their individual structure
of data.  The objects in this hierachy can employ (accept as parameters to
their methods) some Data tier objects to interact with the database.  This
way of modeling make the application extensible -- possible to add in
classes down the hierachy to inherit the basic data interacting methods.
Each of the  classes in the hierachy can implement specific interfaces as
required such as: menu item, ingredients etc.

2.  Presentation object:  some kind of UI objects that will call those data
objects (to interact with db) and specific-interface-implementators (to
perform specific behaviors)

3.  I cannot see the relationship between MenuItem and Recipe as an "Is-a".
They are definitely associated to each other, but an object of MenuItem type
can not be one of Recipe.

4.  I don't quite understand the conversions.  However, my feeling is that
they are not neccessary objects; they may be just some of the
specific-behiviors (methods -- doing some calculations in some Interfaces)

In summary, I can see the major Data hierachy of objets with some specific
"business-tie" behaviors and some other separated objects that are
associated with the business-tier.

Hope that helps.

Cheers,
Tuong Nguyen

-----Original Message-----
From: peter@p... [mailto:peter@p...]
Sent: Tuesday, 1 October 2002 6:26 PM
To: Application Development
Subject: [application_development] Ideas for this food-costing
application


I'm developing ( in JAVA ) a food costing application.

I've got the following as basic ideas, but if anyone can offer more
features, ideas, etc please jump in...

Specifications for food-costing application:

Program must be able to do the following:
*	Accept user input of data
*	Accept user modification of data
*	Delete data
*	Calculate food cost per item
*	Access MySQL database via web
o	Perform Queries
        	Select, Insert, Delete, Update
*	Create custom conversion units based on weight associations
and use these conversion in calculations as needed
*	Generate reports
*	Inform users of updates to database

Potential Objects

*	Recipe->is a collection of ingredients prepared in a specified
manner
*	MenuItem -> is the result of executing a recipes? instructions
*	Ingredient ->is a specific item used in a recipe
*	UnitOfMeasure -> the weight applied to an ingredient
*	User
*	CustomConversion

Objects::fields
*	Recipe
o	   Ingredient(s) array
o	   Instruction(s)
o	   FoodCost
o	   RecommendedSellPrice
o	   Yield
o	   MenuItemCategory

*	MenuItem extends Recipe
o	   menuLevel (lunch, special dinner etc?)
o	   actualSellPrice
o	   menuClass ( app, entrée, special, desert etc?)

*	Ingredient
o	   nameOfIngredient
o	   costOfIngredient
o	   yieldOfIngredient
o	   weightOfIngredient
o	   inventoryCountingFactor
o	   prepNote //an ingredient specific instruction

*	UnitOfMeasure
o	   unitName
o	   unitWeight
o	   unitWeightType

*	CustomConversion
o	   conversionIngredient
o	   conversionMultiplier
o	   conversionWeight
o	   Ingredient
o	   ingredientMultiplier
o	   ingredientWeight
*	User
o	   userNameFirst
o	   userNameLast
o	   userUserName
o	   userPassword
o	   userAccessLevel
o	   lastLogin
o	   accountCreationDate
o	   userEmail

Hi Tuong;

Thanks for you response.  Points 3 and 4 are of particular note:
3.  I cannot see the relationship between MenuItem and Recipe as an "Is-a".
They are definitely associated to each other, but an object of MenuItem type
can not be one of Recipe.

**My thinking here is that a recipe is the base upon which a menu-item
is  created:  a one to one relationship.  But we might be able to dump
the  Recipe class all together and just go with MenuItem...what do you
think about that?

4.  I don't quite understand the conversions.  However, my feeling is that
they are not neccessary objects; they may be just some of the
specific-behiviors (methods -- doing some calculations in some Interfaces)

***  I think you're right about the  conversions, they most likely are
just  behaviours;  this has been the biggest trouble spot for the app,
as   the  client  wants  to  be  able  to  make  up  their  own custom
conversion,   sort   of   like   saying:  " one smear == 2.0 ounces of
butter",  then  being able to specify smear as a weight/measure in the
app  and  have the application understand that they mean 2.0 ounces of
butter.

Thanks much.

Hi Peter,

Form the design point of view, association between two objects means that
from one, the app. can refer to the other; From the implementation point of
view, an assocation is normally interpreted into an aggregation.  In this
instance, I would implement the MenuItem to be the container for the recipe.
By the way, when you say one-to-one relationship, you actually mean an
association; not an extension.  That means both entities must physically
exist at the same time.  The Is-a relationship does not require that; it
just talks about "type" - a truck is a car; implying some car behaviours in
truck; may be just one existence, which is truck.

The conversion may be modelled as some sort of utility object that know how
to do some conversions.

There may be some UI object to interacting with user; this kind of objects
is also of utility kind.

Summary:

Data Objects:  ojbects that have some internal data forming a inheritance
hierachy.  They employ (contain) some sort of Database Tier object to work
with the database; They are call by UI objects

Database Objects:  to implement the access to the DB.  If you need to change
the database, only this logic within these/this object(s) need to be
modified

Business Logic objects:  extending (implementation inherit) Data objects,
implementing (design inherit) some specific Interfaces such as: MenuItem,
Recipe etc

UI objects: to implement forms to interact with user.  If the set of form is
large and complex, implement as a inheritance hierachy here.

Utility Objects:  for some mathematic calculation or similar static
behaviours.

Cheers,
Tuong
-----Original Message-----
From: Peter Simard [mailto:peter@p...]
Sent: Wednesday, 2 October 2002 9:51 AM
To: Application Development
Subject: [application_development] RE: Ideas for this food-costing
application



Hi Tuong;

Thanks for you response.  Points 3 and 4 are of particular note:
3.  I cannot see the relationship between MenuItem and Recipe as an "Is-a".
They are definitely associated to each other, but an object of MenuItem type
can not be one of Recipe.

**My thinking here is that a recipe is the base upon which a menu-item
is  created:  a one to one relationship.  But we might be able to dump
the  Recipe class all together and just go with MenuItem...what do you
think about that?

4.  I don't quite understand the conversions.  However, my feeling is that
they are not neccessary objects; they may be just some of the
specific-behiviors (methods -- doing some calculations in some Interfaces)

***  I think you're right about the  conversions, they most likely are
just  behaviours;  this has been the biggest trouble spot for the app,
as   the  client  wants  to  be  able  to  make  up  their  own custom
conversion,   sort   of   like   saying:  " one smear == 2.0 ounces of
butter",  then  being able to specify smear as a weight/measure in the
app  and  have the application understand that they mean 2.0 ounces of
butter.

Thanks much.

I missed the point about dropping Recipe.  It would entirely depend on the
fact that you consider recipe as Data only or there are some significant(not
from the mentioned basic data action) action against those data.  If a
recipe just some chunk of text then, recipe should not exist as an object.
The picture may depict just a class, say "disk":

- disk extends some basic data class;
- disk contains its recipe
- disk has name

Some Menu can then interact with "disk" to get the name for displaying on
the menu.
Some UI object can request disk for it recipe.

You can see the discussion can open several possiblities.  The fundamental
idea is to use the Abstract Interfaces for specific behaviour definitions to
enable polymorphism and Class Inheritance to allow basic Data Activities to
be inherited.

Also, separate your application in tiers to have a modular design; that
would help the scalability and maintenance of the application.

Good luck.
Tuong
-----Original Message-----
From: Peter Simard [mailto:peter@p...]
Sent: Wednesday, 2 October 2002 9:51 AM
To: Application Development
Subject: [application_development] RE: Ideas for this food-costing
application



Hi Tuong;

Thanks for you response.  Points 3 and 4 are of particular note:
3.  I cannot see the relationship between MenuItem and Recipe as an "Is-a".
They are definitely associated to each other, but an object of MenuItem type
can not be one of Recipe.

**My thinking here is that a recipe is the base upon which a menu-item
is  created:  a one to one relationship.  But we might be able to dump
the  Recipe class all together and just go with MenuItem...what do you
think about that?

4.  I don't quite understand the conversions.  However, my feeling is that
they are not neccessary objects; they may be just some of the
specific-behiviors (methods -- doing some calculations in some Interfaces)

***  I think you're right about the  conversions, they most likely are
just  behaviours;  this has been the biggest trouble spot for the app,
as   the  client  wants  to  be  able  to  make  up  their  own custom
conversion,   sort   of   like   saying:  " one smear == 2.0 ounces of
butter",  then  being able to specify smear as a weight/measure in the
app  and  have the application understand that they mean 2.0 ounces of
butter.

Thanks much.

How about currency?  more detail, if possible.

-----Original Message-----
From: peter@p... [mailto:peter@p...]
Sent: Tuesday, October 01, 2002 6:26 PM
To: Application Development
Subject: [application_development] Ideas for this food-costing
application


I'm developing ( in JAVA ) a food costing application.

I've got the following as basic ideas, but if anyone can offer more
features, ideas, etc please jump in...

Specifications for food-costing application:

Program must be able to do the following:
*	Accept user input of data
*	Accept user modification of data
*	Delete data
*	Calculate food cost per item
*	Access MySQL database via web
o	Perform Queries
        	Select, Insert, Delete, Update
*	Create custom conversion units based on weight associations
and use these conversion in calculations as needed
*	Generate reports
*	Inform users of updates to database

Potential Objects

*	Recipe->is a collection of ingredients prepared in a specified
manner
*	MenuItem -> is the result of executing a recipes? instructions
*	Ingredient ->is a specific item used in a recipe
*	UnitOfMeasure -> the weight applied to an ingredient
*	User
*	CustomConversion

Objects::fields
*	Recipe
o	   Ingredient(s) array
o	   Instruction(s)
o	   FoodCost
o	   RecommendedSellPrice
o	   Yield
o	   MenuItemCategory

*	MenuItem extends Recipe
o	   menuLevel (lunch, special dinner etc?)
o	   actualSellPrice
o	   menuClass ( app, entrée, special, desert etc?)

*	Ingredient
o	   nameOfIngredient
o	   costOfIngredient
o	   yieldOfIngredient
o	   weightOfIngredient
o	   inventoryCountingFactor
o	   prepNote //an ingredient specific instruction

*	UnitOfMeasure
o	   unitName
o	   unitWeight
o	   unitWeightType

*	CustomConversion
o	   conversionIngredient
o	   conversionMultiplier
o	   conversionWeight
o	   Ingredient
o	   ingredientMultiplier
o	   ingredientWeight
*	User
o	   userNameFirst
o	   userNameLast
o	   userUserName
o	   userPassword
o	   userAccessLevel
o	   lastLogin
o	   accountCreationDate
o	   userEmail

Tuong;

You've  given  me  a  lot  to  think  about, and I appreciate all your
input!!


The  more  I think about the Recipe vs MenuItem object I'm inclined to
make  a recipe something that can be derived from the data inherent to
MenuItem.   Maybe  have  a  method  createRecipe()  that pulls  all  the
pertinent data together and enables it's display.

Also, many thanks for this clarification:

"By the way, when you say one-to-one relationship, you actually mean an
association;   not   an  extension.  That  means  both  entities  must
physically  exist  at  the  same  time. The Is-a relationship does not
require that; it just talks about "type"  "

As for the currency question that Angelito raises;

The  currency  is to be in US dollars, as this is an application to
be used by a small restaurant company here in the US.

Back to the drawing board, or keyboard as the case may be.

Cheerio!!