Скачать презентацию Chương 5 Thiết kế hệ thống 1 Скачать презентацию Chương 5 Thiết kế hệ thống 1

f2073a9270fcb7740f6fa66fa1084f83.ppt

  • Количество слайдов: 108

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

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

1. Một số khái niệm • • • Thiết kế là gì Thuộc tính 1. Một số khái niệm • • • 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ế 3

Thiết kế là gì? • Thiết kế tạo ra một biểu diễn hay mô Thiết kế là gì? • 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ả…) 4

Thiết kế là gì? • SRS cho biết hệ thống làm gì (what) và Thiết kế là gì? • 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). 5

Thuộc tính chất lượng • Chức năng (functionality): khả năng của phần mềm, kèm Thuộc tính chất lượng • 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-tofailure (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… 6

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

Thiết kế phần mềm • Thiết kế phần mềm là quá trình lặp thông Thiết kế phần mềm • 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. 8

Hướng dẫn thiết kế • Một thiết kế phải đưa ra một kiến trúc Hướng dẫn thiết kế • 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 9

 • Thiết kế phải đưa ra những giao diện (interface) mà giảm sự • 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 quả cao trong việc thông tin 10

Chuyển mô hình phân tích sang mô hình thiết kế • Mỗi phần tử Chuyển mô hình phân tích sang mô hình thiết kế • 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ế. Scenario-based Element Use case diagram Activity diagram Flow-oriented Element Data Flow Diagram Control-Flow diagram Analysis Model Class-based Element Class diagram CRC models Behavioral Element State diagram Sequence diagram 11

Nguyên lý thiết kế • • • Thiết kế phải tránh “tunnel vision” Thiết Nguyên lý thiết kế • • • 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) 12

Khái niệm thiết kế • • • Trừu tượng (Abstraction) - data, procedure, control Khái niệm thiết kế • • • 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 13

2. Các mô hình thiết kế • • Thiết kế giao diện (Interface Design) 2. Các mô hình thiết kế • • 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) 14

2. 2 Thiết kế giao diện • Để hệ thống làm việc tốt, ta 2. 2 Thiết kế giao diện • Để 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. 15

2. 2 Thiết kế giao diện • • • Ba quy tắc vàng Các 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 16

Xây nhà Phát triển hệ thống Bản vẽ kiến trúc Thiết kế kiến trúc Xây nhà Phát triển hệ thống Bản vẽ kiến trúc Thiết kế kiến trúc (Blueprint) (architecture design) Các mô tả Doors, windows, Thiết kế giao diện (user utility connections for interface design) water, for electricity, … 17

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

Quy tắc 1: Theo yêu cầu người dùng Place the user in control • 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. 19

Quy tắc 1: Theo yêu cầu người dùng Place the user in control • 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ẽ. . ) 20

Quy tắc 2: giảm thiểu việc ghi nhớ của người dùng Reduce the user’s Quy tắc 2: giảm thiểu việc ghi nhớ của người dùng Reduce 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. . ) 21

Quy tắc 3: Giao diện phải luôn nhất quán Make the interface consistent. • 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 22

Mục tiêu của thiết kế giao diện • Là để xác định tập hợp 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 23

Các mô hình phân tích và thiết kế giao diện Bốn mô hình có 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: 1. Kỹ sư phần mềm tạo mô hình thiết kế (design model) 2. Người phụ trách về nhân sự tạo ra mô hình người dùng (user model) 3. Người dùng cuối phát triển mô hình nhận biết hệ thống (system perception) 4. 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. 24

Phân loại người dùng • Novices (người mới) – không có kiến thức về 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. 25

Quy trình phân tích & thiết kế giao diện Quy trình phân tích và 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 26

Quy trình thiết kế giao diện người dùng • Quy trình thiết kế giao 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 27

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

Phân tích giao diện • Phân tích người dùng (user analysis) • Phân tích 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ị 29

Phân tích người dùng Để phân tích người dùng có thể dựa vào các 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) 30

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 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: 1. Are users trained professionals, technicians, clerical or workers? 2. What level of formal education does the average user have? 3. What is the age range of the user community? 4. Do users work normal office hours, or do they work until the job is done? 5. Are users expert typists or keyboard phobic? 6. Is the software to be an integral part of the work users do, or will it be used only occasionally? 7. Do users want to know about the technology that sists behind the interface? 31

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 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: 1. Where will the interface be located physically? 2. Will the user be sitting, standing, or performing other tasks unrelated to the interface? 3. Does the interface hardware accommodate space, light, or noise constraints? 4. Are there special human factors considerations driven by environmental factors? 32

Phân tích nhiệm vụ (Task analysis) Mục tiêu của phân tích nhiệm vụ để 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: 1. What work will the user perform in specific circumstances? 2. What tasks and subtasks will be performed as the user does the work? 3. What specific problem domain objects will the user manipulate as work is performed? 4. What is the sequence of work tasks – the workflow? 5. What is the hierarchy of tasks? 33

Phân tích nhiệm vụ (Task analysis) • Có thể theo 1 trong 2 cách 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) 34

Phân tích nhiệm vụ (Task analysis) • Nếu hệ thống có nhiều người dùng 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 35

Phân tích nội dung hiển thị (Analysis of display content) Khi phân tích giao 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: 1. Are different types of data assigned to consistent geographical locations on the screen? 2. Can user customize screen locations of content? 3. Is proper on-screen identification assigned to all content? 4. How should large report be partitioned for ease of understanding? 5. Will mechanisms be available for moving directly to data summary information for large data collections? 6. Will graphical output be scaled to fit bounds of display device used? 7. How will color be used to enhance understanding? 8. How will error messages and warnings be displayed to the user? 36

Thiết kế giao diện • • 1. 2. 3. 4. Ngay sau khi phân Thiết kế giao diện • • 1. 2. 3. 4. 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. 37

Phân tích các bước thiết kế • Từ đặc tả use case, lọc ra 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, 38

Ví dụ: khảo sát scenario Scenario: The homeowner wishes to gain access to the Ví dụ: khảo sát scenario Scenario: The homeowner wishes to gain access to the Safe. Home 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 Safe. Home 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 Safe. Home. 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. 39

Ví dụ: xác định đối tượng và hành động Nhiệm vụ của homeowner: • Ví dụ: xác định đối tượng và hành động Nhiệm vụ của homeowner: • accesses the Safe. Home system • enters an ID and password to allow remote access • checks system status • arms or disarms Safe. Home system • displays floor plan and sensor locations • displays zones on floor plan • changes zones on floor plan • displays video camera locations on floor plan • selects video 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? ? ? 40

Ví dụ: bố trí màn hình của Safehome • Có 3 loại đối tượng: 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 41

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

Mẫu thiết kế Design pattern Mẫu thiết kế là một giải pháp tổng thể 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ế. 43

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

Bốn vấn đề thiết kế giao diện 1. Response time 2. User help facilities Bốn vấn đề thiết kế giao diện 1. Response time 2. User help facilities 3. Error information handling 4. 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. 45

Vấn đề 1: Thời gian đáp ứng (Response time) • Được tính từ lúc 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. 46

Vấn đề 2: Tiện ích hỗ trợ người dùng User help facilities • Các 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ủ đề. 47

Thiết kế phần hỗ trợ Để thiết kế phần hỗ trợ, cần xem xét Thiết kế phần hỗ trợ Để thiết kế phần hỗ trợ, cần xem xét các vấn đề sau: 1. 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. 2. How will the user request help? Options include a help menu, a special function key, or a HELP command. 3. 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. 4. How will the user return to normal interaction? Options include a return button displayed on the screen, a function key, or control sequence. 5. 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. 48

Vấn đề 3: Quản lý lỗi Error handling • Thông báo (message) và cảnh Vấn đề 3: Quản lý lỗi Error 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: 1. Nên mô tả theo thuật ngữ mà người dùng có thể hiểu được. 2. 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. 3. 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 4. 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 (đỏ) 5. 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 49

Vấn đề 4: Thiết kế nhãn Menu and command labeling • Gõ lệnh vào Vấn đề 4: Thiết kế nhãn Menu 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: 1. Mỗi tùy chọn của thực đơn có tương đương với 1 lệnh không? 2. Khi thi hành lệnh thì sẽ được form gì? 3. Học và nhớ lệnh khó khăn như thế nào? Phải làm gì nếu quên lệnh 4. Người dùng có thể tùy biến hay viết tắt lệnh được không? 50

 • Tham khảo 12 quy tắc thiết kế • http: //www. smashingmagazine. com/2009/01/19/12 • Tham khảo 12 quy tắc thiết kế • http: //www. smashingmagazine. com/2009/01/19/12 -usefultechniques-for-good-user-interface-design-in-webapplications/ 51

User Interface Design Examples of change: 1990 to 2006 52 User Interface Design Examples of change: 1990 to 2006 52

2. 3 Thiết kế dữ liệu data design • Đôi khi còn gọi là 2. 3 Thiết kế dữ liệu data design • Đôi khi còn gọi là data architecting • Để tạo mô hình dữ liệu ở mức trừu tượng (view của người dùng). • Trong nhiều ứng dụng dữ liệu có ảnh hưởng đáng kể đến kiến trúc phần mềm đang phát triển. • Cấu trúc dữ liệu luôn là 1 phần quan trọng của thiết kế phần mềm 53

Thiết kế dữ liệu • Thiết kế dữ liệu ở mức thành phần chỉ Thiết kế dữ liệu • Thiết kế dữ liệu ở mức thành phần chỉ tập trung vào việc biểu diễn các cấu trúc dữ liệu được truy xuất trực tiếp bởi một hay nhiều thành phần mềm (SW components) • Một số nguyên tắc: – Các nguyên tắc dùng để phân tích chức năng cũng nên áp dụng cho dữ liệu – Tất cả cấu trúc dữ liệu và thao tác được thực thi trên mỗi cấu trúc cũng cần xác định (Nguyên tắc này rất thích hợp cho loại cấu trúc class) 54

2. 4 Thiết kế kiến trúc • Kiến trúc(Architecture) là gì? – Tương tự 2. 4 Thiết kế kiến trúc • Kiến trúc(Architecture) là gì? – Tương tự như nói đến kiến trúc tòa nhà. – Kiến trúc chỉ hình dạng tổng thể của cấu trúc vật lý. – Kiến trúc là cách thức mà các thành phần (component) khác nhau được tích hợp lại để tạo nên một tồng thể thống nhất. – Kiến trúc còn chỉ ra cách mà tòa nhà còn phải phù hợp với môi trường và hòa hợp với các tòa nhà khác trong vùng. • Kiến trúc phần mềm (software architecture) của 1 chương trình hay hệ thống máy tính là cấu trúc của hệ thống bao gồm thành phần mềm (software component), các thuộc tính nhìn thấy được của thành phần và mối quan hệ giữa chúng. 55

Thiết kế kiến trúc • Thành phần mềm (software component) có thể đơn giản Thiết kế kiến trúc • Thành phần mềm (software component) có thể đơn giản là một module chương trình hay một class hướng đối tượng hay cũng có thể là cả một database hay “middleware” • Thuộc tính của thành phần (properties of components) là các đặc tính cần thiết để nhận biết sự tương tác giữa các thành phần như thế nào. Ở mức thiết kế kiến trúc, các thuộc tính nội bộ như chi tiết 1 giải thuật chưa cần phải xác định. • Mối quan hệ giữa các thành phần nếu đơn giản có thể giống như phép gọi thủ tục từ 1 module này đến module khác, nếu phức tạp thì giống như protocol truy xuất CSDL. 56

Thiết kế kiến trúc • • Kiến trúc không phải là phần mềm vận Thiết kế kiến trúc • • Kiến trúc không phải là phần mềm vận hành (operational software). Kiến trúc cho phép kỹ sư phần mềm: 1. Phân tích tính hiệu quả của thiết kế xem có đáp ứng các yêu cầu hay không? 2. Khảo sát các chọn lựa kiến trúc khác nhau 3. Giảm các rủi ro liên quan đến việc xây dựng phần mềm 57

Tầm quan trọng của thiết kế kiến trúc • Bản thiết kế của kiến Tầm quan trọng của thiết kế kiến trúc • Bản thiết kế của kiến trúc phần mềm là cách cho phép giao tiếp giữa các stakeholder trong quá trình phát triển hệ thống • Kiến trúc sẽ giúp ra các quyết định thiết kế sớm có ảnh hưởng lớn đến sự thành công sau này của hệ thống • Chính kiến trúc tạo ra mô hình cho thấy hệ thống được cấu trúc như thế nào và các thành phần làm việc với nhau như thế nào (how) 58

Các mẫu kiến trúc (Architecture pattern and style) • Phần mềm có thể được Các mẫu kiến trúc (Architecture pattern and style) • Phần mềm có thể được xây dựng theo một trong các mẫu kiến trúc) • Mỗi mẫu kiến trúc mô tả một loại hệ thống bao gồm: – Tập hợp các thành phần (database, computational modules) thực thi chức năng được yêu cầu bởi hệ thống. – Tập các kết nối (connector) thành phần – Các ràng buộc (constraint) xác định thành phần được tích hợp như thế nào – Các mô hình ngữ nghĩa (semantic model) cho phép nhà thiết kế hiểu được các thuộc tính tổng thể của hệ thống bằng cách phân tích các thuộc tính đã biết của các thành phần 59

Phân biệt giữa pattern và style • Phạm vi của pattern hẹp hơn, tập Phân biệt giữa pattern và style • Phạm vi của pattern hẹp hơn, tập trung vào một ngữ cảnh nào đó hơn là kiến trúc tổng thể • Có thể dùng lẫn lộn cả hai thuật ngữ này 60

Một số mẫu kiến trúc chung • • • Data-centered architecture Data-flow architecture Main Một số mẫu kiến trúc chung • • • Data-centered architecture Data-flow architecture Main program/subprogram architecture Object-oriented architecture Layered architecture 61

Kiến trúc Data-centered • Kho dữ liệu (data store) nằm ở trung tâm kiến Kiến trúc Data-centered • Kho dữ liệu (data store) nằm ở trung tâm kiến trúc này và được truy xuất thường xuyên bởi các thành phần khác để cập nhật, thêm, xóa hay sửa đổi dữ liệu trong kho. 62

Kiến trúc Data Flow • Kiến trúc Data-flow được áp dụng khi dữ liệu Kiến trúc Data Flow • Kiến trúc Data-flow được áp dụng khi dữ liệu đầu vào bị biến đổi thông qua 1 chuỗi các tính toán hay tạo ra các thành phần thành dữ liệu của đầu ra. • Ví dụ mẫu pipe and filter có 1 tập các component, được nối với nhau bởi các pipe để truyền dữ liệu từ thành phần này đến thành phần khác. Mỗi filter làm việc độc lập nhau, được thiết kế để dành cho 1 lọai dữ liệu đầu vào nào đó và tạo dữ liệu ra ở 1 dạng nào đó cho filter kế tiếp. 63

Kiến trúc Data Flow 64 Kiến trúc Data Flow 64

Main program Controller subprogram Application subprogram Application subprogram Cấu trúc Main program/ subprogram 65 Main program Controller subprogram Application subprogram Application subprogram Cấu trúc Main program/ subprogram 65

Kiến trúc hướng đối tượng (Object-oriented architectures) • Các thành phần của hệ thống Kiến trúc hướng đối tượng (Object-oriented architectures) • Các thành phần của hệ thống chứa vừa dữ liệu vừa thao tác (operation) • Việc giao tiếp giữa các thành phần được thực hiện thông qua các thông điệp (message) gửi cho nhau 66

Kiến trúc call and return • Cho phép người thiết kế phần mềm tạo Kiến trúc call and return • Cho phép người thiết kế phần mềm tạo cấu trúc chương trình dễ chỉnh sửa và mở rộng. • Hai kiểu chính : – Main program/subprogram architectures. – Remote procedure call architectures. 67

Kiến trúc phân lớp (Layered architecture) • Bao gồm 1 số lớp, mỗi lớp Kiến trúc phân lớp (Layered architecture) • Bao gồm 1 số lớp, mỗi lớp thực hiện các hoạt động khác nhau. 68

Áp dụng các kiểu kiến trúc • Các kiểu kiến trúc này chỉ là Áp dụng các kiểu kiến trúc • Các kiểu kiến trúc này chỉ là 1 tập con trong số rất nhiều kiểu kiến trúc khác. • Sau khi thu thập yêu cầu phát hiện ra các đặc tính (characteristic) và ràng buộc (constraint) của hệ thống, nhà thiết kế có thể chọn một hay tập hợp các kiểu kiến trúc nào phù hợp nhất với các đặc tính của hệ thống đó. • Co thể có nhiều chọn lựa khác (alternative) cho cùng 1 hệ thống. 69

Trình tự thiết kế kiến trúc • Ngay khi bắt đầu thiết kế kiến Trình tự thiết kế kiến trúc • Ngay khi bắt đầu thiết kế kiến trúc, phần mềm cần xây dựng phải được đặt vào trong ngữ cảnh liên quan đến: – Thực thể bên ngoài – Bản chất của sự tương tác giữa phần mềm và thực thế • Sau khi đã mô hình hóa ngữ cảnh và giao diện bên ngoài, cần xác định và tinh chỉnh các thành phần mềm để thực thi kiến trúc. • Quy trình này sẽ lặp lại cho đến khi hoàn tất kiến trúc thiết kế 70

Lược đồ ? ? 71 Lược đồ ? ? 71

Biểu diễn hệ thống theo ngữ cảnh • Khi phân tích hệ thống thì Biểu diễn hệ thống theo ngữ cảnh • Khi phân tích hệ thống thì lược đồ ngữ cảnh (System Context Diagram – DFD mức 0) được dùng để biểu diễn dòng thông tin vào và ra của hệ thống • Khi thiết kế kiến trúc thì lược đồ ngữ cảnh kiến trúc ( Architectural Context Diagram ACD) được dùng để mô hình hóa cách thức phần mềm tương tác với các thực thể bên ngoài. 72

Cấu trúc chung của architectural Context Diagram Superordinate systems Used by Peers Target system Cấu trúc chung của architectural Context Diagram Superordinate systems Used by Peers Target system uses Actors Depends on Subordinate systems 73

Cấu trúc của ACD • Superordinate system: hệ thống sử dụng hệ thống đích Cấu trúc của ACD • Superordinate system: hệ thống sử dụng hệ thống đích để thực hiện các xử lý mức cao hơn • Subordinate system: hệ thống được dùng bởi hệ thống đích, cung cấp dữ liệu hay các xử lý cần thiết để giúp hệ thống đích hoàn thành chức năng • Peer-level system: hệ thống tương tác 1 -1 • Actor: thực thể (con người, thiết bị) tương tác với hệ thống đích. Mỗi thực thể bên ngoài tương tác với hệ thống đích thông qua giao diện (interface) 74

Ví dụ : ACD của Safe. Home Superordinate systems Safehome product Internet-based system Used Ví dụ : ACD của Safe. Home Superordinate systems Safehome product Internet-based system Used by Peers Control panel Target system: Security function Homeowner Surveillance system uses Actors Depends on Sensors Subordinate systems 75

Ánh xạ dòng dữ liệu thành kiến trúc • Thiết kế kiểu cấu trúc Ánh xạ dòng dữ liệu thành kiến trúc • Thiết kế kiểu cấu trúc (Structured design) thường được mô tả như một phương pháp thiết kế hướng dòng dữ liệu (data floworiented). • Nó cung cấp 1 cách chuyển đổi thuận tiện từ DFD thành kiến trúc phần mềm theo quy trình 7 bước. 76

Quy trình bảy bước chuyển từ DFD sang thiết kế phần mềm 1. Xem Quy trình bảy bước chuyển từ DFD sang thiết kế phần mềm 1. Xem lại mô hình hệ thống cơ bản 2. Xem và tinh chỉnh lại DFD ở các mức 2 và 3 3. Xác định xem DFD có đặc tính transform flow hay transaction flow không? 4. Cô lập điểm transform center 5. Thực hiện "first-level factoring” (phân chia mức đầu tiên) 6. Thực hiện “second-level factoring” (phân chia mức thứ cấp) 7. Tinh chỉnh lại kiến trúc dựa vào heuristics 77

Dòng thông tin • Loại dòng thông tin (information flow) sẽ quy định cách Dòng thông tin • Loại dòng thông tin (information flow) sẽ quy định cách ánh xạ trong bước 3. Có 2 loại dòng: – Transform flow – Transaction flow • Một DFD có thể được đặc trưng bằng cả hai loại dòng transform flow và transaction flow. 78

Transform Flow • Thông tin được đưa vào hoặc xuất ra bên ngoài phần Transform Flow • Thông tin được đưa vào hoặc xuất ra bên ngoài phần mềm trong dạng "external world". Ví dụ: dữ liệu đưa vào từ bàn phím, giọng nói qua điện thoại, hình ảnh … là thông tin bên ngoài. • Dữ liệu bên ngoài này cần phải đuợc biến đổi thành dạng “internal” để được xử lý. • Thông tin được đưa vào hệ thống dọc theo các đường dẫn (path) được gọi là dòng vào (incoming flow). • Bên trong phần mềm, dữ liệu vào sẽ được đưa vào trung tâm biến đổi (transform center) và bắt đầu chuyển dọc theo các đường dẫn để xuất ra ngoài được gọi là dòng ra (outgoing flow). • Trong lược đồ DFD, nếu dòng dữ liệu xảy ra 1 cách tuần tự (sequential) theo dạng đường thẳng (straight line) thì phần lược đồ đó có đặc tính transform flow 79

Transaction Flow • Mô hình hệ thống cơ bản thường thuộc dạng transform flow, Transaction Flow • Mô hình hệ thống cơ bản thường thuộc dạng transform flow, mọi dòng dữ liệu đều có thể được đặc trưng theo dạng này. • Dòng thông tin cũng có thể được đặc trưng bởi 1 mục dữ liệu (data item) nào đó mà mục dữ liệu này có thể kích khởi (trigger) các dòng dữ liệu khác dọc theo 1 hay nhiều đường dẫn. Mục dữ liệu này được gọi là transaction. • Transaction flow được đặc trưng bởi dữ liệu di chuyển dọc theo 1 incoming path để biến thông tin của thế giới bên ngoài thành 1 transaction đuợc đánh giá và dựa vào giá trị của nó mà dòng sẽ đi theo 1 trong nhiều action path. • Nơi mà các dòng thông tin tỏa ra được gọi là transaction center. 80

Transaction flow 81 Transaction flow 81

Transform mapping • Transform mapping là một tập hợp các bước thiết kế cho Transform mapping • Transform mapping là một tập hợp các bước thiết kế cho phép DFD có đặc tính transform flow được ánh xạ thành 1 kiểu kiến trúc xác định nào đó. 82

Ví dụ: DFD mức 0 83 Ví dụ: DFD mức 0 83

Ví dụ: 7 bước thiết kế • Bước 1: xem lại mô hình hệ Ví dụ: 7 bước thiết kế • Bước 1: xem lại mô hình hệ thống cơ bản và thông tin hỗ trợ. Cần xem lại SRS và đặc tả hệ thống (system specification), cả hai mô tả DFD mức 0 và 1. • Bước 2: xem và tinh chỉnh lại DFD ở các mức 2 và 3. Ví dụ khảo sát DFD mức 2 dành cho việc giám sát các cảm biến (sensor) và DFD mức 3 được suy dẫn từ mức 2. Ở mức 3, mỗi process tương ứng với 1 phép transform đều thực hiện 1 chức năng riêng biệt nào đó mà có thể triển khai như một module trong phần mềm. Vì vậy, DFD mức 3 này chứa chi tiết vừa đủ cho thiết kế kiến trúc của hệ thống con (cảm biến) và không cần tinh chỉnh thêm nữa. 84

DFD mức 1 85 DFD mức 1 85

Level 2 DFD that refines the monitor sensors process 86 Level 2 DFD that refines the monitor sensors process 86

DFD mức 3 87 DFD mức 3 87

Ví dụ: 7 bước thiết kế • Bước 3: xác định xem DFD có Ví dụ: 7 bước thiết kế • Bước 3: xác định xem DFD có đặc tính transform flow hay transaction flow không? • Nói chung thì dòng thông tin trong 1 hệ thống thường đều có thể biểu diễn như dạng transfom. Nhưng nếu DFD có đặc tính transaction rõ ràng thì nên theo cách ánh xạ của transaction flow. Các miền cục bộ (local region) của transform flow hay transaction flow đều bị cách ly nhau. Các dòng con này có thể được dùng để tinh chỉnh kiến trúc chương trình đã được suy dẫn từ đặc tính tổng thể chung trước đó. • Ở DFD mức 3, dữ liệu đưa vào phần mềm dọc theo 1 incoming path và đi ra dọc theo 3 outgoing path và không có transaction center rõ ràng. Vì vậy dòng thông tin của lược đồ này là transform. 88

Ví dụ: 7 bước thiết kế • Bước 4: cô lập transform center bằng Ví dụ: 7 bước thiết kế • Bước 4: cô lập transform center bằng cách xác định đường biên (boundary) của các dòng vào và ra. Đường biên của dòng vào và ra không cần phải quá khắt khe và tùy theo nhà thiết kế, có thể vị trí của biên là những điểm khác nhau trên các dòng. • Có thể có nhiều kết quả thiết kế khác nhau bằng cách thay đổi vị trí của các đường biên dòng. Việc thay đổi vị trí biên này nói chung không ảnh hưởng nhiều tới cấu trúc cuối cùng của chương trình. • Các transform tạo nên transform center sẽ nằm bên trong hai đường biên. 89

DFD mức 3 với các Đường biên dòng (flow boundary) 90 DFD mức 3 với các Đường biên dòng (flow boundary) 90

Ví dụ: 7 bước thiết kế Bước 5: thực hiện Ví dụ: 7 bước thiết kế Bước 5: thực hiện "first-level factoring” (phân chia mức đầu tiên) • Cấu trúc chương trình biểu diễn sự phân phối các control từ trên xuống dưới. • Việc phân chia (factoring) sẽ tạo ra trong cấu trúc chương trình module mức cao thực thi việc ra quyết định, và các module mức thấp thực thi hầu hết các ngõ vào, biến đổi và ngõ ra. Các module mức giữa thực thi 1 số control và làm một số công việc mức trung bình. • Khi phép biến đổi (transform) được đưa vào, DFD được ánh xạ thành 1 cấu trúc xác định nào đó (vd: call and return architecture) chứa control dành cho việc xử lý ngõ vào, biến đổi và xử lý thông tin ngõ ra. 91

Ví dụ: 7 bước thiết kế Bước 5 (tt): • Controller chính (monitor sensors Ví dụ: 7 bước thiết kế Bước 5 (tt): • Controller chính (monitor sensors executive) nằm ở đỉnh của cấu trúc chương trình và phối hợp với các control phía dưới – Sensor input controller: nhận tất cả dữ liệu ngõ vào – Alarm conditions controller: giám sát tất cả các thao tác liên quan đến dữ liệu – Alarm output controller: phối hợp để tạo ra thông tin ngõ ra. • Những hệ thống lớn thì có thể có nhiều hơn 2 control module cho mỗi chức năng điều khiển. • Số module ở phân chia mức đầu tiên này nên hạn chế it nhất sao cho vẫn hoàn thành đuợc chức năng điều khiển và vẫn giữ được đặc tính coupling và cohesion 92

Assignment • Coupling là gì? • Cohesion là gì? 93 Assignment • Coupling là gì? • Cohesion là gì? 93

Phân chia mức 1 94 Phân chia mức 1 94

Ví dụ: 7 bước thiết kế Bước 6: Thực thi Ví dụ: 7 bước thiết kế Bước 6: Thực thi "second-level factoring. " (phân chia mức hai) Việc phân chia mức hai được hoàn thành bằng cách ánh xạ các transform đơn lẻ của DFD thành các module thích hợp bên trong cấu trúc. Bắt đầu từ đường biên của transform center và chuyển dần ra ngoài dọc theo đường dẫn vào rồi sau đó theo đuờng dẫn ra. Các transform được biến đổi thành các control mức dưới. Thực tế hai hay nhiều hơn các transform kết hợp lại để biểu diễn 1 module hay một transform có thể được mở rộng thành 2 hay nhiều module hơn. 95

96 96

“First-iteration” program structure for monitor sensors 97 “First-iteration” program structure for monitor sensors 97

Ví dụ: 7 bước thiết kế Bước 7: tinh chỉnh lại kiến trúc ở Ví dụ: 7 bước thiết kế Bước 7: tinh chỉnh lại kiến trúc ở lần lặp đầu (first-iteration) bằng thiết kế heuristic • Kiến trúc nên được tinh chỉnh lại. Các thành phần có thể triển khai hay rút gọn lại sao cho việc phân rã hợp lý hơn, cohesion tốt hơn, giảm coupling. • Những chỉnh sửa ở bước này sẽ tốn thời gian và công sức nhưng có thể có ảnh hưởng lớn đến chất lượng phần mềm 98

Kết quả bước 7 99 Kết quả bước 7 99

Transaction mapping Ví dụ: Khảo sát hệ thống con user interaction của hệ thống Transaction mapping Ví dụ: Khảo sát hệ thống con user interaction của hệ thống Safe. Home Các bước 1, 2 và 3 tương tự như transform mapping Bước 1: xem lại mô hình hệ thống cơ bản Bước 2: xem và tinh chỉnh lại DFD ở các mức 2 và 3 Bước 3: xác định xem DFD có đặc tính transform hay transaction flow 100

DFD mức 1 101 DFD mức 1 101

DFD mức 2 của hệ thống con user interface 102 DFD mức 2 của hệ thống con user interface 102

Transaction mapping Bước 3: xác định xem DFD có đặc tính transform hay transaction Transaction mapping Bước 3: xác định xem DFD có đặc tính transform hay transaction flow Mục dữ liệu command type làm cho dòng dữ liệu tỏa ra DFD có đặc tính transaction flow. Tuy nhiên hai action path tỏa ra từ Invoke command processing thì dường như có đặc tính transform flow. Vì vậy cần xác định đường biên cho cả loại dòng này. 103

Transaction mapping Bước 4: xác định transaction center và đặc tính dòng dọc theo Transaction mapping Bước 4: xác định transaction center và đặc tính dòng dọc theo mỗi action path • Transaction center là nút Invoke command processing. Tất cả path vào và ra khỏi tâm này cần phải được cô lập lại. • Kế đến mỗi action path cần được đánh giá xem nó có đặc tính dòng nào? – Xét nhánh Password: nó có đặc tính transform nên nó có các đường biên riêng 104

Transaction mapping • Bước 5: ánh xạ DFD thành cấu trúc chương trình • Transaction mapping • Bước 5: ánh xạ DFD thành cấu trúc chương trình • Transaction flow được ánh xạ thành 1 cấu trúc chứa 1 nhánh vào (incoming branch) và 1 nhánh gửi đi (dispatch branch). – Cấu trúc của nhánh vào được phát triển tương tự như transform mapping. Xuất phát từ transaction center, các nút dọc theo đường dẫn vào (incoming path) được ánh xạ thành các module. – Cấu trúc của nhánh gửi đi chứa 1 dispatcher module (module điều vận) sẽ điều khiển tất cả các action module phía dưới nó. – Mỗi action path được ánh xạ thành 1 cấu trúc tương ứng với đặc tính dòng của nó. 105

Transaction mapping 106 Transaction mapping 106

Phân rã mức 1 cho hệ thống con 107 Phân rã mức 1 cho hệ thống con 107

 • Bước 6: phân chia và tinh chỉnh lại cấu trúc transaction và • Bước 6: phân chia và tinh chỉnh lại cấu trúc transaction và cấu trúc của mỗi action path • Bước 7: Tinh chỉnh lại kiến trúc lặp lần đầu (first-iteration) bằng thiết kế heuristic 108