International Construction Lease and Financing - Case Study Example

Case Study: International Construction Lease and Financing (UML) Faculty Table of Contents Introduction 1. Development Process 1.2. Object-Orientation 1.3. The Unified Modelling Language (UML) 2. Requirement Capture 2.1. Textual Analysis 2.2. Use Case 2.3. Use Case Diagram 2.4. Sequence Diagram 2.5. Class Diagram References: 1. Introduction This paper analyzes the case study of International Construction Lease and financing. In this paper, the various requirements of Cement Mountain Ltd., which is subsidiary of Acme Core is analyzed with the help of paradigm UML tool. The models used in the report will focus on selected areas of functionality of the proposed system while also indicating how different parts of the system would work together to provide Cement Mountain Ltd. with an information system that will enable them to manage its vehicle, equipments, bookings, delivery of equipments and vehicles, customer credit limit, accountings and payments. This paper will give details of Use Case Diagrams, Use Cases, Sequence Diagram and Class diagram of Cement Mountain Ltd information system. 1.1 Development Processes Traditional information system projects were developed using the Systems Development Life Cycle (SLDC) or ‘Waterfall Model’ to manage and implement the system. Designed in the 1960s this methodology sees the process split into a series of distinct steps: Inception Feasibility Analysis Design Implementation Maintain and review Using the above ‘top-down’ process each step cannot commence until the preceding step has been completed and the findings passed down the chain, at each stage a review can take place to ensure that the requirements identified in the previous stage have been met. In recent years, this development process has come to be seen as too rigid, one of the major problems with this process is that the timescale involved from the project inception to the stage of implementation is far too long. Problems and delays at each stage of the process often result in late delivery of a system. However, a more serious problem is that because the development process is so long the final system produced can be out of date by the time it is released for use. As time passes, user requirements for a system may evolve as a company embraces new working process or technology, it is easy for these changes not to be incorporated into the system being developed and as a result, the completed system may not be fit for its intended purpose. To try and combat these problems new Iterative development processes have been adopted. This new iterative approach involves breaking the entire project into small ‘chunks’ based on functionality, rather than looking to deliver a complete solution one year after the project starts as the traditional waterfall process does, this iterative style will look to produce a working solution in a few months. This initial solution will not be a complete solution containing all required functionality instead it will look to deliver an agreed subset of functionality and features, which users can look at comment on and suggest improvements. This initial system will then be pushed back through the development process again when additional features are added and modifications made, this process will keep taking place until a complete solution is delivered. This development style allows continuous improvement of the system and gives users a working system that they can start to use much more quickly. 1.2 Object-Orientation Object-Orientation Development can be a great help when using an iterative development process. Groups of objects can be identified that are needed to provide certain functions of a system, these groups of objects can be manipulated and modified to perform certain tasks, other objects can then be added to the system in order to expand functionality. This can result in usable systems being rolled out to users with limited functions and then increased functionality being introduced later. Examples of this can be seen in the way that online interfaces offered to customers by online retailers such as Amazon, the initial user interface provided basic functions to allow users to select the product they wanted and enter their details to purchase it, over time Amazon increased the functionality of the system providing users with options such as the ability to view related products or pick alternative delivery locations. 1.3 The Unified Modelling Language (UML) In recent years, UML has become the industry standard modelling language used in object-orientated design. UML consists of a series of 13 different types of diagram; these diagrams provide formats for designers to model the various different parts of a system. The diagrams can be split into two separate camps: Structure – Class, Composite Structure, Object, Component, Deployment & Package. These diagrams are concerned with the logical structure of a system and are used to indicate how the system will store information. Behaviour – Activity, Use Case, State Machine, Sequence, Communication, Interaction & timing. These diagrams are concerned with the functionality of a system and are used to indicate how the different components of the system can work together to perform the desired tasks. 2. Requirements Capture Cement Mountain Ltd. has taken the decision to implement a new information system to help them improve the service they offer to their users. When analysing the requirements of an information system of this type it is important to take into account the three principal areas of requirements, which are: Functional Requirements: These describe what a system is expected to do, or its functionality. These generally include the inputs that the system will have to record, the outputs the system is expected to produce and the types of data the system needs to store. Non-Functional Requirements: These describe aspects of the system that relate to how well the system fulfils its functional requirements. These generally include performance targets for the system and security and validity of the data held. Usability Requirements: These describe ways in which the system will aid its users to accomplish the tasks required of them. These requirements are often referred to as ‘ease of use’ or how intuitive the system is to use. This report will concentrate only on the functional requirements of the new system and it will be assumed that issues such as performance, security and usability will not be a problem. Potential areas for concern however could include; Usability: The new system will be user friendly and allow company’s operators to search vehicle and equipment records and make booking. In addition, it will be also so that it can allow maintenance and pool managers to maintain equipments and vehicles records respectively. In case of Cement Mountain Ltd. it is also important that the new system will allow checking the customer status and their credit limit so that payment schedule can be made if the credit limit breaches. Moreover, this system should also provide the functionality to clerk to enter the equipment and vehicle records going outside and coming to depot. Non-Functional: Security of data is always a major concern for any information system development especially those that are going to be accessible online (most systems these days). Companies have legal requirements (such as the Data Protection Act) to ensure that all personal data they hold about their customers is secure and not disclosed to third parties. Cement Mountain Ltd. will have to ensure that they have sufficient security in place to prevent unauthorised or malicious access to the data they hold. 2.1 Textual Analysis The Cement Mountain Ltd. case study can be analysed quickly to identify the major functional requirements of the new information system, quick analysis of a situation like this is referred to as ‘textual analysis’. This analysis identifies the following areas to be considered The system should be able to store the equipment and vehicle records The company’s operators can search the vehicle and equipment records and make bookings. Maintenance managers can maintain equipment records. Vehicle pool managers can maintain vehicle records. Customers can rent equipment and arrange deliveries. Function for contact the company and arrange a schedule of payments if credit limit for the customer breaches in the next four weeks. There should be a function for staff to input the rental record. There should be a function for staff for confirmation in the system by a clerk when the lorry goes or returns to the depot. The staff can use the system to check the availability of the equipment by using an equipment model number. From this initial textual analysis to identify functional requirements, it is possible to write up a series of ‘Use Cases’. A Use Case is written as a series of steps that a user or ‘actor’ must negotiate in order to achieve a particular goal. The purpose of a Use Case is to describe the interaction between the users and the system. A Use Case illustrates what the system is required to do not how a task will be accomplished. 2.2 Use Case Model 2 Cement Mountain Ltd Administration Use Case 1: Maintain Equipments/Vehicles Records Actor: Administrator (Staff: Maintenance manager and Vehicle pool manager) Pre Condition: Must have general details of equipments and vehicles to input information onto the system Trigger: The Administrator must input the details of new equipments and vehicles attribute or select the one that they wish to modify or delete Goal: To keep organized records of equipments and vehicles details. Summary: The Administrator can add, modify and delete equipments and vehicles records within the system. Use Case 2: Search Equipments/Vehicles Records Actor: Administrator (Staff: Company Operators) Pre Condition: Must have access of equipments and vehicles information from the system Trigger: The Company Operators on request from the customer search equipments database for making booking for the customer. Goal: To make booking for the customer by searching available equipments and vehicles. Summary: The Company Operators searches the equipments and vehicles details from the system for the booking and timely delivery of the equipments to the customer site. Use Case 3: Make booking of Equipments/Vehicles Actor: Administrator (Staff: Company Operators) Pre Condition: Must have searched the system for availability of equipments and vehicles. Trigger: The Company Operators will make booking for the required equipments/vehicle for which customer had requested. Goal: To make booking of equipments and vehicles for the customers Summary: The Company Operators will make booking after knowing the availability of equipment and vehicles on customer request. Use Case 4: Delivery/Picking of Equipments/Vehicles Actor: Administrator (Staff: Driver and Clerk) Pre Condition: Must have made booking of equipments and vehicles. Trigger: The driver will deliver the equipments/vehicle to customer and pick the equipments/vehicle from there to office. Goal: To make delivery and picking of equipments and vehicles to/form the customer’s site. Summary: The driver will make delivery of equipment and vehicles on customer site and will pick any equipment and vehicles to offices. Company’s clerk will enter these details into system. . Use Case 5: Check Credit Limit/Schedule Payments Actor: Administrator (Credit Clerk) Pre Condition: Must have access of customer credit limit details. Trigger: Credit clerk will check the credit limit of each customer and if it breaches the credit limit in the next four weeks than will arrange a schedule for the payments with customers. Goal: To keep credit limit of the customer and schedule payments. Summary: The credit clerk will regularly check the credit limits of each customer. If credit clerks founds breaching of credit limit on next four weeks than will contact company/customer and will make a schedule of payments with the customers. Use Case 6: Monitor and Approve Customers Actor: Administrator (Manager) Pre Condition: Must able to see or select the details of the Customers (Given by the Customers). Trigger: Administrator will select the Customers Details from the system and view their details to make a decision Goal: To keep real records, after deleting bogus records. Summary: Customers will provide details to Cement Mountain Ltd. The Administrator will then check whether the details are authentic or not. The Administrator will inform Customers if any required details are missing through mail or phone. After satisfying, Administrator will approve Customers. Cement Mountain Ltd (Customer) Use Case 7: Register at Ace Haulage Ltd Actor: Customer Pre condition: Must know how and where to register and provide details. Trigger: Customer register in any office nearby of Cement Mountain Ltd. Goal: To become a Cement Mountain Ltd customer/client Summary: The Client will provide registration details and later administrator will approve that. Use Case 8: Make Booking Actor: Customer Pre condition: Must have confirmed from Company operators for the availability of equipments and vehicles. Trigger: Customer make booking for the equipments and vehicles in any office nearby of Cement Mountain Ltd with the help of Company’s operator. Goal: To make booking at Cement Mountain Ltd. Summary: The customer will confirms with company’s operator regarding availability of equipments and vehicles and will make booking. Use Case 9: Take Delivery (rent) Actor: Customer Pre condition: Must have made booking. Trigger: Take delivery from the driver of the Cement Mountain Ltd Goal: To Take delivery of the equipments and vehicles from the Cement Mountain Ltd Summary: The Customer will take delivery from the drivers for the booking made previously. Use Case 10: Make Payment Actor: Customer Pre condition: Must have a schedule made with credit clerk. Trigger: The Customer will make payment to credit clerk of the Cement Mountain Ltd Goal: To make payment for the equipment and vehicle rented from the Cement Mountain Ltd Summary: the customer will make payment for the schedule of payment made by the credit clerk so that the credit limit is not breached. 2.3 Use Case Diagram Model 1 Figure1: Use Case Diagram The above example shows the different actors who use different components of the system as well as a selection of the Use Cases that they may initiate. The diagram also contains relationships between different Use Cases (marked with ). This use case diagram also shows the three types of actor that will use the system and they are Managers, Staffs and customers. 2.3 Sequence Diagram Model 3 Figure 2: Sequence Diagram The above figure shows the sequence diagram for the Cement Mountain Ltd. In the above diagram, the top of the part represents the objects that participate in the interaction. The sequence diagram emphasizes on the time ordering of messages. This can be seen with the complete booking of the equipments and vehicles made by the customer. At the start, the customer (object) confirms and asks staff to make booking of the equipments. In addition, the rest of the flow of message over time is represented in above sequence diagram on timely manner as one goes from top to down of the diagram. 2.4 Class Diagram Model 4 Figure 3: Class Diagram The models examined so far in this report have concentrated on identifying the functionality required of the new IS, the Class Diagram however identifies the different types of objects that exist in the system and the relationships between these objects. While still not getting too concerned with how the actual system will work the Class Diagram sets out what data can be captured and where this data will be stored. The above figure 3 represents the class diagram for the Cement Mountain Ltd information system. In this diagram, various classes that are shown are CustomerDetails for customer records, OfficeDetails for office records, Equipment, Vehicle, BookingDetails for booking of equipments and vehicles, AccountingSystem for making finances and checking credit limit, DeliveryDetails for equipment and vehicles delivery and picking, StaffDetails for staff records,Department, and InvoicesDetails for payment schedule records. The various attributes of classes and operations that can be performed are also shown in above class diagram. The relationships between the classes that can be there (one-to-one, one-to-many or many-to-many) are also shown in class diagram. The relationship is explained below point wise. The relationship between customer and booking is that customer makes booking of vehicle and equipments. Offices works for customer. Offices have many vehicles. Offices have many different types of equipments. Offices have one accounting system. Offices have different departments. Accounting system checks credit limit of customers. Accounting system is managed by staffs. Bookings have invoices. Bookings are done by staffs. Staffs perform delivery/picking of bookings. Staffs work in departments. Vehicles booked in booking. Equipments booked in booking. Delivery/picking is done for booking. References: Fowler, M. & Scott, K. (2004). UML Distilled: A Brief Guide to the Standard Object Modelling Language. 3rd Edition. Object Technology Series. Reading, MA: Addison Wesley. (ISBN: 0-321-19388-7) Maciaszek, L.A. (2005). Requirements Analysis and Systems Design: Developing Information Systems with UML. Addison Wesley. (ISBN: 0-321-204641-6) [The 1st Edition of this book will also suffice (ISBN: 0-201-70944-9)] Bennet, S., McRobb, S. & Farmer, R. (1999). Object-Oriented Systems Analysis and Design using UML. McGraw Hill. (ISBN: 007 709497 2) Schmuller, J. (2002). Sams Teach Yourself UML in 24 Hours. 2nd Edition. Sams Publishing. (ISBN 0-672-32238-2) Brown D.W. (2002). An Introduction to Object Oriented Analysis: Object and UML in Plain English. John Wiley. (ISBN: 0-471-42728-4) Booch, G., Rumbaugh, J. & Jacobson, I. (2001). The United modelling Language User guide. Addison Wesley. [ISBN: 81-7808-169-5] Read More