Using the Input Job Variable Costs' use case and the information, both below, create a sequence...

 

 

 

 

Transcribed Image Text:

Using the Input Job Variable Costs' use case and the information, both below, create a sequence diagram illustrating a Team Leader (TL) updating a Job's variable costs at the completion of a job. The TL has to enter: a list of notes about the job a list of which employee(s) worked and and for how long a list of material used and amount a list of the vehicle(s) used and mileage driven a list of special equipment used and the time used a list of equipment rented and its cost The following list identifies each class's message(s) and its structure or signature (that we are concerned with here): Message structure or signature: findJob (jobld) : jobObject updateJob (className, list) submitJob () updateJob (className, list) updateNotes (noteList) updateLabor (laborList) updateMaterial (materiaList) updateMileage (vehicleList) updateSpecialEquipment (equipmentList) updateRentedEquipment (rentalList) Class name: App Job Notes Labor Material Vehicle Equipment Rental Constraints: The TL will CONLY interact with an App object. The App object sends messages only to a Job object. The Job object can communicate with any of the other objects. We are not concerned with the user interface classes and objects at this time. We are analyzing the business process of a TL inputting job data, not designing the user interface. Each object stores the inputted data in internal attributes (in memory) as part of the call to the updateXXX () message. We will define the actual data storage and forwarding in a later iteration, so don't worry about that now. The TL's data input is complete when the TL indicates that all data has been inputted, i.e., submitJob () is called. That is a stub to be completed when we decide how to Each object stores the inputted data in internal attributes (in memory) as part of the call to the updateXXX () message. We will define the actual data storage forwarding in a later iteration, so don't worry about that now. The TL's data input is complete when the TL indicates that all data has been inputted, i.e., submitJob () is called. That is a stub to be completed when we decide how to accomplish the actual storage and forwarding of the data. and Notes: An App object is instantiated automatically from the App class when the application Printed on 3/22/20 Page 1 of 3 pages is started. This means that the App object is in existence from start to finish. When the App object's findJob () message is called, it automatically instantiates a Job object based on the Job class and returns a reference to that Job object. You do not need to worry about modeling this message, but the Job object's "execution occurrence" must reflect this. As the TL inputs each type of data, the Job object automatically creates and holds a reference to an appropriate object instantiated from its class Notes, Labor, Material, Vehicle, Equipment, and Rental. For example, when the TL inputs notes, the Job object will instantiate one notes object from the Notes class. When the TL inputs labor, the Job object will instantiate one labor object from the Labor class, etc. 4. Again, you do not need to worry about the calls to create the objects, but each object's "execution occurrence" must indicate when it was created. Once created, objects remain in existence until the application is shut down. All data input will be in the form of a List. Each object knows how to parse its own list. Every list is comma delimited with two fields, for example: a laborList might look like this: 3. 5. 6. a labori might look Hke this! Emp3, 4 Emp1, 8 a vehicleList might look like this: Van1, 20 Truck1, 58 Input Job Variable Costs Use Case Use case name Input Job Variable Costs At the completion of a job or the end of the work day, the Team Leader (TL) inputs the following variable job costs: Notes Labor hours used by Employee ID Material used by Material ID and amount Vehicle miles used by Vehicle ID Special equipment used by Equipment ID and hours Scenario used Equipment rented by Equipment ID and cost Triggering event |Job completion or end of work day. This sequence of events is initiated by a Team Leader (TL) at a job site immediately upon completion of a job or the end of a work day. The TL inputs all the variable job costs before leaving the job site. Brief description Primary actor(s): Team Leader Supporting actor(s): Electrician Offstage actor(s): Customer Actor(s) Related use case(s) Manage Job Team Leader and Electrician: Want accurate pay Customer: Wants accurate invoice Stakeholder(s) Owner: Wants accurate data for billing, accounts payable, and payroll The team has worked at the job site and either the job is complete or the work day has ended. Precondition(s) Postcondition(s) All variable job cost data is accurately posted to the system Flow of Activities See below At any time, TL cancels the update Exception Condition(s) At any time, the System fails Flow of Activities: Actor Actions: System Responsibility: 1. TL chooses to update Job data 2. Presents application 3. TL chooses a Job by Job ID 4. Retrieves and displays selected Job 6. Retrieves and displays a blank input for the selected variable cost item 5. TL selects variable cost item 7. TL enters variable cost item data 8. Stores variable cost item data Steps 5 through 8 repeats until all data is inputted 10. Sends information to external systems 9. TL indicates all items entered and presents a confirmation to the user Using the Input Job Variable Costs' use case and the information, both below, create a sequence diagram illustrating a Team Leader (TL) updating a Job's variable costs at the completion of a job. The TL has to enter: a list of notes about the job a list of which employee(s) worked and and for how long a list of material used and amount a list of the vehicle(s) used and mileage driven a list of special equipment used and the time used a list of equipment rented and its cost The following list identifies each class's message(s) and its structure or signature (that we are concerned with here): Message structure or signature: findJob (jobld) : jobObject updateJob (className, list) submitJob () updateJob (className, list) updateNotes (noteList) updateLabor (laborList) updateMaterial (materiaList) updateMileage (vehicleList) updateSpecialEquipment (equipmentList) updateRentedEquipment (rentalList) Class name: App Job Notes Labor Material Vehicle Equipment Rental Constraints: The TL will CONLY interact with an App object. The App object sends messages only to a Job object. The Job object can communicate with any of the other objects. We are not concerned with the user interface classes and objects at this time. We are analyzing the business process of a TL inputting job data, not designing the user interface. Each object stores the inputted data in internal attributes (in memory) as part of the call to the updateXXX () message. We will define the actual data storage and forwarding in a later iteration, so don't worry about that now. The TL's data input is complete when the TL indicates that all data has been inputted, i.e., submitJob () is called. That is a stub to be completed when we decide how to Each object stores the inputted data in internal attributes (in memory) as part of the call to the updateXXX () message. We will define the actual data storage forwarding in a later iteration, so don't worry about that now. The TL's data input is complete when the TL indicates that all data has been inputted, i.e., submitJob () is called. That is a stub to be completed when we decide how to accomplish the actual storage and forwarding of the data. and Notes: An App object is instantiated automatically from the App class when the application Printed on 3/22/20 Page 1 of 3 pages is started. This means that the App object is in existence from start to finish. When the App object's findJob () message is called, it automatically instantiates a Job object based on the Job class and returns a reference to that Job object. You do not need to worry about modeling this message, but the Job object's "execution occurrence" must reflect this. As the TL inputs each type of data, the Job object automatically creates and holds a reference to an appropriate object instantiated from its class Notes, Labor, Material, Vehicle, Equipment, and Rental. For example, when the TL inputs notes, the Job object will instantiate one notes object from the Notes class. When the TL inputs labor, the Job object will instantiate one labor object from the Labor class, etc. 4. Again, you do not need to worry about the calls to create the objects, but each object's "execution occurrence" must indicate when it was created. Once created, objects remain in existence until the application is shut down. All data input will be in the form of a List. Each object knows how to parse its own list. Every list is comma delimited with two fields, for example: a laborList might look like this: 3. 5. 6. a labori might look Hke this! Emp3, 4 Emp1, 8 a vehicleList might look like this: Van1, 20 Truck1, 58 Input Job Variable Costs Use Case Use case name Input Job Variable Costs At the completion of a job or the end of the work day, the Team Leader (TL) inputs the following variable job costs: Notes Labor hours used by Employee ID Material used by Material ID and amount Vehicle miles used by Vehicle ID Special equipment used by Equipment ID and hours Scenario used Equipment rented by Equipment ID and cost Triggering event |Job completion or end of work day. This sequence of events is initiated by a Team Leader (TL) at a job site immediately upon completion of a job or the end of a work day. The TL inputs all the variable job costs before leaving the job site. Brief description Primary actor(s): Team Leader Supporting actor(s): Electrician Offstage actor(s): Customer Actor(s) Related use case(s) Manage Job Team Leader and Electrician: Want accurate pay Customer: Wants accurate invoice Stakeholder(s) Owner: Wants accurate data for billing, accounts payable, and payroll The team has worked at the job site and either the job is complete or the work day has ended. Precondition(s) Postcondition(s) All variable job cost data is accurately posted to the system Flow of Activities See below At any time, TL cancels the update Exception Condition(s) At any time, the System fails Flow of Activities: Actor Actions: System Responsibility: 1. TL chooses to update Job data 2. Presents application 3. TL chooses a Job by Job ID 4. Retrieves and displays selected Job 6. Retrieves and displays a blank input for the selected variable cost item 5. TL selects variable cost item 7. TL enters variable cost item data 8. Stores variable cost item data Steps 5 through 8 repeats until all data is inputted 10. Sends information to external systems 9. TL indicates all items entered and presents a confirmation to the user

Answer rating: 100% (QA)

Use case name Input Job Variable Costs Scenario At the completion of a job or the end of the work da... View the full answer