Chương 5:

1. Chương 5: Thiết kế hệ thống

2. Một số khái niệm Các mô hình thiết kế Thiết kế mô hình hệ thống Thiết kế giao diện (Interface Design) Thiết kế dữ liệu (Data design) Thiết kế kiến trúc (Achitectural Design) Thiết kế thành phần (Component Design) Nội dung

3. Thiết kế là gì Thuộc tính chất lượng Thiết kế hệ thống Hướng dẫn thiết kế Nguyên lý thiết kế Khái niệm thiết kế 1. Một số khái niệm

4. Thiết kế tạo ra một biểu diễn hay mô hình của phần mềm, nhưng không giống như mô hình phân tích (tập trung vào việc mô tả dữ liệu, chức năng và hành vi) Mô hình thiết kế cung cấp chi tiết về kiến trúc (architecture), Giao diện (interfaces) và thành phần (component) cần thiết để cài đặt phần mềm Sản phẩm công tác (work product): biểu diễn kiến trúc (Cơ sơ dữ liệu, giao tiếp với hệ thống khác…), giao diện người dùng (GUI), thành phần (giao tiếp các thành phần, cấu trúc dữ liệu, giải thuật dưới dạng mã giả…) Thiết kế là gì?

5. SRS cho biết hệ thống làm gì (what) và trở thành đầu vào cho quá trình thiết kế Thiết kế dùng để chỉ ra hệ thống sẽ làm như thế nào (how), các yêu cầu sẽ được hiện thực hóa (realize) ra sao? Kết quả của quá trình thiết kế là Software Design Document (SDD). Thiết kế là gì?

6. Chức năng (functionality): khả năng của phần mềm, kèm theo tính an ninh Tiện dụng (usability): bao gồm cả tính mỹ thuật, toàn vẹn và tư liệu Tin cậy (reliability): tính chính xác, dùng The mean-time-to-failure (MTTF), Khả năng phục hồi từ lỗi Thực thi (performance): tốc độ xử lý, thời gian đáp ứng, sử dụng tài nguyên, hiệu quả… Khả năng hỗ trợ (suppotability): dễ mở rộng, khả năng ráp nối, khả năng test, khả năng cấu hình, khả năng tương thích… Thuộc tính chất lượng

7. Thiết kế hệ thống

8. Thiết kế phần mềm là quá trình lặp thông qua đó các yêu cầu hệ thống sẽ được chuyển đổi thành “blueprint” (bản thiết kế chi tiết) của phần mềm. Thiết kế bao gồm hai phần: Thiết kế ý niệm (conceptual design) nhằm nói cho khách hàng biết chính xác hệ thống sẽ làm gì Thiết kế kỹ thuật (technical design) cho phép các nhà xây dựng hệ thống biết cách vận dụng phần cứng và phần mềm như thế nào để giải quyết bài toán của khách hàng. Thiết kế phần mềm

9. Một thiết kế phải đưa ra một kiến trúc mà: (1) Dùng mẫu (pattern) hay kiểu (style) kiến trúc được thừa nhận (2) Gồm những thành phần có đặc trưng thiết kế tốt (3) Có thể thi hành theo cách tiến hóa Thiết kế phải module hóa Thiết kế phải trình bày riêng dữ liệu, kiến trúc, giao diện và thành phần (component) Thiết kế phải đưa ra cấu trúc dữ liệu phù hợp với lớp thực thi và từ những mẫu dữ liệu được thừa nhận Thiết kế phải đưa ra những thành phần mà độc lập chức năng Hướng dẫn thiết kế

10. Thiết kế phải đưa ra những giao diện (interface) mà giảm sự phức tạp của việc kết nối giữa các thành phần, cũng như môi trường ngoài Thiết kế được đưa ra từ việc dùng phương pháp lặp mà được định hướng bởi thông tin đạt được suốt quá trình phân tích yêu cầu phần mềm Thiết kế phải dùng những ký hiệu hiệu quả cao trong việc thông tin

11. Mỗi phần tử của mô hình phân tích (analysis model) cung cấp thông tin cần thiết để tạo 4 mô hình thiết kế. Analysis Model Scenario-based Element Use case diagram Activity diagram Flow-oriented Element Data Flow Diagram Control-Flow diagram Class-based Element Class diagram CRC models Behavioral Element State diagram Sequence diagram Chuyển mô hình phân tích sang mô hình thiết kế

12. Thiết kế phải tránh “tunnel vision” Thiết kế phải có thể lần vết ra mô hình phân tích Thiết kế phải không “reinvent the wheel” Thiết kế “minimize the intellectual distance” giữa phần mềm và những vấn đề trong thế giới thực Thiết kế phải thể hiện tính đồng nhất và tích hợp Thiết kế phải hỗ trợ sự thay đổi Thiết kế phải làm nhẹ đi những lệch lạc về dữ liệu sự kiện hay điều kiện hoạt động Thiết kế không là code, code không là thiết kế Thiết kế phải được đánh giá chất lượng khi nó đang được tạo không phải khi nó có vấn đề Thiết kế phải được kiểm tra (review) để làm giảm thiểu những lỗi ngữ nghĩa (semantic) Nguyên lý thiết kế

13. Trừu tượng (Abstraction) - data, procedure, control Kiến trúc (Architecture) - the overall structure of the software Mẫu (Patterns) - ”conveys the essence” of a proven design solution Module hóa (Modularity) - compartmentalization of data and function Che dấu thông tin (Information hiding) - controlled interface Độc lập chức năng (Functional independence) - single-minded function and low coupling Tinh chế (Refinement) - elaboration of detail for all abstractions Phân tách lại (Refactoring) - a reorganization technique that simplifies the design Khái niệm thiết kế

14. Thiết kế giao diện (Interface Design) Thiết kế kiến trúc (Achitectural Design) Thiết kế dữ liệu (Data design) Thiết kế thành phần (Component Design) 2. Các mô hình thiết kế

15. Để hệ thống làm việc tốt, ta phải điều khiển được các hệ thống con, làm cho các dịch vụ của chúng phải được thực hiện đúng chỗ và đúng thời điểm. Có 2 loại điều khiển (control styles): Điều khiển tập trung: một hệ thống con chịu trách nhiệm kiểm soát, khởi tạo hoặc dừng các hệ thống con khác. Điều khiển hướng sự kiện: mỗi hệ thống đáp ứng với các sự kiện xảy ra từ các hệ thống con khác hoặc từ môi trường của hệ thống. 2.2 Thiết kế giao diện

16. 2.2 Thiết kế giao diện Ba quy tắc vàng Các mô hình phân tích & thiết kế giao diện Quy trình phân tích & thiết kế giao diện Phân tích giao diện Thiết kế giao diện

18. Ba quy tắc vàng 1. Place the user in control. 2. Reduce the user’s memory load. 3. Make the interface consistent.

19. Quy tắc 1: Theo yêu cầu người dùng Place the user in control Người dùng luôn mong muốn hệ thống tương tác và giúp họ thực hiện mọi việc dễ dàng. Người dùng muốn “to control the computer, not have the computer control”, “System reads their mind, it knows what the users want to do before the user need to do” Nhưng Người thiết kế muốn đưa vào giao diện các ràng buộc và giới hạn để làm đơn giản hóa việc thực thi giao diện.

20. Quy tắc 1: Theo yêu cầu người dùng Place the user in control Nên xác định kiểu tương tác sao cho không ép người dùng thực hiện các thao tác không cần thiết hay không mong muốn Cho phép tương tác linh hoạt ( bàn phím, chuột, bút,..) Cho phép người dùng được ngắt khi thực 1 chuỗi thao tác hay được phép “undo” thao tác nào Cho phép người dùng thông thạo được phép tùy biến các tương tác (dùng macro) Không nên để người dùng phải nhìn thấy các yếu tố kỹ thuật của hệ thống (hệ điều hành, chức năng quản lý file,…) Cho phép người dùng tương tác trực tiếp với các đối tượng trên màn hình (kéo dãn 1 đối tượng vẽ..)

21. Quy tắc 2: giảm thiểu việc ghi nhớ của người dùngReduce the user’s memory load Càng bắt người dùng phải nhớ càng nhiều, thì việc tương tác với hệ thống càng dễ bị lỗi Để giảm việc phải nhớ các hành động cần làm, nên đưa ra các gợi ý hình ảnh (visual cues) Nên tạo các mặc định thích hợp Nên tạo các phím gõ tắt (shortcut) trực giác, dễ nhớ Nên sắp xếp giao diện gần giống với thế giới thực Nên tổ chức thông tin theo dạng phân cấp (hierarchical), thông tin ở mức trừu tượng trước, rồi tới mức chi tiết ( chọn chức năng gạch dưới xong, thì các kiểu gạch dưới cụ thể sẽ được liệt kê tiếp theo..)

22. Quy tắc 3: Giao diện phải luôn nhất quán Make the interface consistent. Nhất quán trong việc thiết kế các màn hình giao diện theo cùng một tiêu chuẩn Cùng cơ chế nhập liệu Cùng cơ chế chuyển đổi từ nhiệm vụ này sang nhiệm vụ khác

23. Mục tiêu của thiết kế giao diện Là để xác định tập hợp các đối tượng giao diện và các hành động cho phép người dùng thực hiện được tất cả những nhiệm vụ của hệ thống

24. Các mô hình phân tích và thiết kế giao diện Bốn mô hình có liên quan đến thiết kế giao diện: Kỹ sư phần mềm tạo mô hình thiết kế (design model) Người phụ trách về nhân sự tạo ra mô hình người dùng (user model) Người dùng cuối phát triển mô hình nhận biết hệ thống (system perception) Người thực thi tạo mô hình thực thi (implementation model) Các mô hình này có thể rất khác nhau. Vai trò của người thiết kế giao diện là phải làm sao cho các mô hình này tương thích và tạo ra giao diện ôn định.

25. Phân loại người dùng Novices (người mới) – không có kiến thức về hệ thống, hiểu biết rất ít về ứng dụng cũng như cách sử dụng máy tính Knowledgeable intermittent users (người dùng gián đoạn tuy có kiến thức) Knowledgeable frequent users (người dùng thường xuyên có hiểu biết) Phân tích giao diện thường xét đến hồ sơ (profile) của người dùng hệ thống và phân tích cả môi trường làm việc của người dùng.

26. Quy trình phân tích & thiết kế giao diện Quy trình phân tích và thiết kế giao diện thường lặp lại và có thể được biểu diễn bằng mô hình xoắn ốc Hoạt động implementation thường là prototyping

27. Quy trình thiết kế giao diện người dùng Quy trình thiết kế giao diện thường hay lặp lại và theo mô hình xoắn ốc. Bốn hoạt động chính: 1. User, task, and environment analysis and modeling 2. Interface design 3. Interface construction 4. Interface validation

28. Phân tích giao diện Mục tiêu của phân tích giao diện: Để hiểu người sẽ sử dụng hệ thống thông qua giao diện Để hiểu nhiệm vụ người dùng cuối phải thực hiện Để hiểu nội dung trong mỗi giao diện Để hiểu bản chất môi trường mà nhiệm vụ sẽ thực hiện

29. Phân tích giao diện Phân tích người dùng (user analysis) Phân tích và mô hình hóa nhiệm vụ (task analysis and modeling) Phân tích môi trường làm việc Phân tích nội dung hiển thị

30. Phân tích người dùng Để phân tích người dùng có thể dựa vào các nguồn sau: Phỏng vấn người dùng (User interviews) Từ việc bán hàng (Sales input) – nhân viên bán hàng sẽ giúp nhà thiết kế phân loại người dùng và nắm được nhu cầu của họ Từ tiếp thị (Marketing input) Từ hỗ trợ (Support input)

31. Phân tích người dùng Những câu hỏi giúp nhà thiết kế giao diện hiểu rõ hơn người dùng: Are users trained professionals, technicians, clerical or workers? What level of formal education does the average user have? What is the age range of the user community? Do users work normal office hours, or do they work until the job is done? Are users expert typists or keyboard phobic? Is the software to be an integral part of the work users do, or will it be used only occasionally? Do users want to know about the technology that sists behind the interface?

32. Phân tích môi trường làm việc của người dùng Thông qua 1 số câu hỏi sau: Where will the interface be located physically? Will the user be sitting, standing, or performing other tasks unrelated to the interface? Does the interface hardware accommodate space, light, or noise constraints? Are there special human factors considerations driven by environmental factors?

33. Phân tích nhiệm vụ(Task analysis) Mục tiêu của phân tích nhiệm vụ để trả lời các câu hỏi sau: What work will the user perform in specific circumstances? What tasks and subtasks will be performed as the user does the work? What specific problem domain objects will the user manipulate as work is performed? What is the sequence of work tasks – the workflow? What is the hierarchy of tasks?

34. Phân tích nhiệm vụ(Task analysis) Có thể theo 1 trong 2 cách để phân tích nhiệm vu: Cần phải hiểu được nhiệm vụ mà người dùng cần phải làm (trước khi có phần mềm), rồi ánh xạ chúng thành tập các nhiệm vụ cần thực thi trong giao diện của người dùng. Có thể nghiên cứu đặc tả có sẵn của phần mềm và từ tập nhiệm vụ của người dùng để suy diễn ra mô hình người dùng Mỗi nhiệm vụ chính (major task) có thể được chia thành nhiều nhiệm vụ con (subtask)

35. Phân tích nhiệm vụ(Task analysis) Nếu hệ thống có nhiều người dùng khác nhau, mỗi người dùng có vai trò khác nhau, nên sử dụng các giao diện khác nhau , thì kỹ sư thiết kế cần áp dụng kỹ thuật workflow analysis Workflow analysis: kỹ thuật cho phép kỹ sư phần mềm hiểu một quy trình công việc được hoàn thành như thế nào Thể hiện workflow analysis là lược đồ activity của UML Ví dụ: quy trình kê đơn và phát thuốc. Có 3 loại người dùng: bệnh nhân, bác sĩ và người bán thuốc

36. Phân tích nội dung hiển thị(Analysis of display content) Khi phân tích giao diện,các yếu tố thẩm mỹ và định dạng cũng cần được khảo sát thông qua 1 số câu hỏi: Are different types of data assigned to consistent geographical locations on the screen? Can user customize screen locations of content? Is proper on-screen identification assigned to all content? How should large report be partitioned for ease of understanding? Will mechanisms be available for moving directly to data summary information for large data collections? Will graphical output be scaled to fit bounds of display device used? How will color be used to enhance understanding? How will error messages and warnings be displayed to the user?

37. Thiết kế giao diện Ngay sau khi phân tích xong giao diện, thiết kế giao diện sẽ bắt đầu Là quá trình lặp, được chia thành 4 bước: Xác định các đối tượng và thao tác của giao diện Xác định các sự kiện làm cho trạng thái của các giao diện thay đổi. Tạo mô hình cho các hành vi này Mô tả mỗi trạng thái giao diện Chỉ ra làm thế nào người dùng hiểu các trạng thái này từ thông tin được cung cấp trên giao diện .

38. Phân tích các bước thiết kế Từ đặc tả use case, lọc ra các noun (object) và verb (action) để tạo ra danh sách các object và action Phân loại đối tượng (type): source, target và application. Source là loại đối tượng có thể drag and drop vào target. Application là đối tượng chứa dữ liệu của ứng dụng nhưng không được tạo ra 1 cách trực tiếp bằng các thao tác trên màn hình Screen layout: là 1 quá trình lặp để sắp xếp vị trí các biểu tượng, xác định các phần mô tả (text), xác định và đặt tên cho cửa sổ, định nghĩa menu,

39. Ví dụ: khảo sát scenario Scenario: The homeowner wishes to gain access to the SafeHome system installed in his house. Using software operating on a remote PC, the homeowner determines the status of the alarm system, arms or disarms the system, reconfigures security zones, and views different rooms within the house via preinstalled video cameras. To access SafeHome from a remote location, the homeowner provides an identifier and a password. These define levels of access and provide security. Once validated, the user checks the status of the system and changes status by arming or disarming SafeHome. The user reconfigures the system by displaying a floor plan of the house, viewing each of the security sensors, displaying each currently configured zone, and modifying zones as required. The user views the interior of the house via strategically placed video cameras. The user can pan and zoom each camera to provide different views of the interior.

40. Ví dụ: xác định đối tượng và hành động Nhiệm vụ của homeowner: • accesses the SafeHome system • enters an ID and password to allow remote access • checks system status • arms or disarms SafeHome system • displaysfloor plan and sensor locations • displayszones on floor plan • changes zones on floor plan • displaysvideo camera locations on floor plan • selectsvideo camera for viewing • views video images (4 frames per second) • pans or zooms the video camera Các đối tượng ?? Các hành động???

41. Ví dụ: bố trí màn hình của Safehome Có 3 loại đối tượng: Source: video camera location Target: video camera. Khi source được kéo vào target thì sẽ tạo ra hình ảnh mà camera đó thu được Application: cửa sổ video image

42. Ví dụ: bố trí sơ bộ màn hình

43. Mẫu thiết kế Design pattern Mẫu thiết kế là một giải pháp tổng thể cho các vấn đề chung trong thiết kế phần mềm. Một mẫu thiết kế không phải là một thiết kế hoàn thiện để mà có thể được chuyển đổi trực tiếp thành mã; nó chỉ là một mô tả hay là sườn (template) mô tả cách giải quyết một vấn đề mà có thể được dùng trong nhiều tình huống khác nhau. Các mẫu thiết kế hướng đối tượng thường cho thấy mối quan hệ và sự tương tác giữa các lớp hay các đối tượng, mà không cần chỉ rõ các lớp hay đối tượng của từng ứng dụng cụ thể. Các giải thuật không được xem là các mẫu thiết kế, vì chúng giải quyết các vấn đề về tính toán hơn là các vấn đề về thiết kế.

44. Ví dụ các mẫu thiết kế giao diện Top-level navigation … Card stack Fill-in-the-blanks Sortable table Bread crumbs Edit-in-place Simple search Shopping cart Progress indicator

45. Bốn vấn đề thiết kế giao diện Response time User help facilities Error information handling Command label Nếu không được chú trọng ngay khi bắt đầu thiết kế sẽ gây ra hậu quả sau: Unnecessary iteration Project delays Customer frustration.

46. Vấn đề 1: Thời gian đáp ứng (Response time) Được tính từ lúc người dùng thực hiện 1 hành động kiểm soát (control) nào đó cho đến lúc phần mềm đáp ứng được bằng kết quả hay hành động Hai đặc tính: length and variability. Length: nếu thời gian đáp ứng quá lâu, sẽ gây bực bội và căng thẳng cho người dùng. Thời gian đáp ứng quá nhanh cũng gây bất lợi, người dùng sẽ vội vàng và dễ gây nhầm lẫn Variability: độ dao động của thời gian đáp ứng. Độ dao động thấp cho phép người dùng xác lập được sự thao tác nhịp nhàng, ngay cả khi thời gian đáp ứng tương đối lâu. Ví dụ: thời gian đáp ứng 1 giây cho mỗi lệnh vẫn được ưa thích hơn là thời gian đáp ứng thay đổi từ 0.1 đến 2.5 giây. Người dùng luôn cảm thấy mất thăng bằng nếu lúc nhanh lúc chậm, họ luôn tự hỏi liệu có cái gì khác đang xảy ra mỗi lần đáp ứng chậm.

47. Vấn đề 2: Tiện ích hỗ trợ người dùng User help facilities Các phần mềm hiện đại đều cung cấp hỗ trỡ trực tuyến (on-line help) cho phép người dùng hỏi và được trả lời hay giải quyết các rắc rối mà không cần phải đóng giao diện lại. Hai loại hỗ trợ : tích hợp (integrated ) và bổ sung tùy chọn (add-on) Integrated help: đựợc thiết kế ngay trong phần mềm, thường ở dạng cảm ngữ cảnh (context sensitive) cho phép người dùng chọn theo danh mục phù hợp với từng hành động đang được thực thi, tăng tính thân thiện với người dùng. Add-on help: được bổ sung thêm vào phần mềm sau khi hệ thống đã được xây dựng. Nó thực sự là 1 số tay người dùng trực tuyến nhưng hạn chế khả năng truy vấn, người dùng phải dò tìm thông qua 1 danh mục hàng trăm chủ đề.

48. Thiết kế phần hỗ trợ Để thiết kế phần hỗ trợ, cần xem xét các vấn đề sau: Will help be available for all system functions and at all times during system interaction? Options include help for only a subset of all functions and actions or help for all functions. How will the user request help? Options include a help menu, a special function key, or a HELP command. How will help be represented? Options include a separate window, a reference to a printed document (less than ideal), or a one- or two-line suggestion produced in a fixed screen location. How will the user return to normal interaction? Options include a return button displayed on the screen, a function key, or control sequence. How will help information be structured? Options include a "flat" structure in which all information is accessed through a keyword, a layered hierarchy of information that provides increasing detail as the user proceeds into the structure, or the use of hypertext.

49. Vấn đề 3: Quản lý lỗiError handling Thông báo (message) và cảnh báo (warnings) sai lệch hoặc không có tác dụng gì sẽ làm tăng sự thất vọng cho người dùng. Thông báo lỗi nên theo các tính chất sau: Nên mô tả theo thuật ngữ mà người dùng có thể hiểu được. Nên cung cấp lời khuyên có tính xây dựng giúp người dùng khôi phục được khi lỗi xảy ra. Nên chỉ ra các hậu quả (ví dụ file dữ liệu có thể bị lỗi) nhờ đó người dùng có thể kiểm tra lại Nên đồng hành với các gợi ý âm thanh hay hình ảnh như tiếng beep, thông báo nhấp nháy hoặc có màu đặc biệt (đỏ) Chỉ đơn thuần là thông báo, không mang tính phán quyết, đổ lỗi cho người dùng

50. Vấn đề 4: Thiết kế nhãnMenu and command labeling Gõ lệnh vào là cách tương tác thông dụng nhất giữa người và máy và thường được dùng trong mọi ứng dụng Hiện nay giao diện thông dụng là window-oriented, drag and drop, menu và các nút lệnh Dù phải gõ lệnh hay dùng nút lệnh, cần lưu ý các vấn đề sau: Mỗi tùy chọn của thực đơn có tương đương với 1 lệnh không? Khi thi hành lệnh thì sẽ được form gì? Học và nhớ lệnh khó khăn như thế nào? Phải làm gì nếu quên lệnh Người dùng có thể tùy biến hay viết tắt lệnh được không?