Bài giảng Công nghệ phần mềm - Thiết kế phần mềm

pptx 54 trang Gia Huy 16/05/2022 2870
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Công nghệ phần mềm - Thiết kế phần mềm", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

  • pptxbai_giang_cong_nghe_phan_mem_thiet_ke_phan_mem.pptx

Nội dung text: Bài giảng Công nghệ phần mềm - Thiết kế phần mềm

  1. NỘI DUNG 1. Tổng quan về thiết kế 2. Kiến trúc phần mềm 3. Phương pháp thiết kế phần mền 4. Ví dụ minh họa Jens Martensson 2
  2. 3.1. Tổng quan về thiết kế ❑Mục tiêu của việc thiết kế là định hình hệ thống và tìm dạng thức của phần mềm có thể đáp ứng được mọi yêu cầu. ❑Dữ liệu đầu vào của giai đọn thiết kế: Kết quả thu được từ bước phân tích trước đó. Jens Martensson 3
  3. 3.1. Tổng quan về thiết kế ❑Mục đích thiết kế: ❖Hiểu rõ về yêu cầu và những ràng buộc có liên quan, khả năng tái sử dụng của các thành phần. ❖Tạo đầu vào thích hợp và điểm xuất phát cho các hoạt động hiện thực ❖Có thể phân rã việc cài đặt thành các phần nhỏ dễ quản lý để nhiều nhóm phát triển xử lý đồng thời. ❖Lựa chọn kiến trúc phù hợp với hệ thống. Jens Martensson 4
  4. 3.1.1. Kỹ thuật thiết kế phần mềm ❑Có hai phương pháp chính: ❖Thiết kế từ trên xuống (Top- Down) ❖Thiết kế từ dưới lên (Bottom – Up) Jens Martensson 5
  5. 3.1.1.1 Thiết kế trên xuống (top-down) ❑Quá trình thiết kế được bắt đầu bằng những thành phần tổng quan nhất của hệ thống. ❑Triển khai thành những module nhỏ hơn, quá trình này được lặp lại cho đến khi những nhiệm vụ con trở nên đơn giản sao cho một thuật toán có thể tính toán và giải quyết được. Jens Martensson 6
  6. 3.1.1.2 Thiết kế từ dưới lên (bottom–up) ❑Thiết kế từ dưới lên bắt đầu từ một công việc nhỏ nhất và cụ thể, phát triển liên tiếp thành một thành phần trừu tượng cho đến khi đạt được kết quả mà là các chức năng theo yêu cầu của người dùng. Jens Martensson 7
  7. 3.1.1.3 Thiết kế hệ thống phần mềm ❑Thiết kế hệ thống phần mềm có ba cấp độ kết quả: ❖Thiết kế kiến ​​trúc: Thiết kế kiến ​​trúc là phiên bản trừu tượng cao nhất của hệ thống. Nó xác định phần mềm là một hệ thống có nhiều thành phần tương tác với nhau. ❖Thiết kế cấp cao:. Thiết kế cấp cao tập trung vào cách hệ thống cùng với tất cả các thành phần của nó có thể được thực hiện dưới dạng các mô-đun. ❖Thiết kế chi tiết: Thiết kế chi tiết liên quan đến phần thực hiện của một hệ thống và các hệ thống con, xác định cấu trúc logic của từng mô-đun và giao diện của chúng để giao tiếp với các module khác. Jens Martensson 8
  8. 3.1.1.4 Thiết kế bản mẫu (prototype) ❑Thiết kế bản mẫu: tạo các giao diện sơ bộ, các bản thiết kế phác thảo cho người dùng tham khảo trước khi thiết kế chi tiết ❖Các bản thiết kế này được thực hiện dạng tài liệu kỹ bằng các phần mềm thiết kế nhanh như MS Visio, MS Visual Basic / C# / C++, MS Front Page / Visual Interdev ❖Đây là bước đệm cơ bản trước khi đi vào hiện thực chi tiết. Jens Martensson 9
  9. 3.1.1.5 Phân rã thiết kế ❑Phân rã thiết kế giúp hiện thực hóa từng phần bản thiết kế đến mức chi tiết. Các nhóm phương pháp phân rã gồm: ❖ Phân rã hướng chức năng ❖ Phân rã hướng dữ liệu Jens Martensson 10
  10. 3.1.1.5 Phân rã thiết kế ❑Phân rã hướng chức năng ❖Dựa trên những yêu cầu chức năng để phân rã hướng đến các tác nhiệm của toàn bộ hệ thống. ❖Sử dụng Sơ đồ phân rã chức năng (FDD): – Xác định các chức năng dựa trên mô tả các tính chất của đầu vào và đầu ra – Xác định phạm vi của hệ thống – Phân hoạch chức năng – Tạo nền tảng cho thiết kế kiến trúc hệ thống Jens Martensson 11
  11. 3.1.1.5 Phân rã thiết kế ❑Phân rã hướng dữ liệu ❖Tiến trình thiết kế tập trung vào dữ liệu. ❖Chiến lược thiết kế hướng đến các đối tượng dữ liệu cần được thực hiện. ❖Việc phân rã hệ thống dựa trên việc phân tích dữ liệu, bao gồm sơ đồ luồng dữ liệu (Data flow diagram - DFD), giúp xem toàn bộ luồng dữ liệu bên trong hệ thống và cách dữ liệu được xử lý theo nhiều mức chi tiết khác nhau và nhiều biến thể mở rộng khác nhau. Jens Martensson 12
  12. 3.1.1.5 Phân rã thiết kế ❑Ví dụ: DFD hệ thống bán vé Jens Martensson 13
  13. 3.1.1.5 Phân rã thiết kế ❑Tiếp cận từ trên xuống (top-down) ❖Lập sơ đồ luồng dữ liệu cấp 0 (xét tất cả các luồng dữ liệu nhập xuất, tất cả các yêu cầu xử lý) ❖Phân rã sơ đồ luồng dữ liệu cấp 0 thành các sơ đồ luồng dữ liệu cấp 1: – Phân rã các xử lý thành nhiều xử lý con và quyết định các luồng dữ liệu tương ứng. – Phân rã các luồng dữ liệu nhập xuất thành nhiều luồng dữ liệu con và quyết định các xử lý tương ứng – Quá trình kết thúc khi đạt đến các sơ đồ không thể tiếp tục phân rã được nữa, đây là sơ đồ tương ứng với công việc cụ thể. Jens Martensson 14
  14. 3.1.1.5 Phân rã thiết kế ❑Nhận xét: Cách tiếp cận từ trên xuống ❖Thích hợp với phần mềm có số lượng người dùng, số lượng các yêu cầu ít (nếu ngược lại sơ đồ cấp 0 sẽ rất phức tạp và khó lập chính xác). ❖Đặc biệt thích hợp với các loại phần mềm mà yêu cầu chưa được xác định rõ ngay từ đầu (ví dụ các phần mềm hệ thống). ít được sử dụng. Jens Martensson 15
  15. 3.1.1.5 Phân rã thiết kế ❑Tiếp cận từ dưới lên (bottom-up) ❖Lập sơ đồ luồng dữ liệu ở mức cao nhất. ❖Tích hợp các sơ đồ này để tạo các sơ đồ có cấp nhỏ hơn theo cách: – Tích hợp các xử lý của các sơ đồ cấp k vào sơ đồ cấp k-1 và giữ nguyên các luồng dữ liệu của các sơ đồ cấp k – Tích hợp đồng thời các xử lý và các luồng dữ liệu của các sơ đồ cấp k để tạo lập sơ đồ cấp k-1. – Quá trình kết thúc khi đạt đến các sơ đồ cấp 0 Jens Martensson 16
  16. 3.1.1.5 Phân rã thiết kế ❑Nhận xét: Cách tiếp cận từ dưới lên ❖Thích hợp với các phần mềm có yêu cầu chi tiết, cụ thể và có quy mô trung bình. ❖Khó thực hiện với các dự án có quy mô lớn và yêu cầu chưa được rõ ràng chi tiết Jens Martensson 17
  17. 3.1.1.5 Phân rã thiết kế ❑Hướng tiếp cận phối hợp: ❖Lập sơ đồ luồng dữ liệu cấp k theo tiêu chí xác định ❖Phân rã sơ đồ cấp k thành nhiều sơ đồ cấp k+1 tiếp tục cho đến khi đạt được các sơ đồ lá. ❖Tích hợp các sơ đồ cấp k thành các sơ đồ cấp k-1 tiếp tục cho đến khi đạt được sơ đồ cấp 0. ❑Nhận xét ❖Cách tiếp cận phối hợp thích hợp cho các phần mềm có quy mô yêu cầu lớn, phức tạp ❖Được dùng nhiều trong thực tế. Jens Martensson 18
  18. 3.1.1.5 Phân rã thiết kế ❑Lập sơ đồ luồng dữ liệu cho từng công việc ❖Việc lập các sơ đồ luồng dữ liệu cho toàn bộ phần mềm sẽ trở thành lập sơ đồ luồng dữ liệu cho từng công việc. ❖Sau đó tích hợp để có sơ đồ cấp 0. ❖Quá trình lập sơ đồ luồng dữ liệu cho một công việc được tiến hành qua 3 bước. – Xác định dữ liệu nhập – Xác định dữ liệu xuất – Mô tả cách xử lý Jens Martensson 19
  19. 3.1.1.5 Phân rã thiết kế ❖Bước 1: Xác định dữ liệu nhập, dữ liệu nhập phải thỏa điều kiện sau: – Không nhập vào các dữ liệu có thể tính toán được dựa trên quy định hay công thức đã có. – Không nhập vào các dữ liệu đã được lưu trữ trước đó. – Dữ liệu nhập từ thiết bị nhập khác chỉ được xem xét khi có yêu cầu đặc biệt trong một số phần mềm đặc biệt như: hệ thống thời gian thực, hệ thống bản đồ, nhập qua điện thoại tổng đài Jens Martensson 20
  20. 3.1.1.5 Phân rã thiết kế ❖Bước 2: Xác định dữ liệu xuất ❖Cần phải có các thông báo giúp người dùng biết được kết quả xử lý của hệ thống. Ví dụ thông báo việc mượn sách là không hợp lệ ❖Tăng tính tiện dụng: trong tất cả các xử lý (kể cả các xử lý lưu trữ, tính toán) cần phải xuất cho người dùng các thông tin về kết quả. ❖Tất cả dữ liệu xuất ra màn hình thì phải xuất ra được trên máy in. Đối với các loại thiết bị xuất khác cần phải có các loại phần mềm đặc biệt. Jens Martensson 21
  21. 3.1.1.5 Phân rã thiết kế ❖Bước 3: Mô tả Xử lý – Chỉ mô tả cách xử lý mà không cần chú ý đến cách thực hiện nhập xuất – Khi mô tả cách sử dụng dữ liệu nhập để tạo dữ liệu xuất, việc mô tả càng chi tiết thì việc thiết kế xử lý càng dễ dàng. – Chỉ chú trọng đến tính đúng đắn – Mô tả chính xác thứ tự nhập/xuất Jens Martensson 22
  22. 3.1.1.5 Phân rã thiết kế ❑Xây dựng mô hình thực thể kết hợp (ERD) ❑ Mô hình ERD là dạng sơ đồ giúp thể hiện các đối tượng dữ liệu được đặc tả trong yêu cầu của phần mềm, tạo nền tảng cho việc thiết kế chi tiết cơ sở dữ liệu cho phần mềm. Jens Martensson 23
  23. 3.1.1.5 Phân rã thiết kế ❑Phân rã hướng đối tượng ❖Một hệ thống phần mềm được xem như tập hợp các đối tượng, mỗi đối tượng có cấu trúc dữ liệu và hành vi. ❖Phân rã hướng đối tượng hướng đến tính đồng nhất giữa dữ liệu, hành vi dựa trên sự che dấu thống tin và dẫn xuất kế thừa. Jens Martensson 24
  24. 3.1.2 Thiết kế giao diện người dùng ❑Thiết kế giao diện người dùng ❖Thiết kế giao diện được hỗ trợ một phần trong thiết kế dạng mô hình bản mẫu (prototype) nhằm làm rỏ các yêu cầu từ người dùng và đáp ứng các yêu cầu về giao diện. ❖Nếu khách hàng đồng ý với bản mẫu đã đưa ra trong giai đoạn xác định yêu cầu, kỹ sư thiết kế sẽ hoàn chỉnh thêm để đảm bảo chính xác yêu cầu người dùng. Jens Martensson 25
  25. 3.1.2 Thiết kế giao diện người dùng ❑Các yếu tố cần quan tâm trong thiết kế giao diện ❖Chế độ (modes): – Trường hợp mà người dùng chỉ có thể thực hiện ở một số thao tác giới hạn. – Kỹ thuật tạo/sử dụng cửa sổ có thể cung cấp dịch vụ có giá trị về biểu diễn chế độ của chương trình, giúp thực hiện các thao tác trong những cửa sổ khác nhau thể hiện bởi những chế độ chương trình khác nhau. Jens Martensson 26
  26. 3.1.2 Thiết kế giao diện người dùng ❖Thanh menu: giúp người dùng chọn lệnh của chương trình. Có hai dạng menu – Dạng Pop-up menu: là menu có thể xuất hiện ở một vị trí bất kỳ. – Dạng Pull-down menu: là dạng mở rộng tập lệnh và dễ dàng sử dụng. ❖Có thể phân loại menu theo tập lệnh thao tác với tham số, tập lệnh chuyển đối chế độ người dùng. Jens Martensson 27
  27. 3.1.2 Thiết kế giao diện người dùng ❖Dialog window: dạng hộp thoại giúp người dùng có thể tương tác với chương trình linh hoạt hơn. – Khi thiết kế hộp thoại, ta cần đảm bảo tính đồng nhất trong giao diện người dùng, nên ngắn gọn cô động như cách đặt nhãn Label, Checkbox, Button, List box. ❖Màu sắc Màu được dùng ở những nơi cần làm nổi bật những yêu cầu hoặc cần nhấn mạnh một nội dung, hoặc dấu hiệu cảnh báo nguy hiểm. – Nên sử dụng màu hài hòa trong toàn bộ hệ thống – Sử dụng màu phải phù hợp với từng loại giao diện của chương trình Jens Martensson 28
  28. 3.1.2 Thiết kế giao diện người dùng ❖Âm Thanh là cách tốt nhất tập trung sự chú ý của người dùng. Chúng được phần mềm phù hợp trong các tình huống xử lý lỗi, sự kiện không chắc chắn, tạm thời. – Nên tạo những âm thanh khác nhau với những sự kiện khác nhau, tránh dùng âm thanh gây ồn. ❖Tính kiên định – Thanh lệnh: với những chức năng giống nhau nên có vị trí giống nhau – Phím tắt: nên dùng cho một số chức năng của phần mềm và nên cố định. – Nút lệnh của những chức năng tương tự nên có nhãn và vị trí giống nhau Jens Martensson 29
  29. 3.1.3. Thiết kế hướng chức năng ❑Thiết kế hướng chức năng: tập trung vào thuật toán để giải quyết vấn đề. ❖Xem một thuật toán như một hàm tính toán với các tham số đầu vào. ❖Tại thời điểm bắt đầu giai đoạn thiết kế, thuật toán chưa xác định. ❖Cần xây dựng những thuật toán để giải quyết những tác nhiệm khó hoặc phức tạp của phần mềm. ❖Việc module hóa để phân rã những công việc thành các công việc con độc lập dựa vào thuật toán xử lý các công việc con ❖Kết quả chung của những giải pháp dựa trên các thuật toán con gộp lại. Jens Martensson 30
  30. 3.1.3. Thiết kế hướng đối tượng ❑Thiết kế hướng đối tượng là tổ chức thiết kế xoay quanh những đối tượng và mối liên hệ giữa chúng, bao gồm: ❖Thiết kế lớp đối tượng: xây dựng các lớp đối tượng bao gồm thuộc tính và hành vi của các đối tượng, ❖Thiết kế giao diện: xây dựng giao diện (interface) của lớp đối tượng tương ứng với từng trách nhiệm của lớp đối tượng. ❖Thiết kế dữ liệu: thiết kế cách thức tổ chức lưu trữ các đối tượng trên bộ nhớ phụ. ❖Khả năng tái sử dụng: đóng vai trò quan trọng trong lập trình hướng đối tượng Jens Martensson 31
  31. 3.2. Kiến trúc phần mềm ❑Kiến trúc phần mềm của một chương trình máy tính là cấu trúc của các thành phần bên trong hệ thống, các mối quan hệ (cấu trúc) và cách tương tác giữa các thành phần với nhau. ❖Kiến trúc phần mềm bao gồm các phần tử chức năng, các thuộc tính và mối quan hệ giữa chúng. ❖Kiến trúc phần mềm giúp việc quyết định ở mức cao trong thiết kế phần mềm dễ dàng hơn và cho phép tái sử dụng các thành phần và mẫu thiết kế của các dự án. Jens Martensson 32
  32. 3.2. Kiến trúc phần mềm Jens Martensson 33
  33. 3.2. Kiến trúc phần mềm ❑Kiến trúc phần mềm bao gồm các thành phần cơ bản: Giao diện, Xử lý, Dữ liệu. ❖Khi thiết kế một phần mềm, nhóm thiết kế phải chọn lựa và ra quyết định về các “vật liệu” được dùng trong các thành phần. ❖Kết quả được trình bày trên các bảng vẽ, dưới dạng tài liệu kỹ thuật, tạo thành các mô hình phần mềm. Jens Martensson 34
  34. 3.2. Kiến trúc phần mềm ❑Thành phần Giao diện ❖Nội dung và hình thức trình bày các chức năng giao tiếp ❖Các thao tác của người dùng trên giao diện để thực hiện các giao tiếp và các chức năng xử lý. ❑Thành phần Xử lý: ❖Các kiểu dữ liệu được mô tả về cách tổ chức lưu trữ trong bộ nhớ chính. ❖Các hàm thực hiện các xử lý (ví dụ kiểm tra tính hợp lệ việc cho mượn sách, ghi vào sổ việc cho mượn sách ) Jens Martensson 35
  35. 3.2. Kiến trúc phần mềm ❑Thành phần Dữ liệu: ❖cách tổ chức lưu trữ dữ liệu trong bộ nhớ ❖Cách lưu trữ của dữ liệu được sử dụng của phần mềm, ❖Hệ thống các thành phần lưu trữ và mối quan hệ giữa các dữ liệu. Jens Martensson 36
  36. 3.2. Kiến trúc phần mềm ❑Một số mô hình kiến trúc mẫu ❖Model-ViewController – MVC ❖Kiến trúc phân tầng ❖Kiến trúc client-server Jens Martensson 37
  37. 3.2. Kiến trúc phần mềm ❑Kiến trúc Model-View-Controller – MVC ❖Hệ thống được cấu trúc thành ba thành phần logic tương tác với nhau. – Model : quản lý dữ liệu của hệ thống và các thao tác trên dữ liệu – View : định nghĩa và quản lý cách dữ liệu được hiển thị cho người dùng – Controller: Quản lý tương tác người dùng (VD, ấn phím, nhấp chuột, ) và chuyển các tương tác này tới View và Model. Jens Martensson 38
  38. 3.2. Kiến trúc phần mềm ❑Kiến trúc Model-View-Controller – MVC ❖Hoạt động của MVC ❖Controller chuyển yêu cầu dữ liệu của người dùng cho Model. ❖Model Lấy được dữ liệu chuyển cho Controller. ❖Controller chuyển dữ liệu cho View ❖View Hiển thị thông tin cho người dùng. Jens Martensson 39
  39. 3.2. Kiến trúc phần mềm ❑Kiến trúc Client-Server (máy khách-máy chủ) là một mô hình máy tính, trong đó máy chủ (server), cung cấp và quản lý hầu hết các nguồn lực và dịch vụ cho máy khách (client). Jens Martensson 40
  40. 3.2. Kiến trúc phần mềm ❑Kiến trúc 3 Layer: gồm có 3 thành phần: Presentation Layers, Business Logic Layers, và Data Access Layers ❖Presentation Layers: làm nhiệm vụ giao tiếp với người dùng cuối để thu thập dữ liệu và hiển thị kết quả trên giao diện. ❖Busines Logic Layers: xử lý các dữ liệu trước khi chuyển xuống Data Access Layer để lưu dữ liệu xuống cơ sở dữ liệu. ❖Data Access Layers: thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của ứng dụng như đọc, lưu, cập nhật cơ sở dữ liệu. Jens Martensson 41
  41. 3.2. Kiến trúc phần mềm ❑Kiến trúc 3 Layer: Cách vận hành: ❖Người dùng giao tiếp với tầng giao diện (GUI) để gửi yêu cầu, các thông tin sẽ được kiểm tra, nếu OK, dữ liệu được chuyển xuống tầng nghiệp vụ (BLL). ❖Tại BLL, các thông tin sẽ được xử lý, nếu không cần đến Database thì BLL sẽ gửi trả kết quả về GUI, ngược lại dữ liệu được đưa xuống tầng truy cập dữ liệu (DAL). ❖DAL sẽ thao tác với Database và trả kết quả cho BLL, BLL kiểm tra và gửi cho GUI để hiển thị cho người dùng. ❖ Jens Martensson 42
  42. 3.3. Phương pháp thiết kế phần mềm ❑Phương pháp trực tiếp ❖Phương pháp này được áp dụng khi thực hiện phần mềm không qua giai đoạn phân tích, việc thiết kế nhận kết quả đươc chuyển giao trực tiếp từ giai đoạn xác định yêu cầu. ❖Đối với phương pháp trực tiếp: Thiết kế phần mềm là quá trình chuyển đổi từ các yêu cầu đến mô hình phần mềm tương ứng. ❖Cách tiếp cận này rất khó đối với các phần mềm có quy mô lớn Jens Martensson 43
  43. 3.3. Phương pháp thiết kế phần mềm ❑Phương pháp gián tiếp ❖Được áp dụng với các quy trình có giai đoạn phân tích, việc thiết kế chỉ nhận 1 phần kết quả từ giai đoạn xác định yêu cầu, phần chính được nhận từ giai đoạn phân tích, PM được xây dựng dựa trên các mô hình trong giai đoạn phân tích. ❖ Cách tiếp cận này thích hợp với các phần mềm có quy mô lớn. ❖Đối với phương pháp gián tiếp: Thiết kế PM là quá trình chuyển từ kết quả giai đoạn phân tích đến mô hình phần mêm tương ứng. Jens Martensson 44
  44. 3.4. Ví dụ minh hoạ ❑Ví dụ minh họa quá trình thiết kế phần mềm sau khi thực hiện giai đoạn mô hình hóa yêu cầu. Thiết kế phần mềm quản lý thư viện với 4 yêu cầu: Lập thẻ đọc giả, Nhận sách, Cho mượn sách, Trả sách ❖ Mô hình hóa các yêu cầu: Jens Martensson 45
  45. 3.4. Ví dụ minh hoạ ❑Thiết kế phần mềm: Hệ thống các màn hình giao diện ❑Màn hình chính ❖Nội dung: Thông tin về thư viện, Thông tin về độc giả, Thông tin về sách. ❖Thao tác người dùng: Tra cứu và chọn độc giả, Tra cứu và chọn sách. ❑Màn hình Lập thẻ ❖Nội dung: Thông tin về thẻ độc giả. ❖Thao tác người dùng: Nhập thông tin về thẻ, Yêu cầu lập thẻ Jens Martensson 46
  46. 3.4. Ví dụ minh hoạ ❑Màn hình cho mượn sách ❖Nội dung: Thông tin về thẻ độc giả (Ngày mượn sách, Danh mục sách). ❖Thao tác người dùng: Nhập thông tin mượn sách, Yêu cầu mượn sách. ❑Màn hình Nhận sách ❖Nội dung: Ngày nhận sách, Danh mục sách nhận & thông tin liên quan. ❖Thao tác người dùng: Nhập thông tin về việc cho nhận sách, Yêu cầu cho nhận sách. ❑Màn hình Trả sách ❖Nội dung: Ngày trả sách, Thông tin về việc trả sách. ❖Thao tác người dùng: Nhập thông tin trả sách, Yêu cầu trả sách. Jens Martensson 47
  47. 3.4. Ví dụ minh hoạ ❑Hệ thống các hàm xử lý ❖Hàm lập thẻ: Kiểm tra tính hợp lệ và lưu thẻ vào kho ❖Hàm Tra cứu độc giả: Tìm thẻ độc giả theo các tiêu chuẩn khác nhau để cho phép cập nhật hay xóa thẻ ❖Hàm Xóa thẻ: Xóa thẻ trong kho ❖Hàm Nhập sách: Kiểm tra tính hợp lệ của sách và lưu sách vào kho ❖Hàm Xóa sách: Xóa sách trong kho ❖Hàm Cho mượn sách: Kiểm tra tính hợp lệ của việc cho mượn sách và ghi nhận các thông tin cho mượn sách vào kho ❖Hàm Tra cứu sách: Tìm sách theo các tiêu chuẩn khác nhau để cho phép cập nhật hay xóa sách Jens Martensson 48
  48. 3.4. Ví dụ minh hoạ ❖Hàm Tính số sách độc giả đang mượn: tổng số sách độc giả đang mượn ❖Hàm Kiểm tra độc giả mượn sách quá hạn: Kiểm tra độc giả có sách mượn quá hạn và trả về 1 nếu đúng, 0 nếu sai ❖Hàm Kiểm tra tình trạng sách: Kiểm tra sách đang được mượn, hàm trả về 1 nếu đúng và 0 nếu sai ❖Hàm Tra cứu phiếu cho mượn sách: Tra cứu các phiếu mượn sách theo nhiều tiêu chuẩn để cập nhật hay số phiếu cho mượn ❖Hàm Xóa phiếu cho mượn sách: Xóa thông tin việc mượn sách trong kho ❖Hàm Trả sách: Ghi nhận việc trả sách trong kho ❖Hàm Tính tiền phạt: Tính tiền phạt khi độc giả trả sách trễ hạn Jens Martensson 49
  49. 3.4. Ví dụ minh hoạ ❑Hệ thống các bảng dữ liệu ❖Bảng THU_VIEN: các thông tin về thư viện ❖Bảng DOC_GIA: các thông tin về độc giả ❖Bảng SACH: các thông tin về sách ❖Bảng MUON_SACH: các thông tin về mượn trả sách Jens Martensson 50
  50. Câu hỏi 1. Theo 6 nguyên tắc, Kỷ luật thứ ba là gì? A. Triển khai B. Thực hiện C. Mô hình hóa kinh doanh D. Thiết kế Jens Martensson 51
  51. Câu hỏi 2. Các bước được gọi trong Quy trình hợp nhất (UP) là gì A. Lặp lại (Iterations) B. Vòng đời phát triển hệ thống(System Development Life Cycle) C. Kỷ luật (Disciplines) D. Kiến trúc thông tin (Information Architecture) Jens Martensson 52
  52. Câu hỏi 3. KHÔNG phải là một hoạt động thiết kế chi tiết? A. Thiết kế phần mềm ứng dụng B. Thiết kế các cơ chế sao lưu và phục hồi hệ thống C. Thiết kế giao diện người dùng và hệ thống bên ngoài D. Thiết kế kiến trúc Jens Martensson 53
  53. Câu hỏi 4. ___ là các yêu cầu và ràng buộc xác định các đặc điểm quan trọng của tài nguyên xử lý thông tin và cách chúng tương tác. A. Kiến trúc hệ thống B. Kiến trúc thông tin C. Kiến trúc Internet D. Thực hiện Jens Martensson 54