COMMUNICATIONS OF THE ACM April 2002/Vol. 45, No. 4 109In my previous column Iintroduced the concepts ofenduring business themes(EBTs) and business objects(BOs) as essential artifacts used toachieve software stability [2, 3].This third case study comparesand contrasts a classical modelbuilt by an expert in the field ofsoftware engineering, Peter Coad,and a model of the same prob-lem based on Enduring BusinessThemes and Business Objects.The project is to create a ware-house tracking system allowinggoods storage and order filling tobe performed more quickly andmore efficiently. The warehouse isphysically organized into aisles ofbins. Each bin contains items, andeach pair of bins and items has aline item associated with them forclerical purposes. Items arrive atthe warehouse on pallets. Sincepallets do not have to contain thesame item, they also have lineitems for clerical purposes. Whena customer places an order, thatorder and the line items on it aretranslated into a pick list and listline items. The items indicated bythe pick list are finally retrievedfrom their appropriate locations inthe warehouse and moved to theloading dock for shipment. Thetracking application must alsokeep track of customer informa-tion and customer organizationsto better serve repeat customers.Coad’s model of this problem[1] has several aggregations andfinely intertwined relationshipsbetween classes. Many of theseclasses could be classified as Indus-trial Objects (IOs). Consequently,minor changes to this systemcould result in major changes tothis model and would require areengineering process to fix. Find-ing EBTs for a warehouse trackingsystem is no trivial task. However,once it is done and if it is doneproperly, the resulting model willbe far more stable and robust tochange.Warehouses are used, of course,for storing goods. Thus, one ofthe obvious EBTs that should beincorporated into the modelshould be goods storage. Peoplealso want their goods stored andretrieved in a timely manner.Therefore, the warehouse must berun and the storage systems mustbe structured efficiently. It is easyto see that efficiency is anotherEBT worth consideration. OtherEBTs that immediately come tomind are shipping, receiving,order handling, customer service,and movement of goods.There are several BOs involvedin a warehouse. Several of themexist in [1]. First and foremost,the warehouse itself is a BO. Thegoods to be stored are also BOs. Itdoes not matter to the systemwhat goods are being stored. Tothe system, goods are goods. In[1], the “Item” class representsgoods, so, for consistency’s sake,they will remain members of the“Item” class in the EBT-basedmodel. Customer, organization,and order, from [1], are also BOs.The rest of the objects in hismodel, however, are IOs. Theycan all be changed completelywithout changing the basicpremise of a warehouse.Although this may not appearobvious, the EBT-based model isfar more adaptable. Most of theassociations between classes havebeen moved to associationsbetween EBTs and between BOs,which will never change in sucha way as to affect the system. Allthe changes will occur in theIOs, which have been movedtoward the periphery of the system.How to Deal with SoftwareStabilityTERRY MIURAMohamed E. FayadAll that exist are heuristics for determining an EBT, a BO, or an industrial object.110 April 2002/Vol. 45, No. 4 COMMUNICATIONS OF THE ACMIdentification HeuristicsSome heuristics for findingenduring themes immediatelycome to mind. Identification ofEBTs and BOs does not comeeasily. Engineers used to classicalmethods of object-oriented mod-eling will have to change theirthought processes drastically tocope with these new concepts.These heuristics are designed toease this transition in thought.First and foremost, EBTs andBOs must be enduring. In otherwords, they must be stable overtime. In many cases, determiningwhether or not something isenduring simply takes experiencein a given field. However, most ofthe time it takes a little more.Field experience allows one toknow how long given concepts orobjects have been involved with agiven system. A long history in thefield, however, does not necessarilytranslate into longevity in thefuture.Determining whether or not anobject will be enduring takes aknowledge of the system, a mod-icum of intuition, and commonsense. It is obvious that a newprocess introduced to a system isless likely to be enduring than aprocess that has had a place in thesystem for years. However, as evi-denced by the now infamous “mil-lennium bug,” not even amillennium of time can always beconsidered enough time for some-thing to become enduring.Industrial Object IdentificationIdentifying IOs is easy. Usually,the objects one designs into a clas-sical object model are IOs. Todetermine whether an object is anIO, one must simply ask: “Canthis thing be replaced with some-thing else? Will the system remainviable if some other objectreplaced this one?” If the answerto either of these questions is“yes,” then the object is mostlikely an IO.One should also look at the“tangibility” identification crite-rion. If the object represents somephysical entity, that object is verylikely to be an IO. If it representsa piece of machinery, a button, aninput device, or an output system,it must be replaced any time thephysical entity it represents isreplaced. Thus, it should be con-sidered an IO and placed towardthe periphery of stable designs.Top-Down IdentificationOnce one gets a feel for identify-ing IOs, identification of BOsand EBTs becomes far easier.There are at least two viablemethods for finding BOs andEBTs. One method is to take atop-down look at the system.Start with the whole system.Thinking ObjectivelyPalletnumberPalletLineItemquantity quantitybuildPickListOrderLineItemnumbershippingDateshippingAddressOrderquantityNeededquantityPickedAislenumberPickLlistPickLlistLineItemdate1+1+BinnumberisEmptyisAvailableForPalletfindbinForPalletwarehousenamefindBinForPalletBinLineItemquantitydecrementQtyLoadingDocknumberCustomernumberaddressnumberdescriptionItemOrganizationnameFigure 1. A model of a warehousetracking system [1].COMMUNICATIONS OF THE ACM April 2002/Vol. 45, No. 4 111Then, start breaking off concep-tual pieces of the system. “Whatis the system used for? Whatmust it be? Why are we buildingthis system?” For example, in akitchen, the system serves as ameeting area and a living areaand is used for preparing food.Warehouses, as another example,store commodities, serve
View Full Document
Unlocking...