Case Study CTTS - Milestone 07 Object Analysis Solution
Case Study CTTS - Milestone 07 Object Analysis Solution
Page: 7-1
Prepared by Gary B. Randolph for Systems Analysis & Design Methods 6ed by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 7-2
System Sequence Diagram Below is one solution for one scenario of the use case. Answers may vary. Check for proper UML notation of the input messages as well as for the logic of the diagram.
Prepared by Gary B. Randolph for Systems Analysis & Design Methods 6ed by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 7-3
Potential Object List Again, answers could vary somewhat depending on student assumptions, although the objects and their relationships should be fairly clear from the list.
Potential Object Address Bar Code Client Client Name Component Type Configuration Contact Name Date Installed Date Purchased Date Removed LAN IP Email Equip Name Equip Type Notes The street address, city, state, and zip of a client A unique identifier stamped on each component in inventory or installed in equipment. Someone who Coastline works for. They may own equipment serviced by Coastline. The name of the client. A classification of components, such as NIC, video card, mouse, keyboard, etc. A software configuration setting for the client. The first and last name of the contact person for a client. The date a component was installed in a piece of equipment. The date an inventory item was purchased. The date a component was removed from a piece of equipment The IP address of a piece of equipment on a client network. The client's e-mail address. Each piece of equipment can be given a name. We need to track whether a piece of equipment is a PC, a printer, a network device, or something else. Equipment that is owned by a client and serviced by Coastline. Equipment is made up of its components. Some components are an entire computer or printer (because they are purchased as a unit). Some are component pieces such as monitors, mice, etc. The ending time for a work record. When a piece of equipment was placed in service. Obj X X X X X X X X X X Instance of Configuration Attribute of Client Attribute of Equipment Attribute of Equipment Attribute of Equipment Component Attribute of Client Attribute of Equipment Component Attribute of Client Reason Attribute of Client Attribute of Inventory
X X
Prepared by Gary B. Randolph for Systems Analysis & Design Methods 6ed by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 7-4
A synonym for Service Request Attribute of Service Request Attribute of Equipment Component
Attribute of Work Record A specialized type of User Attribute of User. The User object can be inferred from User Name and User Password. Attribute of User
X X
User Password
Prepared by Gary B. Randolph for Systems Analysis & Design Methods 6ed by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 7-5
Prepared by Gary B. Randolph for Systems Analysis & Design Methods 6ed by J. L. Whitten, L. D. Bentley, & K. C. Dittman
Page: 7-6
Class Diagram Again, answers could vary somewhat depending on student assumptions. One solution is shown below.
Class diagrams should not include foreign key attributes. Foreign key is a relational database concept that is not used in object-oriented analysis. The Gen/Spec hierarchy can be inferred from the User object. Some students might try to make a Gen/Spec relationship with EquipType and Equipment. If the data storage requirements or behaviors were different for the various EquipType instances, then a Gen/Spec can be justified. But the provided solution is based on the assumption that all types of equipment would have an equipName and a dateInservice and no other data attributes. A case could be made for leaving EquipType and ComponentType off the object list and the class diagram. They mainly exist to provide lookup capabilities for Equipment and EquipmentComponent, which is essentially an implementation issue.
Prepared by Gary B. Randolph for Systems Analysis & Design Methods 6ed by J. L. Whitten, L. D. Bentley, & K. C. Dittman