CS 151: Object-Oriented Design August 29 Class Meeting Department of Computer Science San Jose State University Spring 2012 Instructor: Ron Mak www. cs. sjsu. edu/~mak
Key Points from Last Time o o o Việc phát triển một phần mềm tuyệt vời có thể là một việc rắc rối! Đó là một lộ trình lặp đi lặp lại để cải tiến dần chất lượng giải pháp thiết kế Hãy sẵn lòng thừa nhận mình đã có những quyết định thiết kế tồi và sửa chúng. n Càng sớm càng tốt! SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 2
Application Development Big Picture SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 3
Phân tích trước khi thiết kế o Hiểu vấn đề. n o Thu thập yêu cầu (requirement) từ khách hàng. n n o Khách hàng / Client: ta viết phần mềm cho họ Nói chuyện với Rick! Hỏi xem anh ta muốn phần mềm làm việc gì. Viết một đặc tả chức năng / functional specification. n n o Ứng dụng là vô dụng nếu nó không làm việc nó cần làm. Mô tả rõ phần mềm cần làm cái gì (what), không phải bằng cách nào (how). Chứa các use case / ca sử dụng. Cả khách hàng và lập trình viên đều hiểu. Khách hàng có thể đề ra yêu cầu mới hoặc thay đổi yêu cầu cũ. Tạo và demo một ứng dụng rởm thử nghiệm. n Khách hàng có thể nghĩ ra yêu cầu mới hoặc thay đổi yêu cầu cũ. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 4
A Truly Messy Business If you thought software design was messy. . . analysis can be just as messy! o Khách hàng thường không biết họ muốn gì. n o Thu thập yêu cầu từ khách hàng là việc khó! n n n o “Khi nào tôi nhìn thấy nó thì tôi sẽ nhận ra. ” Many iterations (phỏng vấn khách hàng nhiều lần). Nhiều lần demo phiên bản thử nghiệm (mock-up application). Nhiều lần sửa đặc tả chức năng (functional specification). Tất nhiên, khi ta đang thiết kế, khách hàng vẫn có thể đổi ý. n Ví dụ: Rick muốn bán thêm các loại nhạc cụ khác. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 5
What is a Requirement? Một yêu cầu là một nhiệm vụ cụ thể mà phần mềm ứng dụng của ta phải làm để được coi là hoạt động đúng. Đây thực ra là định nghĩa của một yêu cầu chức năng / functional requirement. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 6
Thu thập yêu cầu từ đâu? o o o o Khách hàng - Client Người sử dụng - End users Lập trình viên Development managers Nhà cung cấp công nghệ Stakeholders Tất cả có thể có những ý tưởng mâu thuẫn nhau về việc ứng dụng cần phải làm gì. Giữa chừng, ai cũng có thể đổi ý về yêu cầu. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 7
Types of Requirements o Yêu cầu chức năng – Functional requirements n Hệ thống sẽ làm được gì, hoặc cho phép người dùng làm gì o o n o “Điện thoại sẽ dùng GPS để xác định vị trí của người cầm. ” “Người dùng sẽ có thể chọn giữa Option A hoặc Option B. ” Mô tả tương tác giữa hệ thống và môi trường xung quanh, không quan tâm hệ thống được xây dựng bằng cách nào. Yêu cầu phi chức năng – Nonfunctional requirements n Tính dễ sử dụng (usability), độ tin cậy (reliability), hiệu năng (performance), khả năng hỗ trợ (supportability), . . . o o o n “Hệ thống phải phản ứng với người dùng trong vòng 15 giây. ” “Hệ thống phải chạy trên các server Windows và Linux. ” “Giao diện người dùng mới cần giống với giao diện cũ. ” Các ràng buộc (constraint) mà hệ thống phải thỏa mãn. _ SJSU Dept. of Computer Science CS 151: Object-Oriented Design Fall 2013: August 29 © R. Mak 8
Requirements Must Have. . . o Completeness n o Consistency n o Không có hai yêu cầu nào mâu thuẫn nhau. Clarity n o Các yêu cầu có mô tả được toàn bộ các tính năng của hệ thống? Mỗi yêu cầu chỉ có một cách hiểu. Correctness n n Không có lỗi trong nội dung các yêu cầu. Mỗi chức năng hệ thống có thể được truy về một yêu cầu hay không? _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 9
Requirements Must Have, cont’d o Realism n o Verifiability n o Có thể cài đặt được hệ thống không? Có thể test được xem từng yêu cầu có được thỏa mãn hay không? Traceability n Có thể truy mỗi yêu cầu tới một chức năng hệ thống hay không? _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 10
Example Application: Automated Dog Door o Todd và Gina thuê đội lập trình của bạn làm một cái cửa chó với một nút điều khiển từ xa để nửa đêm khi Fido đi chơi về sủa ầm ĩ thì họ có thể mở cửa cho chó mà không phải đi xuống tầng 1. SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 11
Initial Requirements o o o Push the button on the remote and open the door. Push the button again to close the door. Những yêu cầu đó đã đủ mô tả những gì Todd và Gina nói là họ muốn hay chưa? _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 12
Get More Requirements o Phỏng vấn khách hàng. Hỏi để lấy thêm thông tin. n How tall is Fido? o n How many buttons do you want on the remote? o n o The door must be at least 12” tall. Only one that toggles between opening and closing the door. Should the door close automatically after a while? Lập trình viên cần brainstorming. n Nhìn vấn đề từ nhiều góc độ. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 13
Stated and Implied Requirements o Khách hàng nói n n o Hàm ý (theo bạn là gì? ) n n o Cửa cần mở được từ xa. Cửa cần đóng sau khi chó đã ra ngoài. Cửa không nên đóng trong khi chó đang chui qua. Cửa cần tự động đóng lại sau khi đợi một chút. Còn hàm ý nữa… n n Khách hàng muốn ứng dụng nhanh xong. Chi phí cho phần mềm phải hợp lí. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 14
Dùng use case để kiểm tra requirement SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 15
What is a Use Case? o A complete sequence of steps that provides value to one of the actors. n Actor: Someone or something that is not part of your system. o o o Describes something that your application must do. n A single goal of your application. o o Todd, Gina, Fido You’re building a software application to implement an automatic dog door, not simulations of people or dogs. Todd and Gina remotely let Fido out from their bedroom. Initiated by an actor. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 16
Parts of a Use Case o Name n o Description n o Who’s involved? Preconditions n o One or two paragraphs describing the purpose and goal. Actors n o Verb-Noun (example: Let out the dog) What must be true before the use can start? Trigger n What initiates the sequence of steps? SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 17
Parts of a Use Case, cont’d o Primary sequence n o Postconditions n o n n Variations of the basic flow Alternate triggers Alternate postconditions Nonfunctional requirements n o What must be true when the use case ends successfully? Alternate sequences n o Most common sequence of steps Examples: performance, user interface Glossary SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 18
Example Alternate Sequence From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. SJSU Dept. of Computer Science Fall 2013: August 29 6. Fido does his business. 6. 1 The door shuts automatically. 6. 2 Fido barks to be let back inside. 6. 3 Todd or Gina hears Fido barking (again). 6. 4 Todd or Gina presses the remote control button. 6. 5 The dog door opens (again). 7. Fido goes back inside. CS 151: Object-Oriented Design © R. Mak 19
Some Key Points for Success o Cách tốt nhất để lấy được requirement tốt là cố gắng hiểu ứng dụng cần phải làm gì. n o Để có thành công, ta phải hiểu ứng dụng hơn cả khách hàng. n n o Đảm bảo rằng ứng dụng hoạt động theo như ý muốn của khách hàng, chứ không nhất thiết theo ý của ta. Biết chính xác ứng dụng cần phải làm gì. Có thể dự đoán được các vấn đề. Ta sẽ không thành công nếu ứng dụng không hoạt động như ý khách hàng. n Các use case là công cụ giúp ta biết được điều đó trước khi bắt đầu thiết kế. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 20
Did We Completely Analyze the Problem? Dog. Door. java Dog. Door. jav a The Perfect World Make sure your application will work in a real-world context. SJSU Dept. of Computer Science Fall 2013: August 29 The Real World CS 151: Object-Oriented Design © R. Mak From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006. 21
But Avoid. . . Paralysis by Analysis SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 22
Good Use Cases o Viết use case sao cho tất cả những người quan trọng (khách hàng, lập trình viên, quản lý…) ai cũng hiểu. o Các use case tốt cho thấy n n bạn đã phân tích đến nơi đến chốn ứng dụng sẽ hoạt động được trong ngữ cảnh thực. _ SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 23
The Functional Specification SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 24
The Functional Specification o Problem statement n o Objectives n o o o Bài toán là gì? What is your application supposed to accomplish? Functional requirements Nonfunctional requirements Use cases Nội dung chính của tài liệu Functional Specification Xem sample link tại website môn học!!! SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 25
Ways to Elicit Requirements o Interview the stakeholders n n o Joint Application Design (JAD) n o But you need to know the right questions to ask! Be aware of cultural or political issues. Multi-day workshop with stakeholders and developers to hash out requirements. Ethnography n Developers “live with” the users to observe, learn, and understand their world. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 26
But … o Users don’t always know what they want! n n There must be an ongoing dialog among the developers, the clients, and the users. There needs to be an iterative process: o o Developers show something Clients and users validate Repeat If the developers force the clients or users to come up with the requirements too soon. . . n n They make something up! Such requirements will most likely be wrong or incomplete. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 27
Requirements Elicitation Tasks o Identify actors o Identify and document use cases n o Identify functional requirements n o Abstractions of actor-system interactions. Extract functional requirements from the use cases. Identify nonfunctional requirements n n Do this at the same time as when you’re identifying the functional requirements (as embodied by the use cases). Nonfunctional requirements have as much impact on the development and cost of the system as functional requirements. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 28
Use Cases o Một use case mô tả cách đạt được một mục đích hoặc thực hiện được một việc. n n o Actor là các tử bên ngoài tương tác hoặc liên lạc với hệ thống. n n o Một chuỗi hoàn chỉnh các action hoặc event. Primary sequence (chuỗi chính) và alternate sequences (các chuỗi phụ - tình huống ngoại lệ). Một chuỗi do một actor khởi phát. Chú trọng vào việc hệ thống phải làm cái gì, không quan tâm bằng cách nào. actor = trừu tượng hóa của một vai trò actor có thể là người hoặc một hệ thống. Một use case coi hệ thống như một “hộp đen”. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak ? 29
Example: Bank ATM System system Start up ATM actor Operator Shut down ATM Biên hệ thống use cases Log in customer tương tác Log out customer Customer UML use case diagram SJSU Dept. of Computer Science Spring 2013: September 3 Withdraw cash Display balance CS 151: Object-Oriented Design © R. Mak Bank 30
Example Use Case Description o Name: Withdraw Cash o Goal: Customer withdraws cash from ATM. o Summary: A customer who has logged in can withdraw up to $500 cash in $20 bills. o Actors: The customer and the bank o Preconditions: n n What must be true before the use can start. The ATM has been started up. o n verb object See use case “Start up ATM”. The customer has inserted a valid bank card. The customer has entered a correct PIN. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 31
Example Use Case Description, cont’d o Trigger: The customer selects the “Withdraw Cash” option. o Primary sequence: 1. 2. 3. 4. 5. 6. At most about 10 steps. The system prompts the customer for the amount. The customer chooses from a list of amounts or enters a amount. The customer submits the amount. The system dispenses the amount in $20 bills. The bank deducts the amount from the customer’s balance. The system displays the customer’s balance n See use case “Display balance”. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 32
Example Use Case Description, cont’d o Alternate sequences: n 3. 1 The customer entered an amount not a multiple of $20. o o n 3. 2 The customer’s bank balance is insufficient. o o 3. 1. 1 The system displays a message to the customer. 3. 1. 2. The system prompts the customer for a new amount. 3. 2. 1 etc. Postconditions: n What must be true after the use case is done. The customer receives the desired amount of cash. o o n The amount is deducted from the customer’s account. The customer sees the new account balance. OR: The customer receives no cash. o The customer’s account is unchanged. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 33
Example Use Case Description, cont’d o Nonfunctional requirements: n n o The system responds to each customer input within 5 seconds. The system displays messages in either English, Spanish, or Vietnamese. Glossary n n n customer = a person who wants to withdraw cash from the ATM. bank = a system that maintains customer accounts and balances. etc. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 34
Use Case Guidelines o Tên của use case nên là cụm động từ. n o Viết use case ngắn, đơn giản. n n o Mô tả mục đích đạt được (e. g. , “Withdraw Cash”). Khách hàng và người sử dụng cần hiểu được. Không chứa chi tiết về giao diện GUI hay chi tiết cài đặt. Khi các use case phủ hầu hết các kịch bản có thể của ứng dụng, khi đó ta có đủ requirement để bắt đầu thiết kế. n Một số use case có thể làm cho ta muốn bổ sung requirement. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 35
Key points o Các cách lấy requirement Stakeholder Các loại requirement Tiêu chí của requirement tốt Use case (biểu đồ và mô tả, dùng làm gì? ) Nội dung chính của tài liệu đặc tả chức năng o Bắt đầu làm Assignment #1 o o o SJSU Dept. of Computer Science Fall 2013: August 29 CS 151: Object-Oriented Design © R. Mak 36
Скачать презентацию CS 151 Object-Oriented Design August 29 Class Meeting
98d3bc6c46512ffab13f9e44afcc0f39.ppt