Comments:

Flat Nested Threaded Embedded

Oldest First Newest First

Author	Thread:
George Cassles	Bid Package UML model posted Posted: Thursday, March 24, 2005 4:05 PM (EST) I am not knowledgeable in the area of construction data or practices so I cannot comment on whether or not more attributes are needed. The Bid Package UML model, however, is clearly expressed and easy to understand. It is easy to see how this may be turned into a useful schema for this business area. One thing I coulden't understand was, when the StreetAddress Stereotype was referenced by the Bid Letting Class, are all of the elements within the stereotype required to be included. Some of the stereotypes appear to contain elements where one and only one is to be chosen and others seem to require that all elements be included. I don't know whether there is a notation for designating this, but it should be documented. May be this is just my unfamiliarity with UML modeling showing itself.
Bob DeHoff	Bid Package UML model posted Posted: Thursday, March 24, 2005 5:56 PM (EST) Thank you for your feedback George.  In UML notation, you indicate how many instances of an attribute a class instance can have using the [x..y] notation after the attribute name.  For example, in the StreetAddress data type class definition, the notation “street [1..n] : String” indicates that an attribute that has the StreetAddress data type must have at least one street string and it can have multiple street strings. If an attribute has no “[x..y]“ notation, it is implicitly [1].  The attribute is required and there can only be one instance of it in the object.  For example, “cityName : String“ indicates that a StreetAddress must have one and only one city name. The postalCodeExtensionID attribute of StreetAddress is probably one that should be optional.  The notation for this is “postalCodeExtensionID [0..1] : Integer”.  We will make it so in the model.
Todd Bergland	Bid Package UML model posted Posted: Monday, March 28, 2005 7:56 AM (EST) Below you will find comments from the Minnesota Department of Transportation as it pertains to the Bid Package.  The comments are isolated by the individual classes. Mn/DOT would like to see the following information added or clarified in the document.    1.  Bid Letting Class             - Add Date of Advertisement - it is important to note when the add was sent out for the Bid Letting.              - Does ID = Contract Number or Job Number?             - Add a Federal Number - Mn/DOT tracks both Job Number and Federal Number   2.  Project Milestone Class           - In regards to timeAvailable and timeChange Method are these intended to be working days and calendar days?  Mn/DOT would like to see these attributes changed to reflect this terminology. If this is not the intent of these attributes Mn/DOT would like to see them added.   3.  ContractPayItem Class          - Change the attribute fixedPrice to BidPrice   4.  ContractProvision Class         - Is this intended to refer to Special Provisions?   5.  Proposal Amendment Class        - Need an attribute to track if an amendment was added/modified or deleted. This would also pertain to if changes were made to the amendment.  6.  UnitofMeasure Class       - Does name = Units?         By Units we refer to (Cu. Yds, SY, Gallons, Tons)
Bob DeHoff	Bid Letting Class Posted: Monday, March 28, 2005 10:35 AM (EST) Thanks for your input Todd. 1. Bid Letting Class The intent when we were developing the model is that the Bid Letting class represents the letting event and the associated Proposal class instances represent the individual proposals that will be let at the letting.   We do need to have advertisement date in the model.  Do you see it being an attribute of the Bid Letting event or of an individual Proposal?  There may be cases where some Proposals in a Bid Letting are advertised on different dates, so should advertisementDate be a Proposal attribute? BidLetting.ID is intended to be a unique identifier for the Bid Letting event.  The Proposal.ID would be the primary identifier of the proposal - probably what would typically be come the primary identifier for the awarded contract. You mentioned Contract Number, Job Number, and Federal Number.  Would MnDOT be mapping their Contract Number to Proposal.ID?  Can you elaborate on Job Number and Federal Number?  Are these just additional attributes of the Proposal or do they represent other classes that are in some way associated with the Proposal class?
Bob DeHoff	Proposal Milestone Class Posted: Monday, March 28, 2005 10:37 AM (EST) 2. Proposal Milestone Class The timeAvailable attribute is intended to represent the number of days in which the milestone is to be completed.  The timeChargeMethod attributed is intended to represent the method by which time charges will be assessed on the milestone.  The TimeChargeMethod Enumeration stereotype indicates the three time charge assessment methods: for each calendarDay between the time charge start and stop points, for each availableDay between the time charge start and stop points, or with respect to a predefined completionDate. Todd, you are recommending that the TimeChargeMethod enumeration availableDay value should be workingDay instead?  Is that correct? Other participants, if you have input on this, please chime in.
Bob DeHoff	Contract PayItem Class Posted: Monday, March 28, 2005 10:45 AM (EST) 3. Contract PayItem Class The fixedPrice attribute is intended to be used in cases where the agency has predetermined the price that contractors must bid for a PayItem.  An example is the case where the agency will be furnishing the materials for the PayItem. The bid price attribute would come into play in the bid submission workflow.  The scope of the BidPackage schema defined for the TransXML project is for publication of a bid package by the owner agency to interested organizations.  The bid submission workflow is a good candidate for future expansion of the TransXML schema.
Bob DeHoff	Proposal Amendment Class Posted: Monday, March 28, 2005 11:14 AM (EST) 5. Proposal Amendment Class Encoding the specific changes that result from an amendment in the BidPackage instance document would require a more elaborate model.  The model would have to include both the current and previous state of the changed elements in the proposal. The approach taken to modeling ProposalAmendment is in essence a Proposal versioning approach.  A given BidPackage instance document represents the state of the Proposal that results from the cumulative application of the ProposalAmendments identified in the document, up to and including the most recent ProposalAmendment specified. Systems that require the specific changes made by an amendment can derive them by comparing the BidPackage XML instance document version that corresponds to the amendment against the previous BidPackage XML instance document. This approach neither constrains nor encodes the specific changes in the Proposal state that result from the amendment.  An amendment could change the proposal in any way, including adding, changing, or removing any elements including things such as pay items, milestones, or contract provisions. Please provide feedback on the viability of this simpler model of the amendment process.
Bob DeHoff	Responses to Todd Bergland comments 4 and 6 Posted: Monday, March 28, 2005 11:19 AM (EST) Todd's comments 1, 2, 3, and 5 required some detailed explanation, so I posted a separate response for each. Thank you for your feedback Todd. 4. Contract Provision Class Yes, the ContractProvision class represents the contract special provisions. 6. UnitofMeasure Class Yes, name refers to the “short name” associated with the unit of measure.
Todd Bergland	Bid Letting Class Posted: Wednesday, April 13, 2005 9:06 AM (EST) Bob, Sorry for the delay on your queries. Below you will find responses from Mn/DOT Do you see it being an attribute of the Bid Letting event or of an individual Proposal?  Very good point regarding the date for a Bid Letting and Proposal.  Mn/DOT actually utilizes both. For normal projects Non Design Build the date would only be applied to the Bid Letting Class as the proposals only become available at the time the Bid Letting is advertised.  However, things are entirely different for Design Build as the proposals are available prior to the actual Bid Letting and advertised date. You mentioned Contract Number, Job Number, and Federal Number.  Would MnDOT be mapping their Contract Number to Proposal.ID?  Can you elaborate on Job Number and Federal Number?  Are these just additional attributes of the Proposal or do they represent other classes that are in some way associated with the Proposal class? Yes, Mn/DOT maps there Contract Number to the Proposal ID.  Yes, Job Number and Federal Number are additional attributes of the proposal.  This to Mn/DOT refers to the State Project Number.  The Federal number is an additional attribute on top of the Job Number.  Federal numbers are important to Mn/DOT in order to distinguish federal funding codes.
Todd Bergland	Proposal Milestone Class Posted: Wednesday, April 13, 2005 9:26 AM (EST) Todd, you are recommending that the TimeChargeMethod enumeration availableDay value should be workingDay instead?  Is that correct? Yes, we are recommending that the enumeration type be workingDay instead of availableDay.  As you indicated I would be curiuos to see what others think..
Bob DeHoff	Bid Package UML model draft #2 posted Posted: Thursday, April 21, 2005 5:32 PM (EST) The second draft of the Bid Package UML model has been posted in the Construction/Materials Schema Working Group Documents area here: http://www.transxml.net/Construction+Materials+Schema/Group+Documents/Downloads_GetFile.aspx?id=511 Comments on this draft are requested by May 6th, 2005.  Please post your comments as responses to this thread.  If you need more time for this review, or you have any questions please send an email to transxml@camsys.com. Following is a summary of the changes made to the first draft: Added Proposal.datePublished. Added BidLetting.datePublished. Changed TimeChargeMethod availableDays to workingDays. Changed ContractPayItemGroupID from ID data type to String data type. Added ContractIDType data type and associated ContractIDScheme code list. Added Proposal.contractID of type ContractIDType. Added additional context diagrams. Refined attribute multiplicity, including postalCodeExtensionID. Added attribute descriptions. Refined navigability of associations.
Todd Bergland	Bid Package UML model draft #2 posted Posted: Thursday, May 05, 2005 3:46 PM (EST) Bob, In relationship to the Proposal class.  Do we view this class as a combination of projects lumped together to form a proposal?  Therefore there would be no reason to have a underlying project class is this correct?
Bob DeHoff	Projects in Bid Package Posted: Friday, May 06, 2005 10:37 AM (EST) That is correct, Todd. The Bid Package is the proposal view of the work - the view the contractor sees. The fact that a given proposal may be composed of one or more projects due to considerations such as funding is typically invisible to the contractor.