Bài giảng Công nghệ phần mềm - Bài 3: Phân tích và Thiết kế Hệ thống thông tin - Lê Nguyễn Tuấn Thành

Nội dung text: Bài giảng Công nghệ phần mềm - Bài 3: Phân tích và Thiết kế Hệ thống thông tin - Lê Nguyễn Tuấn Thành

1. Công nghệ Phần mềm Phân tích và Thiết kế Hệ thống thông tin Giảng viên: Lê Nguyễn Tu ấn Thành Email: thanhlnt@tlu.edu.vn Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT Trường Đại Học Thủy Lợi
2. Nội dung } Phân tích và thiết kế kiến trúc } Phân tích và thiết kế hướng đối tượng } Phân tích và thiết kế giao diện Bài giảng có sử dụng hình vẽ trong cuốn sách “Software Engineering, Ian Sommerville, 8th Edition, 2007” 2
3. 1. Thiết kế kiến trúc Architectural design 3
4. Mục tiêu } Giới thiệu thiết kế kiến trúc và thảo luận tầm quan trọng của nó } Giới thiệu ba phong cách thiết kế kiến trúc: } Tổ chức (organisation), } Chia nhỏ (decomposition), } Kiểm soát (control) 4
5. Chủ đề được đề cập (Topics covered) } Phong cách tổ chức hệ thống (System organisation) } Phong cách chia nhỏ (Decomposition styles) } Phong cách kiểm soát (Control styles) 5
6. 1.1. Thiết kế Kiến trúc Phần mềm (Software architecture) } Là quá trình thiết kế để xác định những hệ thống con tạo nên một hệ thống và khung làm việc (framework) giúp kiểm soát và giao tiếp giữa các hệ thống con này. } Đầu ra của quá trình thiết kế này là một mô tả về Kiến trúc Phần mềm. } Đây là giai đoạn đầu của quá trình thiết kế hệ thống. } Biểu thị mối liên hệ giữa đặc tả yêu cầu và quá trình thiết kế. } Thường được thực hiện song song với một số hoạt động đặc tả yêu cầu. 6
7. Ưu điểm của một kiến trúc rõ ràng (Advantages of explicit architecture) } Giao tiếp của các bên liên quan (Stakeholder) } Kiến trúc có thể được sử dụng trong các cuộc thảo luận giữa các bên liên quan đến hệ thống. } Phân tích hệ thống } Kiến trúc giúp phân tích xem liệu hệ thống có đáp ứng các yêu cầu không chức năng của nó hay không. } Tái sử dụng quy mô lớn (Large-scale reuse) } Kiến trúc có thể được tái sử dụng trên một dải các hệ thống tương tự. } Các hệ thống trong cùng một miền thường có các kiến trúc tương tự phản ánh khái niệm miền. 7
8. Hệ thống Kiểm soát robot đóng gói (Packing robot control system) 8
9. 1.2. Những phong cách kiến trúc (Architectural styles) } Kiến trúc của một hệ thống có thể phù hợp với một mô hình hoặc một kiểu kiến trúc chung. } Nhận thức về những kiểu kiến trúc này giúp đơn giản hóa vấn đề định nghĩa kiến trúc hệ thống. } Tuy nhiên, hầu hết các hệ thống lớn đều không đồng nhất và không chỉ theo một kiểu kiến trúc đơn nào. 9
10. Các mô hình kiến trúc (Architectural models) } Được sử dụng để tài liệu hóa một thiết kế kiến trúc. } Mô hình cấu trúc tĩnh thể hiện các thành phần hệ thống chính. } Mô hình quy trình động thể hiện cấu trúc quy trình của hệ thống. } Mô hình giao diện định nghĩa các giao diện hệ thống con. } Mô hình mối quan hệ như mô hình luồng dữ liệu thể hiện các mối quan hệ giữa các hệ thống con. } Mô hình phân phối thể hiện cách các hệ thống con được phân phối trên máy tính. 10
11. 1.2.1. Phong cách tổ chức hệ thống (System organisation) } Phản ánh chiến lược cơ bản được sử dụng để cấu trúc một hệ thống. } Ba mô hình tổ chức được sử dụng rộng rãi: 1. Kiểu kho dữ liệu chia sẻ; 2. Kiểu máy chủ và dịch vụ chia sẻ; 3. Kiểu tầng và máy trừu tượng. 11
12. Mô hình kho lưu trữ chia sẻ (Repository model) } Các hệ thống con phải trao đổi dữ liệu. Điều này có thể được thực hiện theo 2 cách: 1. Dữ liệu chia sẻ được lưu trữ trong cơ sở dữ liệu trung tâm hoặc kho lưu trữ và có thể được truy cập bởi tất cả các hệ thống con; hoặc 2. Mỗi hệ thống con tự duy trì cơ sở dữ liệu riêng của nó và truyền dữ liệu một cách tường minh tới các hệ thống con khác. } Khi số lượng lớn dữ liệu được chia sẻ, mô hình kho dữ liệu chia sẻ thường được sử dụng. 12
13. VD Mô hình Kho lưu trữ: Kiến trúc bộ công cụ CASE 13
14. Những đặc điểm của mô hình kho lưu trữ (Repository model characteristics) } Ưu điểm } Cách hiệu quả để chia sẻ số lượng lớn dữ liệu; } Các hệ thống con không cần phải liên quan đến cách dữ liệu được tạo ra } Quản lý tập trung, ví dụ: sao lưu, an ninh, v.v. } Mô hình chia sẻ được công bố như giản đồ kho lưu trữ. } Nhược điểm } Các hệ thống con phải đồng ý về một mô hình dữ liệu kho lưu trữ. } Việc tiến hóa dữ liệu là khó khăn và tốn kém; } Khó phân bố hiệu quả. 14
15. Mô hình Máy khách-Máy chủ (Client-server model) } Mô hình hệ thống phân tán biểu diễn cách dữ liệu và việc xử lý được phân phối trên một khoảng các thành phần. } Tập các máy chủ độc lập cung cấp các dịch vụ cụ thể như in ấn, quản lý dữ liệu, v.v. } Tập các máy khách gọi đến các dịch vụ này. } Mạng cho phép máy khách truy cập máy chủ. 15
16. Thư viện phim và hình ảnh (Film and picture library) 16
17. Đặc điểm của Mô hình Máy khách-Máy chủ (Client-server characteristics) } Ưu điểm } Sự phân phối của dữ liệu là minh bạch } Sử dụng hiệu quả các hệ thống mạng } Dễ dàng thêm các máy chủ mới hoặc nâng cấp các máy chủ hiện có. } Nhược điểm } Không có mô hình dữ liệu được chia sẻ nên các hệ thống con tự tổ chức dữ liệu khác nhau. } Trao đổi dữ liệu có thể không hiệu quả; } Quản lý dự phòng trong mỗi máy chủ 17
18. Mô hình tầng/máy trừu tượng } Được sử dụng để mô hình hóa giao diện của các hệ thống con. } Tổ chức hệ thống thành một tập các tầng (hoặc các máy trừu tượng), mỗi tầng cung cấp một tập các dịch vụ. } Hỗ trợ sự phát triển gia tăng của các hệ thống con trong các tầng khác nhau. Khi một tầng giao diện thay đổi, chỉ có các tầng lân cận bị ảnh hưởng. 18
19. VD: Hệ thống quản lý phiên bản (Version management system) 19
20. 1.2.2. Phong cách chia nhỏ thành các Mô-đun } Phong cách chia nhỏ hệ thống con thành các mô-đun. } Hệ thống con là một hệ thống có quyền riêng của nó } Hoạt động độc lập với các dịch vụ được cung cấp bởi các hệ thống con khác. } Mô-đun là một thành phần hệ thống cung cấp các dịch vụ cho các thành phần khác } Thường sẽ không được xem như một hệ thống riêng biệt. } 2 mô hình chia nhỏ mô-đun: } Mô hình đối tượng: hệ thống được phân chia thành đối tượng tương tác; } Mô hình đường ống (pipeline) hay mô hình luồng dữ liệu (data-flow): hệ thống được phân chia thành các mô-đun chức năng để chuyển đổi từ đầu vào đến đầu ra. 20
21. Mô hình đối tượng (Object models) } Cấu trúc hệ thống thành một tập hợp các đối tượng lỏng lẻo với các giao diện được định nghĩa rõ ràng. } Sự phân chia hướng đối tượng liên quan đến việc xác định các lớp đối tượng, các thuộc tính và hoạt động của chúng. } Khi được cài đặt, các đối tượng được tạo ra từ các lớp này và một vài mô hình điều khiển được sử dụng để phối hợp các hoạt động của đối tượng. 21
22. VD: Hệ thống Xử lý Hoá đơn (Invoice processing system) 22
23. Ưu điểm của Mô hình Đối tượng } Đối tượng được kết hợp lỏng lẻo vì thế cài đặt của chúng có thể được thay đổi mà không ảnh hưởng đến các đối tượng khác. } Ngôn ngữ lập trình hướng đối tượng được sử dụng rộng rãi. } Tuy nhiên, giao diện đối tượng thay đổi có thể gây ra nhiều vấn đề và các thực thể phức tạp có thể khó biểu diễn thành các đối tượng. 23
24. Mô hình Đường ống hướng Chức năng (Function-oriented pipelining) } Là quá trình biến đổi chức năng, xử lý đầu vào của chúng để tạo ra kết quả đầu ra. } Còn được gọi là mô hình đường ống và bộ lọc (như shell UNIX). } Các biến thể của cách tiếp cận này rất phổ biến. } Khi sự chuyển đổi là tuần tự, đây là một mô hình tuần tự theo lô (batch) được sử dụng rộng rãi trong các hệ thống xử lý dữ liệu. } Không thực sự phù hợp với các hệ thống tương tác. 24
25. VD: Hệ thống xử lý hoá đơn (Invoice processing system) 25
26. Lợi ích của mô hình đường ống (Pipeline model advantages) } Hỗ trợ tái sử dụng chuyển đổi. } Tổ chức trực quan cho việc giao tiếp giữa các bên liên quan. } Dễ dàng thêm các biến đổi mới. } Tương đối đơn giản để cài đặt như một hệ thống đồng thời hoặc tuần tự. } Tuy nhiên, mô hình này yêu cầu một định dạng chung cho việc truyền dữ liệu dọc theo đường ống và khó khăn để hỗ trợ sự tương tác dựa trên sự kiện. 26
27. 1.2.3. Phong cách điều khiển (Control styles) } Liên quan đến luồng điều khiển giữa các hệ thống con. } Điều khiển tập trung (Centralised control) } Một hệ thống con có trách nhiệm kiểm soát chung và có quyền khởi động và ngừng các hệ thống con khác. } Điều khiển dựa trên sự kiện (Event-based control) } Mỗi hệ thống con có thể phản ứng các sự kiện bên ngoài từ các hệ thống con khác hoặc từ môi trường của hệ thống. 27
28. Điều khiển tập trung (Centralised control) } Một hệ thống con kiểm soát có trách nhiệm quản lý việc thực hiện của các hệ thống con khác. } Mô hình Gọi-Trả_về (Call-return model) } Mô hình chương trình con điều khiển từ trên xuống dưới. } Mô hình Nhà quản lý (Manager model) } Một thành phần hệ thống điều khiển việc dừng, khởi động và điều phối các hệ thống khác. 28
29. Mô hình Gọi-Trả_về (Call-return model) 29
30. VD: Mô hình Nhà quản lý Hệ thống thời gian thực 30
31. Điều khiển dựa trên hướng sự kiện } Được kích hoạt bởi các sự kiện bên ngoài } 2 mô hình hướng sự kiện chính: 1. Mô hình quảng bá (broadcast models). Sự kiện được truyền tới tất cả các hệ thống con. Bất kỳ hệ thống con nào có thể xử lý sự kiện này đều có thể thực hiện nó; 2. Mô hình hướng ngắt (interrupt-driven models). Được sử dụng trong các hệ thống thời gian thực nơi mà các ngắt được phát hiện bởi một trình xử lý ngắt và được truyền cho một số thành phần khác để xử lý. 31
32. Mô hình Quảng bá (Broadcast models) } Các hệ thống con đăng ký sự quan tâm của mình đến các sự kiện cụ thể. } Khi những sự kiện này xảy ra, quyền kiểm soát được chuyển cho hệ thống con có thể xử lý sự kiện này. } Tuy nhiên, các hệ thống con không biết liệu hay khi nào một sự kiện sẽ được xử lý. 32
33. Quảng bá chọn lọc (Selective broadcasting) 33
34. Hệ thống hướng ngắt (Interrupt-driven systems) } Được sử dụng trong các hệ thống thời gian thực khi mà việc phản ứng nhanh với một sự kiện là điều tối cần thiết. } Mỗi loại ngắt được liên kết với một vị trí bộ nhớ và một chuyển đổi phần cứng gây ra việc chuyển giao cho trình xử lý của nó. 34
35. Điều khiển hướng ngắt (Interrupt-driven control) 35
36. Tóm tắt các điểm chính (Key points) } Kiến trúc phần mềm là khung nền tảng (fundamental framework) để cấu trúc hệ thống. } Các quyết định thiết kế kiến trúc bao gồm các quyết định về kiến trúc ứng dụng, sự phân bố và các phong cách kiến trúc được sử dụng. } Các phong cách kiến trúc khác nhau như: phong cách tổ chức hệ thống, phong cách chia nhỏ và phong cách điều khiển có thể được phát triển. } Các mô hình tổ chức hệ thống bao gồm: mô hình kho lưu trữ, mô hình máy khách-máy chủ và mô hình tầng/máy trừu tượng. } Mô hình phân chia mô-đun bao gồm: mô hình đối tượng và mô hình đường ống. } Các mô hình điều khiển bao gồm: mô hình điều khiển tập trung và mô hình điều khiển hướng sự kiện. 36
37. 2. Thiết kế hướng đối tượng Object-oriented design 37
38. Mục tiêu } Giải thích cách một thiết kế phần mềm có thể được biểu diễn bằng một tập các đối tượng tương tác để quản lý trạng thái và hoạt động của chúng } Miêu tả các hoạt động trong quá trình thiết kế hướng đối tượng } Giới thiệu các mô hình khác nhau có thể được sử dụng để miêu tả một thiết kế hướng đối tượng } Chỉ ra cách UML có thể được sử dụng để biểu diễn cho các mô hình này 38
39. Chủ đề được đề cập (Topics covered) } Đối tượng và Lớp đối tượng } Một quy trình thiết kế hướng đối tượng 39
40. Phát triển hướng đối tượng (Object-oriented development) } Phân tích, thiết kế và lập trình hướng đối tượng có liên quan nhưng khác biệt } OOA liên quan đến việc phát triển một mô hình đối tượng của miền ứng dụng. } OOD liên quan đến việc phát triển một mô hình hệ thống hướng đối tượng để cài đặt các yêu cầu. } OOP liên quan đến việc thực hiện một OOD bằng cách sử dụng một ngôn ngữ lập trình OO như Java hay C ++. 40
41. Đặc điểm và Ưu điểm của OOD (Characteristics & Advantages of OOD) } Đặc điểm: } Đối tượng là khái niệm trừu tượng của thực thể tổ chức hoặc trong thực tế và chúng tự quản lý chính mình. } Đối tượng là độc lập và đóng gói thông tin miêu tả và trạng thái. } Chức năng của hệ thống được thể hiện dưới dạng các dịch vụ của đối tượng. } Các đối tượng giao tiếp bằng việc truyền thông điệp. } Ưu điểm: } Bảo trì dễ dàng hơn. } Đối tượng là các thành phần tái sử dụng tiềm năng. 41
42. Đối tượng tương tác (Interacting objects) 42
43. Đối tượng và Lớp đối tượng (Objects and object classes) } Đối tượng là một thực thể trong một hệ thống phần mềm biểu diễn các trường hợp cụ thể của các thực thể trong thế giới thực và hệ thống. } Lớp đối tượng là các khuôn mẫu cho các đối tượng. Chúng có thể được sử dụng để tạo ra đối tượng. } Lớp đối tượng có thể kế thừa các thuộc tính và dịch vụ từ các lớp đối tượng khác. 43
44. UML (Unified Modeling Language) } Nhiều ký hiệu khác nhau để miêu tả thiết kế hướng đối tượng đã được đề xuất trong những năm 1980 và 1990. } UML là một tích hợp của các ký hiệu này } Miêu tả ký hiệu cho một số mô hình khác nhau có thể được tạo ra trong quá trình phân tích và thiết kế OO. } Bây giờ nó là một tiêu chuẩn trên thực tế (de facto) cho mô hình hóa OO. 44
45. VD: Lớp đối tượng Nhân viên - UML (Employee object class) 45
46. Giao tiếp giữa Đối tượng (Object communication) } Về mặt lý thuyết, các đối tượng giao tiếp bằng việc truyền thông điệp. } Thông điệp (messages) } Tên của dịch vụ được yêu cầu bởi đối tượng gọi; } Bản sao của thông tin được yêu cầu để thực hiện dịch vụ và tên của đối tượng giữ cho kết quả của dịch vụ. } Trong thực tế, thông điệp thường được cài đặt bằng các lời gọi hàm } Tên = tên hàm; } Thông tin = danh sách tham số. 46
47. VD: Thông điệp // Gọi một phương thức kết hợp với một đối tượng // bộ đệm trả về giá trị tiếp theo trong bộ đệm v = circularBuffer.Get(); // Gọi phương thức liên kết với một đối tượng điều // chỉnh nhiệt để đặt nhiệt độ duy trì ở mức 20 thermostat.setTemp(20); 47
48. Tổng quát hóa và Kế thừa (Generalisation and inheritance) } Các lớp có thể được sắp xếp trong một hệ thống cấp bậc của lớp, } Trong đó một lớp (một siêu lớp – lớp cha) là sự tổng quát của một hoặc nhiều lớp khác (các lớp con). } Một lớp con kế thừa các thuộc tính và hành động từ lớp cha của nó và có thể thêm các phương thức hoặc thuộc tính mới của riêng nó. } Sự tổng quát hóa trong UML được cài đặt bằng khái niệm thừa kế trong các ngôn ngữ lập trình OO. 48
49. VD: Một Hệ thống Phân cấp 49
50. Ưu điểm và Nhược điểm của Kế thừa } Ưu điểm } Là một cơ chế trừu tượng có thể được sử dụng để phân loại thực thể. } Là một cơ chế tái sử dụng ở cả mức thiết kế và lập trình. } Đồ thị thừa kế là một nguồn kiến thức tổ chức về các lĩnh vực và hệ thống. } Nhược điểm } Các lớp đối tượng không thể hiểu được mà không tham khảo đến các lớp cha. } Đồ thị thừa kế của quá trình phân tích, thiết kế và cài đặt có các chức năng khác nhau và cần được duy trì riêng biệt. 50
51. Liên kết trong UML (UML associations) } Đối tượng và lớp đối tượng tham gia vào các mối quan hệ với đối tượng và lớp đối tượng khác. } Trong UML, một mối quan hệ tổng quát được biểu diễn bằng một liên kết. } Các liên kết có thể được chú thích với thông tin miêu tả về liên kết đó. 51
52. VD: Mô hình liên kết 52
53. Mối Quan hệ giữa các Lớp đối tượng 53
54. Quy trình Thiết kế hướng đối tượng (Object-oriented design process) 1. Xác định bối cảnh và phương thức sử dụng của hệ thống; 2. Thiết kế kiến trúc hệ thống; 3. Xác định các đối tượng hệ thống chính; 4. Phát triển các mô hình thiết kế; 5. Xác định giao diện đối tượng. 54
55. Xét Bài toán: Hệ thống thời tiết Một hệ thống bản đồ thời tiết được yêu cầu phát triển nhằm tạo ra các bản đồ thời tiết một cách thường xuyên sử dụng dữ liệu thu thập được từ các trạm thời tiết ở xa và từ các nguồn dữ liệu khác (như: những người quan sát thời tiết, bóng bay và vệ tinh). Các trạm thời tiết truyền dữ liệu của chúng tới máy tính trong khu vực để trả lời một yêu cầu phát sinh từ máy tính đó. Hệ thống máy tính khu vực xác thực dữ liệu thu thập được và tích hợp nó với dữ liệu từ nhiều nguồn khác nhau. Dữ liệu tích hợp được lưu trữ. Một cơ sở dữ liệu bản đồ được số hóa, một tập bản đồ thời tiết địa phương được tạo ra. Bản đồ có thể được in để phân phối trên một máy in bản đồ với mục đích đặc biệt hoặc có thể được hiển thị với một số định dạng khác nhau. 55
56. Q1. Bối cảnh hệ thống và Mô hình sử dụng } Phát triển sự hiểu biết về mối quan hệ giữa phần mềm được thiết kế và môi trường bên ngoài. } Ngữ cảnh hệ thống } Một mô hình tĩnh miêu tả các hệ thống khác trong môi trường. Sử dụng mô hình hệ thống con để hiển thị các hệ thống khác. } Mô hình sử dụng hệ thống } Một mô hình động miêu tả cách hệ thống tương tác với môi trường của nó. Sử dụng use-case để hiển thị các tương tác 56
57. Q2. Kiến trúc phân tầng (Layered architecture) 57
58. Hệ thống con trong hệ thống bản đồ thời tiết 58
59. Mô hình Use-case } Mô hình use-case được sử dụng để biểu diễn từng tương tác với hệ thống. } Một mô hình use-case biểu diễn các tính năng hệ thống bằng những hình e-lip và các thực thể tương tác bằng một hình người. 59
60. Use-case cho Trạm thời tiết 60
61. Miêu tả Use-case Hệ thống Trạm thời tiết Use-case Báo cáo Tác nhân Hệ thống thu thập dữ liệu thời tiết, Trạm thời tiết (Actors) Dữ liệu Trạm thời tiết gửi một bản tóm tắt các dữ liệu thời tiết đã được thu thập từ các thiết bị trong giai đoạn thu thập đến hệ thống thu thập dữ liệu thời tiết. Dữ liệu được gửi là nhiệt độ không khí và mặt đất tối thiểu, tối đa và trung bình; áp suất không khí tối đa, tối thiểu và trung bình; tốc độ gió tối đa, tối thiểu và trung bình; tổng lượng mưa và hướng gió được lấy mẫu ở mỗi 5 phút. Kích hoạt Hệ thống thu thập dữ liệu thời tiết thiết lập một liên kết với trạm thời (Stimulus) tiết và yêu cầu truyền tải dữ liệu Phản ứng Dữ liệu tóm tắt được gửi tới hệ thống thu thập dữ liệu thời tiết Bình luận Các trạm thời tiết thường được yêu cầu báo cáo một lần một giờ (Comments) nhưng tần suất này có thể khác nhau với mỗi trạm và có thể được thay đổi trong tương lai. 61
62. Thiết kế Kiến trúc (Architectural design) } Khi đã hiểu tương tác giữa hệ thống và môi trường của nó, sử dụng thông tin này để thiết kết kiến trúc hệ thống. } Một kiến trúc phân tầng là phù hợp với bài toán trạm thời tiết } Thường có không quá 7 thực thể trong một mô hình kiến trúc. 62
63. Kiến trúc của Hệ thống Trạm thời tiết (Weather station architecture) 63
64. Q3. Nhận dạng Đối tượng (Object identification) } Xác định đối tượng (hoặc các lớp đối tượng) là phần khó nhất của thiết kế hướng đối tượng. } Không có 'công thức kỳ diệu' để nhận dạng đối tượng. } Nó dựa vào các kỹ năng, kinh nghiệm và kiến thức miền của những nhà thiết kế hệ thống. } Nhận dạng đối tượng là một quá trình lặp. Bạn không thể làm cho nó đúng ngay trong bước đầu tiên. 64
65. Phương pháp tiếp cận để nhận dạng (Approaches to identification) } Sử dụng cách tiếp cận ngữ pháp dựa trên mô tả ngôn ngữ tự nhiên của hệ thống (sử dụng trong phương pháp Hood OOD). } Dựa trên việc nhận dạng các vật hữu hình trong miền ứng dụng. } Sử dụng cách tiếp cận hành vi và xác định các đối tượng dựa trên những ai tham gia vào hành vi nào. } Sử dụng một phân tích dựa trên kịch bản. Các đối tượng, thuộc tính và phương pháp trong từng kịch bản được xác định. 65
66. Xét Mô tả về Trạm thời tiết (Weather station description) Một trạm thời tiết là một gói các công cụ phần mềm điều khiển để thu thập dữ liệu, thực hiện một số xử lý dữ liệu và truyền dữ liệu này cho các bước xử lý tiếp theo. Các thiết bị bao gồm nhiệt kế không khí và mặt đất, máy đo nhiệt độ, cánh gió, áp kế và đo mưa. Dữ liệu được thu thập định kỳ. Khi một lệnh được phát ra để truyền dữ liệu thời tiết, trạm thời tiết xử lý và tóm tắt dữ liệu thu thập được. Dữ liệu tóm tắt được truyền tới máy tính lập bản đồ khi nhận được yêu cầu phát sinh từ máy tính đó. 66
67. Các lớp đối tượng của trạm thời tiết (1/2) (Weather station object classes) } Nhiệt kế mặt đất, Phong kế, Phong vũ biểu (Ground thermometer, Anemometer, Barometer) } Các đối tượng miền ứng dụng là các đối tượng 'phần cứng' liên quan đến các thiết bị trong hệ thống. } Trạm thời tiết } Giao diện cơ bản của trạm khí tượng với môi trường của nó. Do đó nó phản ánh các tương tác được định nghĩa trong mô hình use-case. } Dữ liệu thời tiết } Đóng gói dữ liệu tóm tắt từ các thiết bị. 67
68. Các lớp đối tượng của trạm thời tiết (2/2) (Weather station object classes) 68
69. Q4. Các mô hình thiết kế (Design models) } Mô hình thiết kế hiển thị đối tượng và lớp đối tượng và mối quan hệ giữa các thực thể này. } Mô hình tĩnh miêu tả cấu trúc tĩnh của hệ thống dưới dạng các lớp đối tượng và các mối quan hệ. } Mô hình động miêu tả sự tương tác động giữa các đối tượng. 69
70. VD Các Mô hình Thiết kế (Examples of design models) } Mô hình hệ thống con (Sub-system models): thể hiện các nhóm lô gic của các đối tượng trong các hệ thống con mạch lạc. } Mô hình trình tự (Sequence models): thể hiển chuỗi tương tác giữa các đối tượng. } Mô hình trạng thái: thể hiển cách đối tượng đơn thay đổi trạng thái của chúng để phản ứng với các sự kiện. } Các mô hình khác bao gồm mô hình use-case, mô hình tập hợp (aggregation), mô hình tổng quát (generalisation), v.v. 70
71. Mô hình hệ thống con (Sub-system models) } Chỉ ra cách thiết kế được tổ chức thành các nhóm đối tượng liên quan. } Trong UML, chúng được thể hiển bằng các gói (packages) - một cấu trúc đóng gói. Đây là một mô hình logic. Việc tổ chức thực sự của các đối tượng trong hệ thống có thể khác nhau. 71
72. Hệ thống con trạm thời tiết (Weather station subsystems) 72
73. Mô hình trình tự (Sequence models) } Các mô hình trình tự hiển thị chuỗi tương tác giữa các đối tượng xảy ra: } Các đối tượng được sắp xếp ở hàng ngang trên cùng; } Thời gian được biểu diễn theo chiều dọc vì vậy các mô hình được đọc từ trên xuống dưới; } Tương tác được biểu diễn bằng mũi tên có nhãn, Các kiểu mũi tên khác nhau biểu thị các loại tương tác khác nhau; } Một hình chữ nhật mỏng trên vòng đời của đối tượng biểu diễn thời gian khi đối tượng là thực thể đang kiểm soát trong hệ thống. 73
74. Trình tự thu thập dữ liệu (Data collection sequence) 74
75. Biểu đồ trạng thái (Statecharts) } Chỉ ra cách đối tượng phản ứng với các yêu cầu dịch vụ khác nhau và sự chuyển tiếp trạng thái được kích hoạt bởi các yêu cầu này } Nếu trạng thái đối tượng là Shutdown thì nó trả lời một thông báo Startup(); } Trong trạng thái chờ đợi, đối tượng đang chờ các thông điệp về sau; } Nếu reportWeather() thì sau đó hệ thống di chuyển đến trạng thái tổng kết; } Nếu calibrate() hệ thống sẽ chuyển sang trạng thái hiệu chỉnh; } Một trạng thái thu thập được kích hoạt khi nhận được một tín hiệu đồng hồ. 75
76. Sơ đồ trạng thái trạm thời tiết (Weather station state diagram) 76
77. Q5. Đặc tả giao diện đối tượng (Object interface specification) } Giao diện đối tượng phải được xác định sao cho các đối tượng và các thành phần khác có thể được thiết kế song song. } Đối tượng có thể có một số giao diện về quan điểm với các phương pháp được cung cấp. } UML sử dụng sơ đồ lớp cho các đặc tả giao diện nhưng ngôn ngữ Java cũng có thể được sử dụng. 77
78. Giao diện trạm thời tiết (Weather station interface) 78
79. Tóm tắt các điểm chính (Key points) } OOD là một cách tiếp cận để thiết kế các thành phần có trạng thái và hoạt động riêng của chúng. } Đối tượng phải có các hoạt động khởi tạo và kiểm tra. Chúng cung cấp dịch vụ cho các đối tượng khác. } Đối tượng có thể được cài đặt tuần tự hoặc đồng thời. } UML cung cấp các ký hiệu khác nhau để định nghĩa các mô hình đối tượng khác nhau. } Một khoảng các mô hình khác nhau có thể được sản xuất trong quá trình thiết kế hướng đối tượng. Chúng bao gồm các mô hình hệ thống tĩnh và động. } Giao diện đối tượng phải được định nghĩa chính xác, có thể bằng cách sử dụng một ngôn ngữ lập trình như Java. 79
80. 3. Thiết kế Giao diện người dùng User interface design 80
81. Mục tiêu } Đề xuất một số nguyên tắc thiết kế chung cho thiết kế giao diện người dùng } Giải thích các phong cách tương tác khác nhau và cách sử dụng của chúng } Giải thích khi nào sử dụng biểu diễn thông tin dạng đồ họa và văn bản } Giải thích các hoạt động chính trong quá trình thiết kế giao diện người dùng } Giới thiệu các thuộc tính khả dụng và cách tiếp cận để đánh giá hệ thống 81
82. Các chủ đề được đề cập (Topics covered) } Quá trình thiết kế giao diện người dùng } Phân tích người dùng } Nguyên mẫu giao diện người dùng } Đánh giá giao diện 82
83. Giao diện người dùng } Giao diện người dùng nên được thiết kế để phù hợp với kỹ năng, kinh nghiệm và mong đợi của những người dùng dự kiến. } Người dùng hệ thống thường đánh giá một hệ thống qua giao diện hơn là chức năng của nó. } Một giao diện được thiết kế tồi có thể khiến người dùng tạo ra một lỗi thảm họa. } Thiết kế giao diện người dùng kém là lý do tại sao rất nhiều hệ thống phần mềm không bao giờ được sử dụng. 83
84. Yếu tố con người trong thiết kế giao diện (Human factors in interface design) } Bộ nhớ ngắn hạn (Limited short-term memory) } Mọi người có thể ngay lập tức nhớ khoảng 7 thông tin. Nếu bạn trình bày nhiều hơn số này, họ thường mắc sai lầm nhiều hơn. } Con người dễ mắc sai lầm } Khi mọi người mắc sai lầm và hệ thống xử lý sai, các báo động và thông điệp không thích hợp có thể làm tăng căng thẳng và do đó lại khiến khả năng mắc nhiều lỗi hơn. } Mọi người là khác nhau } Con người có nhiều khả năng thể chất vật lý. Người thiết kế nên không chỉ thiết kế cho khả năng của bản thân mình. } Mọi người có sở thích tương tác khác nhau } Một số giống như hình ảnh, một số giống như văn bản. 84
85. Nguyên tắc thiết kế giao diện người dùng (1/2) (UI design principles) } Thiết kế UI phải tính đến nhu cầu, kinh nghiệm và khả năng của người sử dụng hệ thống. } Người thiết kế nên nhận thức được những hạn chế về thể chất và tinh thần của con người (ví dụ như bộ nhớ ngắn hạn) và phải nhận ra rằng mọi người đều mắc phải sai lầm. 85
86. Nguyên tắc thiết kế giao diện người dùng (2/2) (UI design principles) Nguyên tắc Miêu tả Thân thiện người dùng Giao diện nên sử dụng thuật ngữ và khái niệm (User familiarity) được rút ra từ kinh nghiệm của những người chính của hệ thống. Tính nhất quán Giao diện phải nhất quán trong đó, nếu có thể, các (Consistency) hoạt động giống nhau phải được kích hoạt theo cùng một cách. Ít gây ngạc nhiên Người dùng không nên bị ngạc nhiên trước một (Minimal surprise) hành vi của hệ thống Khả năng phục hồi Giao diện nên bao gồm các cơ chế để cho phép (Recoverability) người dùng khôi phục lại từ các lỗi. Hướng dẫn người dùng Giao diện nên cung cấp phản hồi có ý nghĩa khi xảy (User guidance) ra lỗi và cung cấp các phương tiện trợ giúp người dùng. Đa dạng người dùng Giao diện nên cung cấp các phương tiện tương tác (User diversity) thích hợp với từng loại người dùng hệ thống. 86
87. Phong cách tương tác (Interaction styles) Phong cách Ưu điểm Nhược điểm chính Ví dụ tương tác chính ứng dung Thao tác Tương tác nhanh và Có thể khó cài đặt. Trò chơi điện tử trực tiếp trực quan Chỉ thích hợp khi có phép ẩn dụ Hệ thống CAD Dễ học trực quan cho các tác vụ và đối tượng. Lựa chọn Tránh lỗi người dùng Chậm với người dùng có kinh Hầu hết các hệ thống menu Yêu cầu phải gõ ít nghiệm. mục đích chung Có thể trở nên phức tạp nếu có nhiều lựa chọn trong menu. Điền vào biểu Nhập dữ liệu đơn Chiếm nhiều không gian màn Kiểm soát chứng khoán, mẫu giản hình. xử lý khoản vay cá nhân Dễ học Gây ra vấn đề khi các tùy chọn Kiểm tra được người dùng không khớp với các trường biểu mẫu. Ngôn ngữ Mạnh mẽ và linh hoạt Khó học. Hệ điều hành, Hệ thống mệnh lệnh Quản lý lỗi kém. chỉ huy và điều khiển Ngôn ngữ tự Khả dụng cho người Yêu cầu gõ nhiều hơn. Hệ thống thu thập thông nhiên dùng bình thường Hệ thống hiểu biết ngôn ngữ tự tin Dễ dàng mở rộng nhiên không đáng tin cậy. 87
88. Giao diện nhiều người dùng (Multiple user interfaces) 88
89. Tương tác với hệ thống LIBSYS (LIBSYS interaction) } Tìm kiếm tài liệu } Người dùng cần có khả năng sử dụng các tính năng tìm kiếm để tìm các tài liệu họ cần. } Yêu cầu tài liệu } Người dùng yêu cầu một tài liệu được gửi đến máy của họ hoặc đến một máy chủ để in. 89
90. Giao diện mẫu cho chức năng tìm kiếm LIBSYS (LIBSYS search form) 90
91. Biểu diễn thông tin (1/3) (Information presentation) } Biểu diễn thông tin liên quan đến việc trình bày thông tin hệ thống cho người dùng. } Thông tin có thể được trình bày trực tiếp (ví dụ: văn bản trong bộ xử lý văn bản) hoặc có thể được chuyển đổi theo cách nào đó để biểu diễn (ví dụ: ở dạng đồ hoạ). } Cách tiếp cận Mô_hình-Góc_nhìn-Điều_khiển (Model-View-Controller) là một cách để hỗ trợ nhiều kiểu biểu diễn cho dữ liệu. 91
92. Biểu diễn thông tin (2/3) (Information presentation) 92
93. Biểu diễn thông tin (3/3) (Information presentation) } Thông tin tĩnh } Được khởi tạo vào đầu phiên (session). Nó không thay đổi trong phiên. } Thông tin động } Thay đổi trong phiên và những thay đổi phải được thông báo cho người sử dụng hệ thống. 93
94. Một số phương pháp biểu diễn dữ liệu (1/2) 94
95. Một số phương pháp biểu diễn dữ liệu (2/2) 95
96. Hiển thị màu sắc (Colour displays) } Màu sắc bổ sung thêm thông tin cho một giao diện và có thể giúp người sử dụng hiểu các cấu trúc thông tin phức tạp. } Màu sắc có thể được sử dụng để làm nổi bật các sự kiện đặc biệt. } Sai lầm phổ biến trong việc sử dụng màu sắc trong thiết kế giao diện bao gồm: } Sử dụng quá mức màu sắc trong hiển thị. } Hướng dẫn sử dụng màu sắc: } Hạn chế số lượng màu được sử dụng. } Sử dụng sự thay đổi màu sắc để hiển thị thay đổi trạng thái hệ thống. 96
97. Thông báo lỗi (Error messages) } Thiết kế thông báo lỗi rất quan trọng. Thông báo lỗi tồi có thể khiến người dùng từ chối hệ thống. } Nền tảng và kinh nghiệm của người sử dụng nên là yếu tố quyết định trong thiết kế thông báo. } Thông báo phải: lịch sự, súc tích, nhất quán và xây dựng. } Các nhân tố thiết kế trong cách diễn đạt thông báo: } Ngữ cảnh (context) } Kinh nghiệm (experience) } Kỹ năng (skill) } Phong cách (style) } Văn hóa (culture) 97
98. Ví dụ về Lỗi người dùng (User error) } Giả sử một y tá đánh sai tên của một bệnh nhân mà cô ta đang cố gắng để tìm hồ sơ 98
99. Thiết kế thông điệp tồi và tốt (Good and bad message design) 99
100. Quá trình thiết kế giao diện người dùng (UI design process) } Thiết kế giao diện người dùng là một quá trình lặp liên quan đến mối quan hệ chặt chẽ giữa người dùng và nhà thiết kế. } 3 hoạt động cốt lõi trong quá trình này là: } Phân tích người dùng. Hiểu được những gì người dùng sẽ làm với hệ thống; } Tạo nguyên mẫu hệ thống. Phát triển một loạt các nguyên mẫu để thử nghiệm; } Đánh giá giao diện. Thử nghiệm với những nguyên mẫu này với người dùng. 100
101. Quá trình thiết kế giao diện người dùng (Design process) 101
102. Phân tích người dùng (User analysis) } Các phân tích của người dùng phải được miêu tả theo cách mà cả người dùng và nhà thiết kế khác đều có thể hiểu. } Các kịch bản mà bạn miêu tả các giai đoạn sử dụng tiêu biểu là một cách để miêu tả các phân tích này. } Một vài kỹ thuật phân tích } Phân tích tác vụ: Mô hình các bước liên quan đến việc hoàn thành một tác vụ } Phỏng vấn và bảng câu hỏi: Hỏi người dùng về công việc họ làm. } Nhân chủng học: Quan sát người dùng tại nơi làm việc. 102
103. Tạo nguyên mẫu giao diện người dùng (User interface prototyping) } Mục đích của việc tạo nguyên mẫu là cho phép người dùng có được kinh nghiệm trực tiếp với giao diện. } Nếu không có kinh nghiệm trực tiếp như vậy, không thể đánh giá khả năng sử dụng của một giao diện. } Tạo nguyên mẫu có thể là một quá trình hai giai đoạn: } Ban đầu, nguyên mẫu trên giấy có thể được sử dụng; } Thiết kế sau đó được tinh chế và các nguyên mẫu tự động tinh vi hơn được phát triển. 103
104. Đánh giá giao diện người dùng (User interface evaluation) } Đánh giá quy mô đầy đủ là rất tốn kém và không thực tế đối với hầu hết các hệ thống. } Lý tưởng nhất là một giao diện nên được đánh giá dựa trên một đặc tả tính khả dụng. } Các thuộc tính khả dụng: } Tính dễ học } Tốc độ hoạt động } Độ bền (robustness) } Khả năng phục hồi (recoverability ) } Khả năng thích ứng (adaptability ) 104
105. Tóm tắt các điểm chính (Key points) } Các nguyên tắc thiết kế giao diện người dùng sẽ giúp hướng dẫn thiết kế các giao diện người dùng. } Các kiểu tương tác bao gồm: thao tác trực tiếp, các hệ thống menu, điền vào mẫu, ngôn ngữ lệnh và ngôn ngữ tự nhiên. } Hiển thị đồ họa nên được sử dụng để biểu thị các xu hướng và các giá trị gần đúng. } Màu sắc nên được sử dụng một cách tiết kiệm và nhất quán. } Quá trình thiết kế giao diện người dùng liên quan đến: việc phân tích người dùng, tạo nguyên mẫu hệ thống và đánh giá nguyên mẫu. } Mục đích của việc phân tích người dùng là để các nhà thiết kế hiểu cách người dùng thực sự làm việc. } Việc tạo mẫu giao diện người dùng phải là một quy trình được phân đoạn với các nguyên mẫu giấy ban đầu được sử dụng làm cơ sở cho nguyên mẫu tự động của giao diện. } Mục tiêu của việc đánh giá giao diện người dùng là lấy thông tin phản hồi về cách cải tiến thiết kế giao diện và đánh giá xem giao diện có đáp ứng các yêu cầu về tính hữu dụng của nó hay không. 105
106. Tài liệu Tham khảo } Giáo trình chính: Software Engineering, Ian Sommerville, 8th Edition, 2007 } Tham khảo: } Object-Oriented Software Engineering Practical Software Development using UML and Java, Lloseng.com, Lethbridge/Laganièr, 2001 } Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm, Phạm Thị Quỳnh 106