Item & ItemInHierarchy

Kevin Fairclough posted on Tuesday, September 29, 2009

Hi All

This is pretty much my first use case and I'm stuck already!

I have the following use case. Enter item details (which is a largish object with child collections) and also maintain a hierarchy of said items. However because the Item may be large in size I don't want the hierarchy to be the same Item type, hence ItemInHierarchy, also ItemInHierarchy should just display Name + No for each link aswell as some data about the link.

I'm leading to the idea of this being 2 use cases but I need them to be 1 save operation. When I save the Item it also saves any changes to the hierarchy.

I was think of having a child object in Item of type ItemInHierarchy, which managed the hierarchy and living with the duplicate Item/ItemInHierarchy at the root level. Does this seem feasible?

Any ideas, or advice/experience would be appreciated as I'm completely stuck. I have a blank canvas as its a new development.

TIA
Kevin

RockfordLhotka replied on Tuesday, September 29, 2009

First off, are Item and ItemHierarchy words your end users would understand? If not, that may be the root of your problem.

Use cases, or user stories, or user scenarios, are user-focused. It should be the case that the words you use to describe your objects are mostly the words used by a user to describe what they are trying to do.

Oh sure, later in implementation you might use somewhat more cryptic techie terms/names. But at the design stage things should be in the user-focused language.

In any case, your problem description is too vague for me to guess what you are trying to do. Is this like a bill of materials or something?

Kevin Fairclough replied on Tuesday, September 29, 2009

It is essentially a bill of materials, yes. Or at least the forerunner to a BOM.

I need a hierarchy of Items but my Item object is too heavy, hence the lighter ItemInHierarchy (my object not user requested).

The terms derived from user (given to me) are Item, Contains(Items) & Contained In(Items).

My main gripe was I need to pick Items in order to create the Contains hierarchy and this is where ItemInHierarchy came from. A lighter Item object that can be used to structure the items that are contained within the Item.

So do I have
Item.ItemContainsHierarchy.Contains.Add(itemInHierarchy) etc.?
or do I separate the hierarchies from Item object, if so how do I save then together, a command object?

Thanks for your time.

RockfordLhotka replied on Tuesday, September 29, 2009

I spent many years in manufacturing, which is why I thought this sounded somewhat like a BOM :)

I agree, when building a BOM structure, typically the items in the BOM aren’t the actual “items” or products. The use case isn’t to edit product information, it is to establish relationships between products.

So the BOM structure is a hierarchy of “item link” objects that usually contain a small number of read-only properties describing the actual item/product.

In this case, you’ll almost certainly have some ROL containing products so the user can pick a product to add to the BOM.

And you’ll have the BOM itself, which is an editable root.

I think the issue here is that the user says “Item” and that has two contextual meanings.

“Item” is something they pick to add to the hierarchy – and what they are really describing is a ROL of ItemInfo objects.

“Item” is also something in the hierarchy – and what they are really describing is a BB (editable child) in the hierarchy.

You just have to tease the two concepts apart and recognize that they aren’t the same thing within the use case.

Kevin Fairclough replied on Wednesday, September 30, 2009

You indeed must be happy away from the BOM!!! But it has returned for a short while to say hello Smile [:)]

In my case the "item link" has a mixture of read-only and editable fields. The read-only fields are part of the link display, i.e. Item Identifier, Name etc. I understand I need a read-only retrieval mechanism for these items to link. The link however must also be able to store other data such as qty, uom, fitted, sequence etc. hence my object ItemInHierarchy.

I now have the following concepts; Item(EditableRoot), ItemContainsBOM(?), ItemInHierarchy(EditableChild), ItemROList(ROLB of ROB) I also need a collection of ItemInHierarchy objects inside the ItemContainsBOM.

Do I need to separate the ItemContains(BOM) from the main Item root object even though they part of the same use case? is the ItemContains(BOM) as you say a separate root object? or can it be a child of the Item(EditableRoot)?

If I separate them to be two editable roots; Item, ItemContainsBOM, how do I save them together in one transaction? Do I also bring in a ItemSaver(Command)?

Thanks
Kevin

RockfordLhotka replied on Wednesday, September 30, 2009

Why would you separate Item and ItemContainsBOM?

We used the terms ‘product’ and ‘part’ to keep our sanity. A product is the top level item, and parts and the items in the hierarchy.

Product -> ComposedOfParts -> Part

Also of course

Part -> Composed of Parts -> Part

Because this is a hierarchy with potentially many levels of detail.

Different properties and rules were involved in a Product compared to a Part, so they (for us) were clearly different things.

Kevin Fairclough replied on Wednesday, September 30, 2009

There is no need to separate them, I was thrown when you said the BOM is the editable root. Where in my case the Item is the editable root. My use case is to create/edit Item and link it to sub-items n levels deep, therefore my BOM is an editable child?

My Item edit object is huge (or will be) and I don't want the Item in the hierarchy to be the same object type.

Kevin