Object and Data Modeling for a Car-Sharing System - Assignment Example

Object and Data Modeling for a Car Sharing System Table of Contents Part I: Analysis Report 3 Use Case Diagram 3 Overview use case model 3 Detailed design of the Use Case Model 4 Activity Diagrams (Behavior state machine diagrams) 7 Part II. Design Report 9 Class Diagram Description 10 Communication Diagram 12 Sequence diagram 14 Sequence Diagram (Client) 15 Sequence Diagram (Driver) 16 Conclusion 17 References 18 Part I: Analysis Report This section of the report focuses on the analysis of the business requirements for the intended Car Sharing System. A use case diagram is a simple demonstration of an end system users communication with the system. Describing the specifications of this particular case scenario entails two system users, that is, the driver and the client. The various functions that each end user can perform are also highlighted in the use case model. Use Case Diagram The system is intended for two end users, which makes up for the client and the driver. These two entities have the privileges to utilize the system and access the following functionalities: The client can do the following functions on the car sharing system platform: Can sign in into the system, Search for trips in the system database, Select a trip form a list of trips Pay for the trip The Driver can perform the following functions on the on the car sharing system platform: Can sign in into the system, Register the details of a car, Store the car information in the system database Post trip information and details An overview of the use case model is shown below for the car sharing system. Overview use case model Detailed design of the Use Case Model A detailed design of the case model aims to showcase all the major attributes of the systems functions expected to be accomplished by respective end users. The participants accessing the system, who can be either the diver or the customer, are both required to register on the system or sign up with their personal information. Personal information comprises of the names, sex, the users year of birth, mobile number, and email addresses of the system end users. The system is divided into a driver and client subsystem that categorically showcase the attributes and features required by the system. The registration details for sign up process are mandatory in order to allow automatic validation of the end user. The end users are expected to input additional information to support the subsequent data required for completing the sub-functions of the system. The sub-functions of the system simply include and extend other higher functions or authority within the system (SHOVAL 2007). For example getting registered on the system extends to being validated by the system. Including other use cases helps to reduce duplication of system functionalities for each user, therefore, describing other detailed parts of the system in the use case makes it easy to understand the hierarchy of actors (system end users) in the car sharing system as well. Car sharing system Allows registration with personal details Registration Details contain password and username information System verifies end user personal information Driver Subsystem Stores drivers personal information like address email, year of birth and other registration with personal details Registers driver’s car information details Registers trip details and posts them Client Subsystem Enables the client register on system Offers registration details for payment account Provides search engine capabilities to search for and select available trips posted by drivers or any car available for sharing The diagram below represents detailed description of the use case model: Activity Diagrams (Behavior state machine diagrams) An activity diagram relatively represents the flow of information within the system showing and illustrating the sequence of activities. The conditions for the information for each activity can also be described within an activity diagram. In the case of the Car sharing system, the activity diagrams that are presented include that of the Registration and Payment process. The activity diagram shows the start and stop process for each particular activity. Designing an activity diagram requires the coordination of execution of sub-functions using a control and data flow model. The activity diagram developed and created in this particular case invokes other activities via a level of hierarchy that executes and resolves particular functions (GEORGE 2007). For example, for an individual to sign up on the system, they have to key in data in a similar way depicted by the activity diagram below so as to store the information onto the system’s databank. The initial node represented by the big black dot while the activity final node is indicated by black dot that is circled. The activities for registration and making a payment are represented below also aid in the information modeling of the entire system through determining the system level processes. In an activity diagram, one action is accepted after the completion of a prior action; therefore each action defines a behavior and represents a single discrete element within the system. The activity diagram for the system is displayed below: Part II. Design Report This section of the report focuses on the description of the major system elements and illustrating how each of these components interacts with each other within the car sharing system. The design details also help in demonstrating how external entities interact or use the system components to execute an instruction. This is defined via the use of descriptive class diagram that highlights on all the information flow and shows the attributes that can be accessed by each user. The objects in this case are trip, client, driver and car while the functionality or operations expected of the system are communication, making a payment, validating or registration and performing a car search. The design elements implemented in the case functions and how they are linked to each class is also provided in the object description or object model for the car sharing system. The object model also describes the entire possible object oriented interfaces that are most likely to be involved with the car sharing system. For example in this case, the most likely interface that is involved includes the payment interface, the registration interface and the search interface. The basic purpose of an object diagram is to show the action and flow of response information within the system. Like shown below: Class Diagram Description Communication Diagram The communication diagram aids in modeling the dynamic behavior of the use case. It further helps in better understanding of how the end users interact with the system and the acceptable functionalities they can execute for the computer node. In this case scenario, the communication diagram represented shows the communication events that are instigated by the driver and the client respectively when accessing the system. The driver offers information regarding a planned trip. In turn interested clients access this information on the client interface end to find and view the posted trip information. So as to preserve the organization of messages or information flowing in the system, the free-form messages on the diagram are labeled to show the movement of information between the system and user (DENNIS, WIXOM & TEGARDEN 2005). The ordering is done using chronological numbers which are placed close to the link that shows how the message is sent over the system network. Interpreting a communication diagram involves beginning at message 1.0 as shown in the activity diagram. The subsequent actin includes following the messages from one object to another object. Sequence diagram There is a separate sequence for each user of the system. That is, the driver and customer interested in sharing a car. The diagrams provide a graphical representation of the object interactions over time. It also shows how the components interact to facilitate the execution of a use case. The flow of events within the system can be understood from the messages that are distributed among the different object in the system. The events of a sequence diagram explain how the class operations are implemented in the final model. The actor (client) desires to book a trip and accesses the car sharing system website application and prompts the system for particular outputs. The corresponding occurrence validated by the website confirms registration of the client and permits the client to carry out additional functions on the system. The sequence diagram represented below shows the actions instigated by the client to search for trips and select trips they are interested in. Sequence Diagram (Client) Sequence Diagram (Driver) Comparing the above design with the object-oriented system analysis and design principles, the notable approach that has been used in this case portrays the primary elements of object-oriented analysis (OOA). This is because the main tasks involved in the system analysis and design are implemented in the design report for the car sharing system. The undertaking of identifying the problem statement and designing an information model that uses object instances to define the behavior of the system (RAMNATH & DATHAN 2010). Furthermore object-oriented analysis (OOA) enables a system developer identifies involved objects, organize them, and describe how they interact via defining the internal attributes of the objects. Conclusion Developing and designing system models necessitate the elementary understanding of the structure of object-oriented software. It helps one acknowledge the benefit of the similarities between object-oriented and structured methods, particularly during the analysis stage of a software system. Proper event analysis and end user experience in data modeling is important and valuable in developing a system. Therefore, implementing a high-level system that possesses exceptional modularity and good software metric is essential for all object-oriented software systems. References DENNIS, A., WIXOM, B. H., & TEGARDEN, D. P. (2005). Systems analysis and design with UML version 2.0 an object-oriented approach. Hoboken, NJ, J. Wiley. http://app.knovel.com/web/toc.v/cid:kpSADUMLVA. GEORGE, J. F. (2007). Object-oriented systems analysis and design. Upper Saddle River, N.J., Pearson Prentice Hall. KENDALL, K. E., & KENDALL, J. E. (2005). Systems analysis and design. Upper Saddle River, NJ, Pearson/Prentice Hall. RAMNATH, S., & DATHAN, B. (2010). Object-oriented analysis and design. London, Springer-Verlag. SHOVAL, P. (2007). Functional and object oriented analysis and design an integrated methodology. Hershey, PA, Idea Group Pub. (an imprint of Idea Group). http://search.ebscohost.com/login.aspx?direct=true&scope=site&db=nlebk&db=nlabk&AN=164190. Read More