Nhập môn Công nghệ phần mềm - Chương 7: Thiết kế phần mềm

Nội dung text: Nhập môn Công nghệ phần mềm - Chương 7: Thiết kế phần mềm

1. Thiết kế phần mềm NHẬP MÔN • Nội dung CÔNG NGHỆ PHẦN MỀM 1. Tổng quan thiết kế phần mềm (INTRODUCTION TO SOFTWARE 2. Thiết kế kiến trúc phần mềm ENGINEERING) 3. Thiết kế chi tiết phần mềm 4. Thiết kế giao diện người dùng 5. Thiết kế mẫu 6. Thiết kế giao diện cho ứng dụng WebApp 1 2 1 2 Analysis Model -> Design Model (Mô hình phân tích-> Mô hình thiết kế) Design • Theo Mitch Kapor, người đã tạo ra Lotus 1-2-3, giới thiệu trong “Tuyên ngôn về thiết kế phần mềm” trên Dr. Dobbs Journal. : – Thiết kế phần mềm tốt nên thể hiện Com ponent - sc e n a r i o- ba se d f l ow- or i e n te d Lev el Design – Sự ổn định (Firmness): Một chương trình không nên có bất cứ lỗi nào e l e me n ts e l e me n ts use-cases - text data flow diagrams use-case diagrams control-flow diagrams làm hạn chế chức năng của nó. activity diagrams processing narratives swim lane diagrams Int erfa c e Design – Tiện nghi(Commodity): Một chương trình nên phù hợp với mục đích Analysis Model đã định của nó . Arc hit ec t ura l Design c l a ss- ba se d be h a v i or a l e l e me n ts e l e me n ts – Sự hài lòng(Delight): Trải nghiệm sử dụng chương trình nên làm hài class diagrams state diagrams analysis packages sequence diagrams CRC models Da t a / Cla ss Design lòng người dùng. collaboration diagrams Design Model These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3 4 3 4
2. Thiết kế và chất lượng Nguyên tắc Chất lượng • Một thiết kế nên thể hiện một kiến trúc mà (1) đã được tạo ra bằng cách sử dụng phong • thiết kế phải thực hiện tất cả các yêu cầu rõ ràng chứa trong mô cách kiến trúc hoặc các pattern được công nhận , (2) bao gồm các thành phần mang những đặc tính thiết kế tốt và (3) có thể được thực hiện một cách tiến hóa hình phân tích, và nó phải đáp ứng tất cả các yêu cầu tiềm ẩn khách – Đối với các hệ thống nhỏ hơn, thiết kế đôi khi có thể được phát triển tuyến tính. hàng mong muốn . • Một thiết kế nên môđun hoá; đó là, phần mềm nên được phân chia thành các thành phần hợp lý hoặc hệ thống con • thiết kế phải là một hướng dẫn dễ hiểu dễ đọc cho những người tạo • Một thiết kế cần có biểu diễn riêng biệt của dữ liệu, kiến trúc, giao diện, và các thành ra code và cho những người kiểm thử và sau đó hỗ trợ cho phần phần. mềm. • Một thiết kế nên dẫn đến các cấu trúc dữ liệu thích hợp cho các lớp sẽ được thực thi và được rút ra từ mô hình dữ liệu có thể nhận biết. • thiết kế nên cung cấp một bức tranh hoàn chỉnh của phần mềm, giải • Một thiết kế nên dẫn đến các thành phần mang những đặc tính chức năng độc lập. quyết vấn đề dữ liệu, chức năng, và hành vi từ một quan điểm thực • Một thiết kế nên dẫn đến giao diện mà giảm sự phức tạp của các kết nối giữa các thành phần và với môi trường bên ngoài thi. • Một thiết kế nên được chuyển hóa bằng cách sử dụng một phương pháp lặp lại được dẫn dắt bởi các thông tin thu được trong quá trình phân tích các yêu cầu phần mềm. These slides are designed to accompany Software Engineering: • Một thiết kế nên được đại diện bằng một ký hiệu truyền đạt hiệu quả ý nghĩa của nó. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 These slides are designed to accompany Software Engineering: 6 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 6 Nguyên tắc thiết kế Các khái niệm cơ bản • Quá trình thiết kế không nên mắc phải‘tunnel vision.’ • Trừu tượng hoá—dữ liệu, thủ tục, kiểm soát • Việc thiết kế nên có thể truy ngược về mô hình phân tích. • Kiến trúc—cấu trúc tổng thể của phần mềm • Việc thiết kế không nên ‘phát minh lại bánh xe’. • Patterns—"chuyển tải những tinh túy" của một giải pháp thiết kế đã được chứng minh • Việc thiết kế nên "giảm thiểu khoảng cách trí tuệ" [DAV95] giữa phần mềm và bài • Separation of concerns—bất kỳ vấn đề phức tạp có thể được xử lý dễ dàng hơn nếu nó toán như nó tồn tại trong thế giới thực. được chia thành nhiều mảnh • Việc thiết kế nên biểu lộ tính đồng nhất và tích hợp. • Modularity—mô đun hoá các dữ liệu và chức năng • Tính ẩn—giao diện được điều khiển • Việc thiết kế nên được cấu trúc để thích ứng với thay đổi. • Độc lập Chức năng —Các hàm đơn mục đích và khớp nối thấp. • Việc thiết kế nên được cấu trúc để làm suy thoái (degrade) nhẹ nhàng, ngay cả khi • Sàng lọc—xây dựng chi tiết cho tất cả các khái niệm trừu tượng đang gặp phải dữ liệu bất thường, các sự kiện, hoặc điều kiện hoạt động . • Các khía cạnh—một cơ chế cho sự hiểu biết các yêu cầu tổng thể ảnh hưởng đến thiết • Thiết kế không phải là coding, coding không phải là thiết kế. kế như thế nào • Việc thiết kế nên được đánh giá về chất lượng khi nó được tạo ra, chứ không phải • Refactoring— một kỹ thuật tái tổ chức nhằm đơn giản hóa thiết kế sau thực tế. • OO design concepts—Phụ lục II • Việc thiết kế cần được xem xét để giảm thiểu lỗi khái niệm (ngữ nghĩa). • Thiết kế Lớp—cung cấp chi tiết thiết kế mà sẽ cho phép các lớp đã phân tích được thực From Davis [DAV95] thi These slides are designed to accompany Software Engineering: 7 These slides are designed to accompany Software Engineering: 8 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7 8
3. Trừu tượng dữ liệu Trừu tượng thủ tục Cửa Mở nhà sản xuất model số chi tiết về Loại Thuật toán vào cửa Hướng xoay chèn đèn loại số lượng Khối lượng Cách mở thực hiện với "kiến thức” về các Thực thi như một cấu trúc dữ liệu đối tượng được kết hợp với vào cửa These slides are designed to accompany Software Engineering: 9 These slides are designed to accompany Software Engineering: 10 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 10 Kiến trúc Patterns(mẫu) • “Cấu trúc tổng thể của phần mềm và cách thức mà cấu trúc cung cấp tính toàn Bản mẫu thiết kế paern vẹn khái niệm cho một hệ thống.” [SHA95a] Tên Paern—mô tả bản chất của mô hình trong một tên ngắn nhưng ý nghĩa – Tính cấu trúc. Khía cạnh này của các đại diện thiết kế kiến trúc xác định Intent (ý định)—mô tả các mô hình và những gì nó làm Also-known-as—liệt kê các từ đồng nghĩa cho các paern các thành phần của một hệ thống (ví dụ, mô-đun, các đối tượng, các bộ Movaon(Động lực )—cung cấp một ví dụ về vấn đề lọc) và cách thức mà những thành phần này được đóng gói và tương tác Applicability (Khả năng áp dụng)—lưu ý nh huống thiết kế cụ thể, trong đó mô hình được áp dụng với nhau. Ví dụ, đối tượng được đóng gói cả dữ liệu và việc xử lý các Structure( cấu trúc)—mô tả các lớp được yêu cầu để thực hiện mô hình thao tác dữ liệu và tương tác thông qua việc gọi các phương pháp Parcipants (thành phần tham gia)—mô tả trách nhiệm của các lớp được yêu cầu để thực hiện paern – Tính thêm chức năng. Các mô tả thiết kế kiến trúc nên giải quyết cách Collaboraons (sư công tác)—mô tả cách những thành phần tham gia cộng tác để thực hiện trách nhiệm của mình kiến trúc thiết kế đạt yêu cầu về hiệu suất, công suất, độ tin cậy, an toàn, Consequences(hệ quả)—mô tả các "lực lượng thiết kế" có ảnh hưởng đến các mô khả năng thích ứng, và các đặc điểm khác của hệ thống. hình và các đánh đổi ềm năng phải được xem xét khi mô hình được thực hiện Related paerns(paerns liên quan)—tham khảo chéo liên quan đến các mẫu thiết – Họ các hệ thống liên quan. Thiết kế kiến trúc sẽ dựa trên mô hình lặp lại kế mà thường gặp trong thiết kế của các họ của các hệ thống tương tự. Về bản chất, các thiết kế cần phải có khả năng sử dụng lại các khối xây dựng kiến trúc. These slides are designed to accompany Software Engineering: 11 These slides are designed to accompany Software Engineering: 12 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 11 12
4. Phân tách các Mối quan tâm Mô đun • Bất kỳ vấn đề phức tạp có thể được xử lý dễ dàng hơn nếu nó • “Mô đun là thuộc tính duy nhất của phần mềm cho phép một chương được chia thành từng mảnh mà mỗi mảnh có thể được giải quyết trình có thể quản lý một cách thông minh" [Mye78]. và / hoặc tối ưu hóa một cách độc lập • Phần mềm nguyên khối (ví dụ, một chương trình lớn gồm một mô-đun • Mối quan tâm là một tính năng hoặc hành vi được quy định như duy nhất) có thể không được dễ dàng nắm bắt được bởi một kỹ sư phần mềm. là một phần của mô hình yêu cầu cho các phần mềm – Số lượng các đường dẫn điều khiển, khoảng thời gian tham khảo, • Bằng cách tách mối quan tâm ra nhỏ hơn, và các mảnh dễ quản số lượng các biến, và độ phức tạp tổng thể sẽ làm cho việc hiểu lý hơn, một vấn đề mất ít hơn công sức và thời gian để giải được gần như không thể. quyết. • Trong hầu hết các trường hợp, bạn nên phá vỡ thiết kế thành nhiều module, hy vọng sẽ làm cho việc hiểu biết dễ dàng hơn và như một hệ quả, giảm chi phí cần thiết để xây dựng các phần mềm. These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13 14 13 14 Modularity: sự đánh đổi Ẩn thông tin Số "chính xác" các mô đun module cho một thiết kế phần mềm cụ thể? • thuật toán Giao diện chi phí phát triển module Điều khiển • cấu trúc dữ liệu chi phí . Chi tiết về giao diện bên ngoài Phần mềm • chính sách phân bổ nguồn lực Chi phí tích hợp Mô đun clients ”bí mật" Số môđun tối ưu Số modules một quyết định thiết kế cụ thể These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 15 16 15 16
5. Tại sao lại Ẩn thông tin? Sàng lọc theo từng bước • làm giảm khả năng "tác dụng phụ” Mở • hạn chế ảnh hưởng chung của quyết định thiết kế cục bộ • nhấn mạnh truyền thông qua giao diện điều khiển đi bộ đến cửa; • không khuyến khích việc sử dụng các dữ liệu toàn cục tiếp cận với núm; • dẫn đến đóng gói, một thuộc tính của thiết kế chất lượng cao Mở cửa; repeat until door opens turn knob clockwise; • kết quả trong phần mềm chất lượng cao Đi qua; if knob doesn't turn, then Đóng cửa. take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 17 18 17 18 Định kích thước mô đun: Hai cách nhìn Tính độc lập chức năng • Tính độc lập chức đạt được bằng cách phát triển các module với chức What's How big năng đơn lẻ và một "ác cảm" với tương tác quá mức với các module khác. inside?? is it?? • Sự gắn kết là một dấu hiệu của sức mạnh chức năng tương đối của một module. • Một module gắn kết thực hiện một nhiệm vụ duy nhất, đòi hỏi ít tương tác với các thành phần khác trong các phần khác của chương trình. Nói đơn giản, một mô-đun gắn kết nên (lý tưởng) làm chỉ là một việc. • Ghép nối là một dấu hiệu của sự phụ thuộc lẫn nhau tương đối giữa các MODULE mô-đun. • Ghép nối phụ thuộc vào độ phức tạp giao diện giữa các module, các điểm mà tại đó entry hoặc tham chiếu được thực hiện cho một mô-đun, và những dữ liệu truyền qua giao diện. These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 19 20 19 20
6. Các khía cạnh Các khía cạnh — Ví dụ • Hãy xem xét hai yêu cầu, A và B. Yêu cầu A giao nhau với yêu cầu B "nếu • Hãy xem xét hai yêu cầu với SafeHomeAssured.com WebApp. Yêu cầu A được một phân tách phần mềm [tinh chế] được lựa chọn trong đó B không thể mô tả qua các trường hợp sử dụng camera giám sát truy cập thông qua Internet. làm hài lòng mà không cần dùng A.[Ros04] Một tinh chỉnh thiết kế sẽ tập trung vào những mô-đun có thể cho phép một người sử dụng đăng ký để truy cập video từ camera đặt khắp không gian. Yêu cầu B là • Một khía cạnh là một đại diện của một mối quan tâm giao nhau. một yêu cầu an ninh chung chung mà nói rằng một người sử dụng đăng ký phải được xác nhận trước khi sử dụng SafeHomeAssured.com. Yêu cầu này được áp dụng cho tất cả các chức năng có sẵn cho người dùng SafeHome đăng ký. Vì tinh chỉnh thiết kế xảy ra, A * là một đại diện thiết kế cho yêu cầu A và B * là một đại diện thiết kế cho yêu cầu B. Vì vậy, A * và B * là đại diện của các mối quan tâm, và B * chéo cắt A *. • Một khía cạnh là một đại diện của một mối quan tâm xuyên suốt. Do đó, các đại diện thiết kế, B *, các yêu cầu, một người sử dụng được đăng ký phải được xác nhận trước khi sử dụng SafeHomeAssured.com, là một khía cạnh của SafeHome WebApp. These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 21 22 21 22 Tái cấu trúc OO Các khái niệm thiết kế • Fowler [FOW99] định nghĩa cấu trúc lại theo cách sau đây: • Các lớp thiết kế – "Tái cấu trúc là quá trình thay đổi một hệ thống phần mềm trong – Các lớp thực thể một cách mà nó không làm thay đổi hành vi bên ngoài của mã – Các lớp biên [thiết kế] nhưng cải thiện cấu trúc bên trong của nó.” – các lớp điều khiển – Khi phần mềm được refactored, thiết kế hiện có được kiểm tra về • sự thừa kế—tất cả các trách nhiệm của một lớp cha được ngay sự lập tức được thừa kế bởi tất cả các lớp con » Dư thừa • thông điệp—khuyến khích một số hành vi xảy ra trong đối tượng » yếu tố thiết kế không sử dụng nhận » các thuật toán không hiệu quả hoặc không cần thiết • Đa hình—một đặc tính mà làm giảm đáng kể nỗ lực cần thiết để » cấu trúc dữ liệu xây dựng kém hoặc không phù hợp mở rộng thiết kế. » hoặc bất kỳ sự thất bại thiết kế khác có thể được điều chỉnh để mang lại một thiết kế tốt hơn. These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 23 24 23 24
7. Thiết kế các lớp Mô hình thiết kế • Các lớp phân tích được tinh chỉnh trong quá trình thiết kế để trở thành các lớp high thực thể a na ly sis model class diagrams analysis packages • Các lớp biên phát triển trong thiết kế để tạo ra giao diện (ví dụ, màn hình use-cases - text class diagrams Requirements: CRC models use-case diagrams analysis packages constraints collaboration diagrams activity diagrams CRC models interoperability data flow diagrams swim lane diagrams collaboration diagrams tương tác hoặc báo cáo) mà người dùng thấy và tương tác với với phần mềm. control-flow diagrams targets and collaboration diagrams data flow diagrams processing narratives state diagrams control-flow diagrams configuration – Các lớp biên được thiết kế với trách nhiệm quản lý các đối tượng cách sequence diagrams processing narratives state diagrams thực thể được đại diện cho người sử dụng. sequence diagrams design class realizations subsystems collaboration diagrams technical interface component diagrams • các lớp điều khiển được thiết kế để quản lý design class realizations design design classes subsystems Navigation design activity diagrams collaboration diagrams GUI design sequence diagrams – việc tạo ra hoặc cập nhật các đối tượng thực thể; component diagrams design model design classes refinements to: activity diagrams – Sự tức thời của các đối tượng biên khi họ có được thông tin từ các đối sequence diagrams refinements to: component diagrams design class realizations design classes subsystems activity diagrams tượng thực thể; low collaboration diagrams sequence diagrams deployment diagrams – truyền thông phức tạp giữa các tập của các đối tượng; architecture interface component-level deployment-level – xác nhận của dữ liệu trao đổi giữa các đối tượng hoặc giữa người sử dụng elements elements elements elements và với ứng dụng. process d imension These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 25 26 25 26 Các thành phần Mô hình thiết kế Các thành phần kiến trúc • Các thành phần dữ liệu • Các mô hình kiến trúc [Sha96] có nguồn gốc từ ba nguồn: – Mô hình dữ liệu -> cấu trúc dữ liệu – thông tin về miền ứng dụng cho xây dựng phần mềm; – Mô hình dữ liệu -> kiến trúc cơ sở dữ liệu • Các thành phần kiến trúc – các thành phần mô hình yêu cầu cụ thể như sơ đồ luồng dữ liệu và – miền ứng dụng phân tích các lớp, các mối quan hệ và sự hợp tác của chúng, và – Các lớp phân tích, mối quan hệ, hợp tác và hành vi của chúng được – sự sẵn có của mô hình kiến trúc (Chương 12) và các kiểu (Chương chuyển thành chứng ngộ thiết kế 9). – Patterns và“kiểu” (Chapters 9 and 12) • Các thành phần giao diện – giao diện người dùng (UI) – giao diện bên ngoài đến các hệ thống khác, các thiết bị, mạng, hoặc các nhà sản xuất khác hoặc người dùng thông tin – giao diện nội bộ giữa các thành phần thiết kế khác nhau. • Các yếu tố cấu thành • các thành phần triển khai 27 28 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 27 28
8. Các thành phần giao diện Component Elements MobilePhone WirelessPDA SensorManagement Sensor ControlPanel LCDdisplay LEDindicators keyPadCharacteristics KeyPad speaker wirelessInterface readKeyStroke() decodeKey() displayStatus() lightLEDs() sendControlMsg() > KeyPad readKeystroke() decodeKey() Figure 9.6 UML interface representation for Cont rolPa nel 29 30 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 29 30 Các thành phần triển khai Thiết kế phần mềm Control Panel CPI server Security homeownerAccess • Nội dung 1. Tổng quan thiết kế phần mềm 2. Thiết kế kiến trúc phần mềm Personal computer 3. Thiết kế chi tiết phần mềm externalAccess 4. Thiết kế giao diện người dùng Security Surveillance 5. Thiết kế mẫu 6. Thiết kế giao diện cho ứng dụng WebApp homeManagement communication Figure 9.8 UML deployment diagram for SafeHome 31 These slides are designed to accompany Software Engineering: 32 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 31 32
9. Why Architecture? Tại sao kiến trúc quan trọng? • Các kiến trúc không phải là phần mềm hoạt động. Thay vào đó, nó là • Đại diện của kiến trúc phần mềm là một tạo khả năng cho truyền thông một đại diện cho phép một kỹ sư phần mềm để: giữa tất cả các bên (các bên liên quan) quan tâm đến sự phát triển của 1. phân tích hiệu quả của thiết kế trong việc đáp ứng các yêu cầu đề một hệ thống dựa trên máy tính. ra, • Những kiến trúc làm nổi bật thiết kế quyết định ban đầu mà sẽ có một 2. xem xét lựa chọn thay thế kiến trúc khi thay đổi thiết kế vẫn tương tác động sâu sắc trên tất cả các công việc kỹ thuật phần mềm sau và, đối dễ dàng, và quan trọng hơn, vào sự thành công cuối cùng của hệ thống như là một 3. giảm thiểu rủi ro gắn liền với việc xây dựng các phần mềm. thực thể hoạt động. • Kiến trúc "tạo thành một mode minh bạch tương đối nhỏ về cách hệ thống được cấu trúc và cách các thành phần của nó làm việc cùng nhau” [BAS03]. These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 33 34 33 34 Mô tả kiến trúc Thể loại kiến trúc • IEEE Computer Society đã đề nghị IEEE-Std-1471-2000, Recommended • Thể loại ngụ ý một phân loại cụ thể trong lĩnh vực phần mềm tổng thể. Practice for Architectural Description of Software-Intensive System, [IEE00] • Trong mỗi thể loại, bạn gặp phải một số tiểu phân loại. – để thiết lập một khuôn khổ khái niệm và từ vựng cho việc sử dụng trong – Ví dụ, trong các thể loại của các tòa nhà, bạn sẽ gặp phải những các thiết kế của kiến trúc phần mềm, phong cách chung sau đây: nhà ở, căn hộ, chung cư, cao ốc văn – để cung cấp hướng dẫn chi tiết cho đại diện cho một mô tả kiến trúc, and phòng, tòa nhà công nghiệp, nhà kho, vv. – khuyến khích thực hành thiết kế kiến trúc âm thanh. – Trong mỗi phong cách chung, phong cách cụ thể hơn có thể được • The IEEE Standard định nghĩa một mô tả kiến trúc (AD) là một "một tập hợp các sản phẩm để tài liệu hoá một kiến trúc.” áp dụng. Mỗi phong cách sẽ có một cấu trúc có thể được mô tả – Các mô tả chính nó được đại diện bằng cách sử dụng nhiều quan điểm, bằng một tập các mô hình dự đoán được. nơi từng xem là "một đại diện của cả một hệ thống từ quan điểm của một tập hợp có liên quan của [các bên liên quan] các mối quan tâm.” These slides are designed to accompany Software Engineering: 35 These slides are designed to accompany Software Engineering: 36 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 35 36
10. Kiểu kiến trúc Kiến trúc lấy dữ liệu làm trung tâm • Mỗi phong cách mô tả một loại hệ thống bao gồm: (1) một tập hợp các thành phần (ví dụ, một cơ sở dữ liệu, mô đun tính toán) thực hiện một chức năng cần thiết của một hệ thống, (2) một tập hợp các kết nối cho phép "truyền thông, phối hợp và hợp tác" giữa các thành phần, (3) khó khăn để xác định cách các thành phần có thể được tích hợp để tạo thành hệ thống, và (4) các mô hình ngữ nghĩa cho phép một nhà thiết kế phải hiểu được tính chất tổng thể của hệ thống bằng cách phân tích các đặc tính được biết đến của các bộ phận cấu thành của nó. – Kiến trúc lấy dữ liệu làm trung tâm – Kiến trúc luồng dữ liệu – kiến trúc gọi và trả về – Kiến trúc hướng đối tượng – kiến trúc lớp These slides are designed to accompany Software Engineering: 37 These slides are designed to accompany Software Engineering: 38 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 37 38 Kiến trúc luồng dữ liệu Kiến trúc gọi và trả về These slides are designed to accompany Software Engineering: 39 These slides are designed to accompany Software Engineering: 40 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 39 40
11. Kiến trúc phân lớp Mô hình kiến trúc • Đồng thời —các ứng dụng phải xử lý nhiều nhiệm vụ một cách mô phỏng song song – mô hình quản lý điều hành quy trình hệ thống – bảng kế hoạch pattern • Persistence—Dữ liệu vẫn tồn tại nếu nó tồn tại qua việc thực hiện các quá trình tạo ra nó. Hai mô hình phổ biến: – một mô hình cơ sở dữ liệu hệ thống quản lý áp dụng lưu trữ và truy xuất khả năng của một DBMS với các kiến trúc ứng dụng – một mô hình bền bỉ mức độ ứng dụng mà xây dựng tính năng bền bỉ vào các kiến trúc ứng dụng • Phân phối— cách thức mà hệ thống hoặc các thành phần trong hệ thống giao tiếp với nhau trong một môi trường phân phối – Một nhà môi giới hoạt động như một "người trung gian" giữa các thành phần client và một thành phần máy chủ. These slides are designed to accompany Software Engineering: 41 These slides are designed to accompany Software Engineering: 42 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 41 42 Thiết kế kiến trúc Bối cảnh kiến trúc • Phần mềm này phải được đặt trong bối cảnh Safehome Internet-based – thiết kế cần xác định các thực thể bên ngoài (các hệ thống khác, Product system thiết bị, con người) mà phần mềm tương tác với và bản chất của sự tương tác control • Một tập hợp các nguyên mẫu kiến trúc cần được xác định panel target system: surveillance Security Function function – Một nguyên mẫu là một trừu tượng (tương tự như một lớp) đại uses homeowner peers uses diện cho một phần tử của hệ thống hành vi • Các nhà thiết kế xác định cấu trúc của hệ thống bằng cách xác định và uses tinh chỉnh các thành phần phần mềm thực hiện từng nguyên mẫu sensors sensors These slides are designed to accompany Software Engineering: 43 These slides are designed to accompany Software Engineering: 44 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 43 44
12. Nguyên mẫu Cơ cấu thành phần Controller SafeHome communicates with Executive Function selection Node External Communication Management Security Surveillance Home management GUI Internet Detector Indicator Interface Control detector alarm panel management processing processing Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00]) These slides are designed to accompany Software Engineering: 45 These slides are designed to accompany Software Engineering: 46 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 45 46 Cơ cấu thành phần tinh chỉnh Phân tích thiết kế kiến trúc 1. Thu thập các kịch bản. SafeHome Executive 2. Gợi ý các yêu cầu, ràng buộc, và đặc tả môi trường. 3. Mô tả các phong cách / mô hình kiến trúc đã được lựa chọn để giải External Communication Management quyết các tình huống và yêu cầu: • quan điểm mô-đun Security GUI Internet • góc nhìn quá trình Interface Control detector alarm • quan điểm dòng dữ liệu panel management processing processing 4. Đánh giá chất lượng thuộc tính bằng cách coi mỗi thuộc tính trong sự Keypad processing scheduler phone communication cô lập. CP display functions alarm 5. Xác định mức độ nhạy cảm của các thuộc tính chất lượng với các sensorsensor sensorsensorsensor sensorsensorsensor sensorsensor thuộc tính kiến trúc khác nhau cho một phong cách kiến trúc cụ thể. 6. Kiến trúc ứng cử viên phê bình (được phát triển trong bước 3) bằng cách sử dụng phân tích độ nhạy được thực hiện ở bước 5. These slides are designed to accompany Software Engineering: 47 These slides are designed to accompany Software Engineering: 48 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 47 48
13. Độ phức tạp kiến trúc ADL • Độ phức tạp tổng thể của một kiến trúc đề xuất được đánh giá bằng • Architectural description language (Ngôn ngữ mô tả kiến trúc- cách xem xét sự phụ thuộc giữa các thành phần trong kiến trúc[Zha98] ADL) cung cấp các ngữ nghĩa và cú pháp để mô tả một kiến trúc – Chia sẻ phụ thuộc đại diện cho mối quan hệ phụ thuộc giữa các phần mềm khách hàng sử dụng cùng một tài nguyên hoặc các nhà sản xuất đã • Cung cấp cho nhà thiết kế với khả năng: sản xuất ra cho cùng những người tiêu dùng . – phân giải các thành phần kiến trúc – Phụ thuộc luồng đại diện cho mối quan hệ phụ thuộc giữa sản xuất – kết hợp thành phần riêng lẻ thành các khối kiến trúc lớn hơn và và tiêu dùng các nguồn lực. – đại diện cho giao diện (cơ chế kết nối) giữa các thành phần. – Phụ thuộc ràng buộc đại diện cho các ràng buộc vào các luồng liên quan của kiểm soát trong một tập hợp các hoạt động. These slides are designed to accompany Software Engineering: 49 These slides are designed to accompany Software Engineering: 50 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 49 50 Một phương pháp thiết kế kiến trúc Phát sinh Kiến trúc Chương trình yêu cầu khách hàng "bốn phòng ngủ, ba phòng tắm, rất nhiều kính " Kiến trúc Chương trình thiết kế kiến trúc These slides are designed to accompany Software Engineering: 51 These slides are designed to accompany Software Engineering: 52 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 51 52
14. Phân vùng Kiến trúc Phân vùng ngang • Phân vùng "ngang" và ”dọc" là cần thiết • xác định các nhánh riêng biệt của hệ thống phân cấp module cho từng chức năng chính • sử dụng mô-đun điều khiển để phối hợp truyền thông giữa các chức năng function 1 funcon 3 function 2 These slides are designed to accompany Software Engineering: 53 These slides are designed to accompany Software Engineering: 54 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 53 54 Phân vùng dọc: Factoring Tại sao phân vùng Kiến trúc? • thiết kế để việc ra quyết định và làm việc được phân tầng • kết quả trong phần mềm dễ dàng kiểm tra hơn • module ra quyết định nên nằm ở trên cùng của kiến trúc • dẫn đến phần mềm dễ dàng để duy trì hơn • kết quả trong lan truyền ít tác dụng phụ hơn decision-makers • kết quả trong phần mềm dễ dàng để mở rộng hơn workers These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. These slides are designed to accompany Software Engineering: 55 56 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 55 56
15. Thiết kế cấu trúc Các đặc tính luồng • Mục tiêu: để đưa ra một kiến trúc chương trình được phân chia • phương pháp tiếp cận: – một DFD được ánh xạ vào một kiến trúc chương trình Luồng chuyển đổi – các PSPEC và STD được sử dụng để chỉ ra các nội dung của mỗi mô-đun This edition of SEPA does not • ký pháp: biểu đồ cấu trúc cover transaction mapping. For a detailed discussion see the SEPA website Luồng giao dịch These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 57 58 57 58 Phương pháp tiếp cận ánh xạ chung Phương pháp tiếp cận ánh xạ chung • cô lập ranh giới luồng vào và ra; cho các luồng giao dịch, cô lập • Cô lập các trung tâm chuyển đổi bằng cách xác định ranh giới luồng vào và ra các trung tâm giao dịch • Thực hiện ”factoring.cấp độ đầu tiên” • làm việc kể từ ranh giới bên ngoài, ánh xạ DFD biến đổi thành – Các kiến trúc chương trình có nguồn gốc sử dụng kết quả ánh xạ này các module tương ứng trong một phân bố trên-xuống của điều khiển. – Factoring dẫn đến một cấu trúc chương trình trong đó các thành phần cấp • thêm module điều khiển theo yêu cầu cao thực hiện việc ra quyết định và thành phần ở mức độ thấp thực hiện • tinh chỉnh cấu trúc chương trình kết quả bằng cách sử dụng các hầu hết công việc đầu vào, tính toán, và đầu ra. khái niệm mô đun hiệu quả – Thành phần cấp trung thực hiện một số kiểm soát và làm một lượng vừa phải công việc. • Thực hiện ”factoring.cấp độ hai." These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 59 60 59 60
16. Ánh xạ chuyển đổi Factoring g h b f direction of increasing a d e decision making typical "decision c i j making" modules data flow model x1 "Transform" mapping x2 x3 x4 b c d e f g i a h j typical "worker" modules These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 61 62 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 61 62 Factoring cấp độ một Ánh xạ cấp độ hai điều khiển chương trình main chính D C control B A điều A điều khiển điều khiển B đầu vào khiển xử đầu ra lí C mapping from the D flow boundary outward 63 64 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 63 64
17. Thiết kế phần mềm Thế nào là một thành phần? • OMG Unified Modeling Language Specification [OMG01] định nghĩa • Nội dung một thành phần (component) như là: 1. Tổng quan thiết kế phần mềm – Một phần có tính mô-đun, có thể triển khai và thay thế của một hệ thống 2. Thiết kế kiến trúc phần mềm mà đóng gói việc thực thi và đưa ra một tập các giao diện. • Góc nhìn hướng đối tượng: Một thành phần bao gồm một tập các lớp 3. Thiết kế chi tiết phần mềm cộng tác. 4. Thiết kế giao diện người dùng • Góc nhìn quy ước: Một thành phần bao gồm logic xử lý, cấu trúc dữ 5. Thiết kế mẫu liệu bên trong cần thiết để triển khai logic đó và một giao diện cho 6. Thiết kế giao diện cho ứng dụng WebApp phép thành phần được gọi và dữ liệu được truyền đến nó. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 65 66 65 66 Thành phần hướng đối tượng Thành phần quy ước design component analysis class getJobData PrintJob numberOfPages ComputePageCost numberOfSides paperType magnification productionFeatures accessCostsDB design component computeJobCost() computeJob passJobtoPrinter() PrintJob elaborated module initiateJob PageCost in: numberPages in: numberDocs in: sides= 1, 2 > elaborated design class co mp u teJo b in: color=1, 2, 3, 4 PrintJob in: page size = A, B, C, B computePageCost () numberOfPages out: page cost computePaperCost () numberOfSides computeProdCost () paperType in: job size computeTotalJobCost () paperWeight paperSize in: color=1, 2, 3, 4 paperColor in: pageSize = A, B, C, B magnification colorRequirements out: BPC productionFeatures out: SF collationOptions bindingOptions coverStock > bleed getJobData (numberPages, numberDocs, in itiateJo b priority job size (JS) = totalJobCost sides, color, pageSize, pageCost) buildWorkOrder() WOnumber accessCostsDB (jobSize, color, pageSize, numberPages * numberDocs; checkPriority () lookup base page cost (BPC) > passJobto Production() computePageCost () BPC, SF) computePaperCost () computePageCost() accessCostsDB (JS, color); computeProdCost () computeTotalJobCost () lookup size factor ( SF) > buildWorkOrder() checkPriority () accessCostDB (JS, color, size) passJobto Production() job complexity factor ( JCF) = 1 + [(sides-1)* sideCost + SF] pagecost = BPC * JCF These slides are designed to accompany Software Engineering: 67 These slides are designed to accompany Software Engineering: 68 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 67 68
18. Nguyên lý thiết kế cơ bản Hướng dẫn thiết kế • Nguyên lý mở-đóng (OCP): Một mô-đun (thành phần) nên được mở cho việc • Thành phần: mở rộng nhưng nên đóng cho việc hiệu chỉnh. – Quy ước đặt tên nên được thiết lập cho các thành phần được xác định như • Nguyên lý thay thế Liskov (LSP): Các lớp con nên thay thế được các lớp gốc. là một phần của mô hình kiến trúc rồi sau đó tinh chỉnh và xây dựng như • Nguyên lý tráo đổi phụ thuộc (DIP): Phụ thuộc vào trừu tượng hóa, không phụ là một phần của mô hình mức thành phần thuộc vào kết cấu. • Giao diện: • Nguyên lý tách biệt giao diện (ISP): “Nhiều giao diện khách hàng cụ thể thì – Giao diện cung cấp thông tin quan trọng về sự giao tiếp và cộng tác (đồng tốt hơn một giao diện mục đích chung.” thời cũng giúp chúng ta đạt được OPC) • Nguyên lý phát hành và tái sử dụng tương đương (DEP): “Hạt nhỏ của việc tái • Phụ thuộc và kế thừa: sử dụng cũng là hạt nhỏ của việc phát hành” – Việc mô hình hóa sự phụ thuộc từ trái sang phải và sự kế thừa từ dưới lên • Nguyên lý đóng chung (CCP). “Các lớp thay đổi cùng nhau thì thuộc về nhau” trên. • Nguyên lý tái sử dụng chung (CRP). “Các lớp không được tái sử dụng cùng nhau thì không nên nhóm lại với nhau” Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000. These slides are designed to accompany Software Engineering: 69 These slides are designed to accompany Software Engineering: 70 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 69 70 Sự gắn kết (cohesion) Sự gắn kết (cohesion) • Góc nhìn quy ước: • Các mức của sự gắn kết: – Một “tư duy đơn lẻ” của một mô-đun. – Chức năng • Góc nhìn hướng đối tượng: – Tầng – Sự gắn kết nghĩa là một thành phần hoặc một lớp chỉ đóng gói các – Truyền thông thuộc tính và hoạt động liên quan chặt chẽ với nhau và với bản – Liên tục thân thành phần hoặc lớp đó. – Thủ tục – Phụ thuộc thời gian – Lợi ích These slides are designed to accompany Software Engineering: 71 These slides are designed to accompany Software Engineering: 72 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 71 72
19. Ghép nối (coupling) Thiết kế mức thành phần - I • Góc nhìn quy ước: • Bước 1. Xác định tất cả các lớp thiết kế tương ứng với miền vấn đề. – Là mức độ mà một thành phần kết nối với các thành phần khác và với thế giới bên • Bước 2. Xác định tất cả các lớp thiết kế tương ứng với kết cấu hạ ngoài. • Góc nhìn hướng đối tượng: tầng. – Một thước đo chất lượng mức độ kết nối của các lớp với lớp khác. • Bước 3. Xây dựng tất cả các lớp không có được như là thành phần • Các mức của sự ghép nối: tái sử dụng. – Nội dung • Bước 3a. Xác định chi tiết thông điệp khi các lớp hoặc các thành – Chung – Điều khiển phần cộng tác. – Đánh dấu • Bước 3b. Xác định các giao diện thích hợp cho mỗi thành phần. – Dữ liệu – Lời gọi công thức – Loại sử dụng – Sự lồng ghép và bao hàm. – Bên ngoài These slides are designed to accompany Software Engineering: 73 These slides are designed to accompany Software Engineering: 74 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 73 74 Thiết kế mức thành phần - II Sơ đồ cộng tác • Step 3c. Xây dựng các thuộc tính và xác định kiểu dữ liệu và cấu trúc dữ liệu cần thiết để thực hiện chúng. :ProductionJob • Step 3d. Mô tả luồng xử lý trong từng hoạt động cụ thể. • Step 4. Mô tả các nguồn dữ liệu bền vững (cơ sở dữ liệu và các tập tin) và xác định các lớp cần thiết để quản lý chúng. 1: buildJob (WOnumber) • Step 5. Phát triển và xây dựng biểu diễn hành vi cho một lớp hoặc một 2: submitJob (WOnumber) thành phần. • Step 6. Xây dựng sơ đồ triển khai để cung cấp thêm thông tin về chi :WorkOrder tiết thực hiện. :JobQueue • Step 7. Nhân tố hóa mỗi thể hiện thiết kế mức thành phần và luôn luôn xem xét phương án thay thế. These slides are designed to accompany Software Engineering: 75 These slides are designed to accompany Software Engineering: 76 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 75 76
20. Sơ đồ hoạt động validate attributes Tái cấu trúc input computeJob accessPaperDB (weight) PrintJob returns baseC ostperPage initiateJob paperC ostperPage = baseC ostperPage WorkOrder size = B paperC ostperPage = paperC ostperPage *1 .2 appropriate attributes > getJobDescriiption buildJob initiateJob size = C buildWorkOrder () paperC ostperPage = paperC ostperPage *1 .4 passJobToProduction() ProductionJob size = D paperC ostperPage = paperC ostperPage *1 .6 submitJob JobQueue appropriate attributes color is custom paperC ostperPage = paperC ostperPage *1 .1 4 checkPriority () color is standard returns ( paperC ostperPage ) These slides are designed to accompany Software Engineering: 77 These slides are designed to accompany Software Engineering: 78 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 77 78 behavior within the Sơ đồ trạng thái state buildingJobData dataInputIncomplete buildingJobData entry/readJobData () Thiết kế thành phần cho WebApps exit/displayJobData () do/checkConsistency() include/dataInput • Thành phần WebApp là: dataInputCompleted [all data items consistent]/displayUserOptions – (1) Một chức năng được xác định rõ và có tính kết hợp, thao tác computingJobCost nội dung hoặc cung cấp quá trình tính toán hoặc xử lí dữ liệu cho entry/computeJob exit/save totalJobCost người dùng cuối hoặc: – (2) Một gói có tính kết hợp của nội dung và chức năng, cung cấp jobCostAccepted [customer is authorized]/ getElectronicSignature cho người dùng cuối các khả năng được yêu cầu. formingJob entry/buildJob exit/save WOnumber • Vì vậy, thiết kế mức thành phần cho WebApps thường kết hợp các yếu do/ tố của thiết kế nội dung và thiết kế chức năng. submittingJob entry/submitJob exit/initiateJob do/place on JobQueue jobSubmitted [all authorizations acquired]/ printWorkOrder These slides are designed to accompany Software Engineering: 79 These slides are designed to accompany Software Engineering: 80 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 79 80
21. Thiết kế nội dung cho WebApps Thiết kế chức năng cho WebApps • Tập trung vào các đối tượng nội dung và cách thức mà chúng có thể được • Các ứng dụng Web hiện đại cung cấp các chức năng xử lý ngày càng phức tạp: đóng gói để trình bày cho một người dùng cuối. – (1) thực hiện xử lý địa phương để tạo ra nội dung và khả năng chuyển • Hãy xem xét một khả năng giám sát video trên nền web tại hướng theo kiểu động; SafeHomeAssured.com – (2) cung cấp khả năng tính toán hoặc xử lý dữ liệu thích hợp cho miền – Các thành phần nội dung tiềm năng có thể được xác định cho khả năng nghiệp vụ của WebApps; giám sát video: – (3) cung cấp truy vấn hoặc truy cập CSDL phức tạp, hoặc » (1) các đối tượng nội dung biểu diễn cách bố trí không gian (kế hoạch – (4) thiết lập giao diện dữ liệu với hệ thống hợp tác bên ngoài. sàn) với các biểu tượng thêm vào để đại diện cho vị trí của cảm biến • Để đạt được những khả năng này (và nhiều khả năng khác), bạn sẽ thiết kế và và máy quay video; xây dựng thành phần chức năng của WebApp giống hệt về dạng với các thành » (2) tập hợp các hình ảnh thu nhỏ và đoạn video (cho mỗi đối tượng phần phần mềm trong phần mềm quy ước. dữ liệu riêng biệt) và » (3) cửa sổ quay video cho từng camera riêng biệt. – Mỗi một thành phần trên có thể được đặt tên và xử lí một cách riêng biệt như là một gói. These slides are designed to accompany Software Engineering: 81 These slides are designed to accompany Software Engineering: 82 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 81 82 Thiết kế thành phần quy ước Thiết kế thuật toán • Việc thiết kế các xử lý logic được quy định bởi các nguyên tắc cơ bản • Là hoạt động thiết kế sát nhất với việc coding. của thiết kế thuật toán và lập trình có cấu trúc. • Cách tiếp cận: • Việc thiết kế các cấu trúc dữ liệu được định nghĩa bởi các mô hình dữ – xem xét mô tả thiết kế cho các thành phần liệu được phát triển cho hệ thống. – sử dụng tinh chỉnh từng bước để phát triển thuật toán • Việc thiết kế các giao diện được quy định bởi sự hợp tác mà một thành – sử dụng lập trình có cấu trúc để thực hiện logic có tính thủ tục phần phải có ảnh hưởng. – sử dụng ‘phương pháp chính thống’ để chứng minh logic. These slides are designed to accompany Software Engineering: 83 These slides are designed to accompany Software Engineering: 84 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 83 84
22. Tinh chỉnh từng bước Mô hình thiết kế thuật toán open • Trình bày các thuật toán ở mức độ chi tiết mà có thể được xem xét lại chất lượng. • Tùy chọn: walk to door; – reach for knob; Đồ họa (e.g. flowchart, box diagram) – Mã giả (e.g., PDL) open door; repeat until door opens turn knob clockwise; – Ngôn ngữ lập trình walk through; if knob doesn't turn, then close door. take key out; – Bảng quyết định find correct key; insert in lock; endif pull/push door move out of way; end repeat These slides are designed to accompany Software Engineering: 85 These slides are designed to accompany Software Engineering: 86 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 85 86 Lập trình cấu trúc Một thiết kế thủ tục có cấu trúc • Sử dụng một tập hạn chế các cấu trúc logic: add a condition Z, a if true, exit the program Chuỗi Điều kiện — if-then-else, select-case x1 Vòng lặp — do-while, repeat until b x2 c • Dẫn đến những đoạn mã dễ đọc, dễ kiểm thử. x3 d • Có thể sử dụng kết hợp với “chứng minh tính đúng đắn” f e • Rất quan trọng để có thể đạt được chất lượng tốt, x4 • nhưng chưa đủ. g x5 These slides are designed to accompany Software Engineering: 87 These slides are designed to accompany Software Engineering: 88 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 87 88
23. Bảng quyết định Ngôn ngữ lập trình thiết kế (PDL) Rules Conditions 1 2 3 4 5 6 if condition x regular customer T T then process a; else process b; silver customer T T endif gold customer T T if-then-else PDL special discount F T F T F T easy to combine with source code Rules machine readable, no need for graphics input no discount apply 8 percent discount graphics can be generated from PDL apply 15 percent discount enables declaration of data as well as procedure apply additional x percent discount easier to maintain These slides are designed to accompany Software Engineering: 89 These slides are designed to accompany Software Engineering: 90 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 89 90 Vì sao chọn ngôn ngữ thiết kế? Sự phát triển dựa trên thành phần • Có thể được bắt nguồn từ HOL của lựa chọn • Khi phải đối mặt với khả năng tái sử dụng, nhóm phần mềm xem • Máy móc có thể hiểu và xử lý được. xét: • Có thể được nhúng với mã nguồn, do đó dễ bảo trì hơn. – Liệu các thành phần thương mại off-the-shelf có sẵn để triển • Có thể được trình bày rất chi tiết, nếu người thiết kế và người lập khai các yêu cầu? trình là khác nhau – Liệu thành phần tái sử dụng phát triển bên trong có sẵn để • Dễ dàng xem xét lại thực hiện các yêu cầu? – Liệu các giao diện cho các thành phần có sẵn có tương thích trong kiến trúc của hệ thống được xây dựng? • Đồng thời, họ cũng đang phải đối mặt với những trở ngại sau đây để tái sử dụng These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 91 92 91 92
24. Trở ngại để tái sử dụng Quá trình CBSE • Rất ít công ty và các tổ chức có một kế hoạch tái sử dụng phần mềm toàn diện dù chỉ ở mức khá nghiêm túc. • Mặc dù ngày càng nhiều nhà cung cấp phần mềm hiện nay bán các công cụ hoặc thành phần cung cấp sự hỗ trợ trực tiếp cho việc tái sử dụng phần mềm, phần lớn nhà phát triển không sử dụng chúng. • Tương đối ít sự huấn luyện có sẵn để giúp các kỹ sư và các nhà quản lý phần mềm hiểu và áp dụng tái sử dụng. • Nhiều học viên phần mềm tiếp tục tin rằng tái sử dụng là "rắc rối hơn là giá trị." • Nhiều công ty tiếp tục khuyến khích các phương pháp phát triển phần mềm không áp dụng tái sử dụng • Rất ít công ty cung cấp ưu đãi để sản xuất các chương trình tái sử dụng. These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 93 94 93 94 Kỹ thuật miền Xác định các thành phần tái sử dụng • Chức năng thành phần có cần thiết cho việc triển khai trong tương lai? 1. Xác định các miền được nghiên cứu • Mức độ phổ biến của chức năng của các thành phần trong các tên miền là như thế nào? 2. Phân loại các mặt hàng được xuất từ miền. • Có trùng lặp chức năng của các thành phần trong các tên miền không? 3. Thu thập một mẫu đại diện của các ứng dụng trong miền. • Thành phần có phụ thuộc phần cứng không? • Liệu các phần cứng có giữ nguyên trạng trong quá trình triển khai? 4. Phân tích mỗi ứng dụng trong mẫu. • Chi tiết cụ thể phần cứng có thể được loại bỏ cho thành phần khác? 5. Xây dựng một mô hình phân tích cho các đối tượng. • Liệu thiết kế có đủ tối ưu hóa cho bước triển khai tiếp theo? • Liệu chúng ta có thể tham số hóa một thành phần không thể tái sử dụng để nó trở nên tái sử dụng? • Liệu có thể tái sử dụng các thành phần trong nhiều lần triển khai với chỉ những thay đổi nhỏ? • Việc tái sử dụng thông qua sửa đổi có khả thi? • Một thành phần không thể tái sử dụng có thể được phân tách để tạo ra phần tái sử dụng? These slides are designed to accompany Software Engineering: • Việc phân tách thành phần cho tái sử dụng hợp lệ như thế nào? A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 95 These slides are designed to accompany Software Engineering: 96 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 95 96
25. Kỹ thuật phần mềm dựa trên thành phần Các hoạt động CBSE (CBSE) • Một thư viện các thành phần phải sẵn có • Tiêu chuẩn thành phần • Các thành phần cần có một cấu trúc nhất quán • Thích ứng thành phần • Nên tồn tại một tiêu chuẩn, ví dụ, • Ghép nối thành phần – OMG / CORBA • Cập nhật thành phần – Microsoft COM – Sun JavaBeans These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 97 98 97 98 Tiêu chuẩn Sự thích ứng Trước khi một thành phần có thể sử dụng, bạn phải xem xét: Ý nghĩa của "dễ dàng tích hợp" là: • Giao diện lập trình ứng dụng (API) 1. các phương pháp nhất quán trong quản trị tài nguyên đã được triển • Các công cụ phát triển và tích hợp theo yêu cầu của các thành phần khai cho tất cả các thành phần trong thư viện; • Các yêu cầu tại thời điểm chạy bao gồm cả sử dụng tài nguyên (ví dụ, 2. có hoạt động chung như quản lý dữ liệu tồn tại cho tất cả các thành bộ nhớ hoặc lưu trữ), thời gian hay tốc độ, và giao thức mạng phần, và • Các yêu cầu dịch vụ bao gồm cả giao diện hệ điều hành và hỗ trợ từ 3. có giao diện trong kiến trúc và với môi trường bên ngoài đã được triển các thành phần khác. khai một cách nhất quán. • Các tính năng bảo mật bao gồm kiểm soát truy cập và giao thức xác thực • giả định thiết kế nhúng bao gồm cả việc sử dụng các thuật toán số học hoặc phi số học cụ thể • Xử lý ngoại lệ These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 10 99 0 99 100
26. Ghép nối (composition) OMG/ CORBA • Một cơ sở hạ tầng phải được thiết lập để ràng buộc các thành • Nhóm quản lý đối tượng (Object Management Group) đã xuất bản một kiến phần với nhau trúc môi giới yêu cầu đối tượng chung (common object request broker architecture ) (OMG/CORBA). • Thành phần kiến trúc cho các thành phần bao gồm: • Một sự môi giới yêu cầu đối tượng (ORB) cung cấp dịch vụ cho phép các – Mô hình trao đổi dữ liệu thành phần (đối tượng) giao tiếp với các thành phần khác, bất kể vị trí của – Tự động hóa chúng trong hệ thống. – Lưu trữ có cấu trúc • Sự tích hợp các thành phần CORBA (mà không sửa đổi) trong một hệ thống – Mô hình đối tượng tiềm ẩn được đảm bảo nếu một ngôn ngữ định nghĩa giao diện (IDL) được tạo ra cho mỗi thành phần. • Các đối tượng trong các ứng dụng khách yêu cầu một hoặc nhiều dịch vụ từ máy chủ ORB. Yêu cầu được thực hiện thông qua một IDL hoặc tự động tại thời điểm chạy. • Một kho giao diện chứa tất cả các thông tin cần thiết về định dạng của yêu cầu These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. và hồi đáp của dịch vụ. 10 10 These slides are designed to accompany Software Engineering: 1 2 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 101 102 Kiến trúc ORB Microsoft COM Interface Client • Mô hình đối tượng thành phần (COM) cung cấp một đặc tả cho Repository việc sử dụng các thành phần được sản xuất bởi các nhà cung cấp khác nhau trong một ứng dụng duy nhất chạy dưới hệ điều hành Dynamic Client ORB Windows. Invocation IDL interface Stubs • COM bao gồm 2 thành phần: Server – Giao diện COM (được triển khai như đối tượng COM) LAN Objects ORB Core – một tập hợp các cơ chế đăng ký và truyền các thông điệp giữa các giao diện COM. Server ORB Object IDL interface Adapter Stubs Interface Repository These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 10 10 These slides are designed to accompany Software Engineering: 3 4 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 103 104
27. Sun JavaBeans Phân loại • Hệ thống thành phần JavaBeans là một cơ sở hạ tầng CBSE di động, • Phân loại liệt kê: các linh kiện được mô tả bằng cách định nghĩa một độc lập nền tảng được phát triển sử dụng ngôn ngữ lập trình Java. cấu trúc phân cấp trong đó các lớp và mức độ khác nhau của các lớp • Hệ thống thành phần JavaBeans bao gồm một tập các công cụ, được con của các thành phần phần mềm được xác định gọi là Bean Development Kit (BDK) cho phép nhà phát triển: • Phân loại nhiều mặt: một khu vực miền được phân tích và một tập hợp – phân tích sự hoạt động của một Beans (thành phần). các tính năng mô tả cơ bản được xác định – tùy chỉnh hành vi và sự hình thức của chúng • Phân loại thuộc tính-giá trị: một tập các thuộc tính được định nghĩa cho – thiết lập cơ chế phối hợp và truyền thông tất cả các thành phần trong một khu vực miền. – phát triển các Beans tùy chỉnh để sử dụng trong một ứng dụng cụ thể – kiểm tra và đánh giá hành vi của Beans These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 10 10 5 6 105 106 Đánh chỉ mục Môi trường tái sử dụng • Một cơ sở dữ liệu thành phần có khả năng lưu trữ các thành phần phần mềm và thông tin phân loại cần thiết để lấy chúng. • Một hệ thống quản lý thư viện cung cấp quyền truy cập vào cơ sở dữ liệu. • Một hệ thống truy xuất thành phần phần mềm cho phép một ứng dụng khách có thể lấy các thành phần và dịch vụ từ các máy chủ thư viện. • Công cụ CBSE có hỗ trợ việc tích hợp các thành phần tái sử dụng trong một thiết kế hoặc thực hiện mới. These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 10 10 7 8 107 108
28. Thiết kế phần mềm Thiết kế giao diện Dễ học? • Nội dung Dễ sử dụng? 1. Tổng quan thiết kế phần mềm Dễ hiểu? 2. Thiết kế kiến trúc phần mềm 3. Thiết kế chi tiết phần mềm 4. Thiết kế giao diện người dùng 5. Thiết kế mẫu 6. Thiết kế giao diện cho ứng dụng WebApp These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 11 109 0 109 110 Thiết kế giao diện Quy tắc vàng • Đặt người dùng trong sự kiểm soát Lỗi thiết kế thông thường • Giảm tải bộ nhớ cho người dùng thiếu nhất quán quá nhiều ghi nhớ • Làm cho giao diện nhất quán không có hướng dẫn / giúp đỡ không nhạy cảm với ngữ cảnh đáp ứng kém Phức tạp / không thân thiện Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000. 11 11 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2 111 112
29. Đặt người dùng trong sự kiểm soát Giảm tải bộ nhớ cho người dùng • Xác định phương thức tương tác theo một cách mà không ép người • Giảm nhu cầu về bộ nhớ ngắn hạn. dùng tới những hành động không cần thiết hoặc không mong muốn. • Thiết lập các mặc định có ý nghĩa. • Cung cấp sự tương tác linh hoạt. • Xác định các phím tắt trực quan. • Cho phép tương tác người dùng được ngắt và hoàn tác . • Các thiết kế trực quan của giao diện phải được dựa trên một phép ẩn dụ • Hợp lý hóa tương tác như trình độ kỹ năng cao và cho phép tùy chỉnh thế giới thực. tương tác. • Tiết lộ thông tin theo kiểu lũy tiến. • Ẩn kỹ thuật bên trong với người sử dụng bình thường. • Thiết kế cho tương tác trực tiếp với các đối tượng xuất hiện trên màn hình. 11 11 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: 3 4 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 113 114 Làm cho giao diện nhất quán Mô hình thiết kế giao diện người dùng • Cho phép người sử dụng đưa các tác vụ hiện hành vào một ngữ cảnh có • Mô hình người dùng — một hồ sơ của tất cả người dùng cuối của hệ ý nghĩa. thống • Duy trì tính nhất quán giữa một họ các ứng dụng. • Mô hình thiết kế — một nhận thức thiết kế của các mô hình sử dụng • Nếu mô hình tương tác cũ đã tạo ra những kỳ vọng của người dùng, • Mô hình về tinh thần (nhận thức hệ thống) — hình ảnh nhận thức của không làm thay đổi trừ khi có một lý do thuyết phục để làm như vậy. người dùng về những gì giao diện là • Mô hình triển khai — giao diện "nhìn và cảm nhận" cùng với thông tin hỗ trợ mô tả cú pháp và ngữ nghĩa giao diện 11 11 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: 5 6 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 115 116
30. Quá trình thiết kế giao diện người dùng Phân tích giao diện • Phân tích giao diện nghĩa là hiểu được: – (1) những người (người dùng cuối), người sẽ tương tác với các hệ thống thông qua giao diện; – (2) các tác vụ mà người dùng phải thực hiện để làm công việc của họ, – (3) các nội dung được trình bày như là một phần của giao diện – (4) môi trường trong đó những công việc này sẽ được tiến hành. 11 11 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: 7 8 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 117 118 Phân tích người dùng Phân tích tác vụ và mô hình hóa • Liệu người dùng là các chuyên gia đã qua đào tạo, kỹ thuật viên, văn thư hay là công nhân • Trả lời những câu hỏi sau sản xuất? • Mức độ giáo dục trung bình của người dùng là gì? – Công việc gì mà người dùng sẽ thực hiện trong những trường hợp cụ thể? • Liệu người dùng có thể học từ những tài liệu viết hay họ bày tỏ mong muốn một chương – Tác vụ hay tác vụ con nào sẽ được thực hiện khi người dùng làm việc? trình luyện tập kiểu lớp học? – Những vấn đề miền đối tượng cụ thể nào mà người dùng sẽ thao tác khi • Người dùng là những chuyên gia đánh máy hay họ sợ bàn phím? công việc được thực hiện? • Độ tuổi của cộng đồng người dùng là bao nhiêu? – Chuỗi các nhiệm vụ-quy trình là gì? • Liệu người dùng sẽ được đại diện chủ yếu bởi một giới tính? – Hệ thống cấp bậc của tác vụ là gì? • Người dùng sẽ trả cho công việc họ thực hiện như thế nào? • Liệu người dùng chỉ làm việc trong giờ công sở hay họ sẽ làm việc đến khi công việc hoàn • Use-cases xác định tương tác cơ bản. thành? • Xây dựng tác vụ điều chỉnh các nhiệm vụ tương tác. • Liệu phần mềm sẽ trở thành một phần quan trọng trong công việc của người dùng hay nó sẽ • Xây dựng đối tượng xác định đối tượng giao diện (lớp) chỉ thỉnh thoảng được sử dụng? • Phân tích quy trình làm việc xác định cách một quá trình làm việc được hoàn • Ngôn ngữ chính giữa các người dùng là gì? thành khi một số người (và vai trò) đều tham gia • Sẽ có những hệ quả nào nếu người dùng gây ra lỗi khi sử dụng hệ thống? • Liệu người dùng có phải là chuyên gia trong lĩnh vực liên quan được xử lý bởi hệ thống? • Liệu người dùng có muốn biết về công nghệ phía sau giao diện? These slides are designed to accompany Software Engineering: 11 These slides are designed to accompany Software Engineering: 12 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0 119 120
31. Sơ đồ Swimlane patient pharmacist physician re q u e sts th at a d e te rmin e s statu s o f p re scrip tio n b e re fille d Phân tích nội dung hiển thị p re scrip tio n no refills ch e cks p atie n t • Liệu các loại dữ liệu khác nhau có được gán cho vị trí địa lý nhất định trên remaining re co rd s refills màn hình (ví dụ, hình ảnh luôn luôn xuất hiện ở góc trên bên phải)? remaining approves refill • Liệu người dùng có thể tùy chỉnh vị trí màn hình cho nội dung? refill not ch e cks in v e n to ry fo r allowed re fill o r alte rn ativ e • Liệu các nhận dạng phù hợp có được gán cho tất cả nội dung? e v alu ate s alte rn ativ e me d icatio n • Nếu một báo cáo lớn được trình bày, nó sẽ được phân chia như thế nào cho dễ re ce iv e s o u t o f sto ck out of stock n o tificatio n alternative hiểu? available in stock re ce iv e s time /d ate none • Liệu cơ chế có sẵn sàng để di chuyển trực tiếp tới thông tin tóm tắt cho lượng to p ick u p dữ liệu lớn? p icks u p fills p re scrip tio n p re scrip tio n • Liệu các đầu ra đồ họa có được căn chỉnh để vừa vặn với các giới hạn của re ce iv e s re q u e st to thiết bị hiển thị được sử dụng? co n tact p h y sician • Màu sắc sẽ được sử dụng như thế nào để tăng tính dễ hiểu? • Thông báo lỗi và cảnh báo sẽ được trình bày tới người dùng như thế nào? Figure 12.2 Swimlane diagram for prescription refill function 12 12 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2 121 122 Các bước thiết kế giao diện Các vấn đề thiết kế • Sử dụng thông tin được phát triển trong quá trình phân tích giao diện, • Thời gian trả lời xác định đối tượng giao diện và hành động (hoạt động). • Trợ giúp các tiện nghi • Xác định các sự kiện (các hành động người dùng) sẽ gây ra sự thay đổi • Xử lý lỗi trạng thái của giao diện người dùng. Mô hình hóa hành vi này. • Gắn nhãn menu và câu lệnh • Miêu tả mỗi trạng thái giao diện như thể nó sẽ thực sự tìm đến người • Khả năng tiếp cận ứng dụng dùng cuối. • Quốc tế hóa • Xác định cách người dùng diễn giải các trạng thái của hệ thống từ thông tin được cung cấp thông qua giao diện. 12 12 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4 123 124
32. Thiết kế giao diện WebApp Giao diện WebApp hiệu quả • Tôi đang ở đâu? Giao diện nên • Bruce Tognozzi [TOG01] gợi ý rằng – cung cấp một dấu hiệu rằng các WebApp đó đã được tiếp cận – Giao diện hiệu quả rất trực quan rõ ràng và rộng rãi, mang lại cho – thông báo cho người sử dụng vị trí của họ trong hệ thống phân cấp nội người dùng cảm giác kiểm soát. Người dùng nhanh chóng nhận ra dung. sự rộng rãi của các tùy chọn, nắm bắt cách để đạt được mục tiêu và • Tôi có thể làm gì bây giờ? Giao diện phải luôn luôn giúp người dùng hiểu các làm công việc của họ. tùy chọn hiện tại của mình – Giao diện hiệu quả khiến người dùng không phải quan tâm đến hoạt – Những chức năng nào đang có sẵn? – Những liên kết nào còn hoạt động? động bên trong hệ thống. Công việc được lưu trữ cẩn thận và liên – Những nội dung nào có liên quan? tục, với đầy đủ tùy chọn cho người dùng được hoàn tác bất kì hoạt • Tôi đã từng ở đâu, tôi sẽ đi đâu? Giao diện phải tạo điều kiện cho việc điều động nào tại thời điểm bất kì. hướng – Ứng dụng và dịch vụ hiệu quả thực hiện công việc lượng công việc – Cung cấp một "bản đồ" (được thực hiện một cách dễ hiểu) về nơi mà tối đa, trong khi yêu cầu lượng thông tin tối thiểu. người sử dụng đã đi qua và những con đường có thể được thực hiện để chuyển đến nơi khác trong phạm vi WebApp. 12 12 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6 125 126 Nguyên tắc thiết kế giao diện-I Nguyên tắc thiết kế giao diện-II • Dự đoán—Một WebApp nên được thiết kế sao cho nó dự đoán được động • Tập trung -Giao diện WebApp (và nội dung nó trình bày) nên tiếp tục tập thái tiếp theo của việc sử dụng. trung vào các nhiệm vụ người dùng. • Truyền thông—Giao diện nên truyền thông tình trạng của bất kỳ hoạt • Luật Fitt - "Thời gian để có được một mục tiêu là một hàm của khoảng động khởi xướng bởi người sử dụng cách đến và kích thước của các mục tiêu." • Nhất quán—việc sử dụng điều hướng, menu, biểu tượng, và thẩm mỹ (ví • Đối tượng giao diện con người - một thư viện tái sử dụng rộng lớn của các dụ: màu sắc, hình dạng, bố cục) đối tượng giao diện con người đã được phát triển cho các ứng dụng web. • Tự điều khiển—Giao diện điều khiển nên tạo điều kiện cho chuyển động • Giảm độ trễ- WebApp nên sử dụng đa tác vụ bằng cách cho phép người sử sử dụng trong suốt WebApp, nhưng nó phải làm như vậy bằng cách thực dụng tiến hành với công việc nếu các hoạt động đã được hoàn thành. hiện quy ước đã được thiết lập cho các ứng dụng. • Tính học được- WebApp nên được thiết kế để giảm thiểu thời gian học • Hiệu quả—Thiết kế của WebApp và giao diện của nó nên tối ưu hóa hiệu tập, và một khi đã học, phải giảm thiểu sự học lại cần thiết khi WebApp quả công việc của người sử dụng, không phải của các kỹ sư thiết kế và xây được sử dụng lại. dựng nó hoặc của các môi trường client-server thực hiện điều đó. 12 12 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8 127 128
33. Nguyên tắc thiết kế giao diện-III Quy trình thiết kế giao diện-I • Duy trì tính toàn vẹn của sản phẩm công việc—Một sản phẩm công việc • Xem lại thông tin chứa trong các mô hình phân tích và tinh chỉnh khi cần (ví dụ: một biểu mẫu hoàn thành bởi người dùng, một danh sách chi tiết thiết. người dùng) cần được lưu trữ tự động để không bị mất khi có lỗi xảy ra. • Xây dựng một phác thảo sơ bộ giao diện bố cục WebApp. • Tính đọc được—Tất cả thông tin trình bày qua giao diện cần phải đọc • Map các mục tiêu sử dụng vào các hoạt động giao diện cụ thể. được bởi tất cả mọi người • Xác định một tập hợp các nhiệm vụ người dùng có liên quan đến từng • Theo dõi trạng thái—Lúc thích hợp, trạng thái của tương tác người dùng hành động. nên được theo dõi và lưu trữ để một người dùng có thể đăng xuất và sau • Lên kịch bản hình ảnh màn hình cho mỗi hành động giao diện. đó trở lại đúng giao diện mà người đó đã dời đi. • Tinh chỉnh giao diện bố cục và kịch bản sử dụng đầu vào từ thiết kế thẩm • Hiển thị điều hướng—A giao diện WebApp được thiết kế tốt cung cấp "sự mỹ. ảo tưởng rằng người sử dụng ở cùng một vị trí, với các công việc mang lại cho họ." These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 12 13 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 0 129 130 Xác định mục tiêu người dùng Quy trình thiết kế giao diện-II Menu bar • Xác định đối tượng giao diện người dùng được yêu cầu để thực hiện major functions các giao diện. Xây dựng biểu diễn thủ tục của sự tương tác của người List of user objectives graphic, logo, and company name dùng với giao diện. objective #1 objective #2 • Xây dựng một biểu diễn hành vi của giao diện. objective #3 • Mô tả bố cục giao diện cho mỗi trạng thái. objective #4 objective #5 • Tinh chỉnh và xem xét các mô hình thiết kế giao diện. graphic objective #n Home page text copy Navigation menu These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13 13 1 2 131 132
34. Thiết kế thẩm mỹ Chu kỳ đánh giá thiết kế • Không ngại khoảng trắng • Nhấn mạnh nội dung. • Tổ chức các yếu tố định dạng từ góc trái trên đến phải dưới. • Nhóm điều hướng, nội dung và chức năng địa lý trong trang. • Không mở rộng thành phần bất động của bạn với thanh cuộn. • Xem xét kích thước cửa sổ trình duyệt và độ phân giải khi thiết kế. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 13 13 These slides are designed to accompany Software Engineering: 3 4 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 133 134 Thiết kế phần mềm Khuôn mẫu thiết kế (Design Patterns) • Mỗi chúng ta đều đã trải qua vấn đề thiết kế và từng nghĩ: • Nội dung Liệu đã có ai phát triển một lời giải cho vấn đề này chưa? 1. Tổng quan thiết kế phần mềm – Điều gì sẽ xảy ra nếu đã có một cách tiêu chuẩn để mô tả một vấn 2. Thiết kế kiến trúc phần mềm đề (để bạn có thể nhìn nhận nó), và một phương pháp có tổ chức để trình bày lời giải cho vấn đề đó? 3. Thiết kế chi ết phần mềm • Khuôn mẫu thiết kế là một phương pháp có hệ thống để mô tả 4. Thiết kế giao diện người dùng các vấn đề và giải pháp, cho phép các cộng đồng công nghệ 5. Thiết kế mẫu phần mềm có thể nắm bắt kiến thức thiết kế theo cách có thể 6. Thiết kế giao diện cho ứng dụng WebApp tái sử dụng 13 135 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6 135 136
35. Khuôn mẫu thiết kế (Design Patterns) Khái niệm cơ bản • Ngữ cảnh cho phép người đọc hiểu được môi trường trong đó các vấn • Mỗi khuôn mẫu mô tả một vấn đề xảy ra hết lần này đến lần khác đề phát sinh và giải pháp nào có thể thích hợp trong môi trường đó. trong môi trường của chúng ta và sau đó mô tả cốt lõi của giải pháp • Một tập hợp các yêu cầu, bao gồm cả những hạn chế và khó khăn, hoạt cho vấn đề đó theo một cách mà bạn có thể sử dụng nó hàng triệu động như một hệ thống các lực lượng có ảnh hưởng tới cách: lần mà không bao giờ phải làm lại một việc lần thứ hai. – các vấn đề có thể được diễn giải trong ngữ cảnh của nó và Christopher Alexander, 1977 – giải pháp có thể được áp dụng hiệu quả như thế nào • “một quy tắc ba phần diễn tả một mối quan hệ giữa một ngữ cảnh, một vấn đề, và một giải pháp.” 13 13 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8 137 138 Khuôn mẫu hiệu quả Khuôn mẫu khả sinh (Generative patterns) • Coplien [Cop05] nêu đặc điểm cho một khuôn mẫu thiết kế hiệu quả theo các cách sau đây: • Khuôn mẫu khả sinh mô tả một khía cạnh quan trọng và có thể lặp lại – Nó giải quyết một vấn đề: Khuôn mẫu đưa ra giải pháp, không chỉ là quy tắc hay của một hệ thống và sau đó cung cấp cho chúng ta một cách xây dựng chiến lược trừu tượng. khía cạnh đó trong một hệ thống của các nguồn lực riêng biệt đối với – Nó là một khái niệm đã được chứng minh: Khuôn mẫu đưa ra giải pháp dựa trên từng ngữ cảnh. dữ liệu theo dõi, không phải là lý thuyết hay suy đoán. • Một tập hợp các khuôn mẫu thiết kế khả sinh có thể được dùng để sinh – Giải pháp không hiển nhiên: Rất nhiều kỹ thuật giải quyết vấn đề (chẳng hạn như mô hình hoặc các phương pháp thiết kế phần mềm) cố gắng đạt được giải pháp từ một ứng dụng hoặc một hệ thống dựa trên máy tính có kiến trúc cho quy tắc đầu tiên. Khuôn mẫu tốt nhất tạo ra một giải pháp cho một vấn đề một phép nó thích nghi với sự thay đổi. cách gián tiếp - một cách tiếp cận cần thiết cho những vấn đề khó nhất của thiết kế. – Nó mô tả một mối quan hệ: Khuôn mẫu không chỉ mô tả mô-đun mà mô tả kiến trúc và cơ chế sâu hơn của hệ thống. – Khuôn mẫu có một thành phần con người quan trọng (giảm thiểu ảnh hưởng của con người). Tất cả phần mềm cung cấp cho con người sự thoải mái hoặc chất lượng cuộc sống; khuôn mẫu tốt nhất hấp dẫn rõ ràng về cả thẩm mỹ và tiện ích. These slides are designed to accompany Software Engineering: 13 These slides are designed to accompany Software Engineering: 14 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0 139 140
36. Các loại khuôn mẫu Các loại khuôn mẫu • Architectural patterns Mẫu kiến trúc mô tả các vấn đề thiết kế trên diện rộng • Khuôn mẫu sáng tạo (Creational patterns) tập trung vào việc khởi tạo, sáng tác được giải quyết bằng cách tiếp cận cấu trúc. và biểu diễn của các đối tượng, ví dụ: • Data patterns Mẫu dữ liệu mô tả vấn đề dữ liệu và các giải pháp mô hình dữ – Abstract factory pattern liệu có thể được dùng để giải quyết vấn đề trên – Factory method pattern • Component patterns Mẫu thành phần (còn gọi là các mẫu thiết kế) nhằm đến • Khuôn mẫu cấu trúc tập trung vào các vấn đề và các giải pháp liên quan đến các vấn đề liên quan với việc phát triển các hệ thống con và các thành phần, cách các lớp và các đối tượng được tổ chức và tích hợp để xây dựng một cấu cách thức chúng giao tiếp với nhau, và vị trí của chúng trong một kiến trúc lớn trúc lớn hơn, ví dụ như: hơn – Adapter pattern • Interface design patterns. Mẫu thiết kế giao diện mô tả các vấn đề giao diện – Aggregate pattern người dùng thông thường và giải pháp bao gồm các đặc trưng cụ thể của • Khuôn mẫu hành vi giải quyết các vấn đề liên quan đến việc phân công trách người dùng cuối. nhiệm giữa các đối tượng và cách thức mà giao tiếp được thực hiện giữa các • WebApp patterns. Mẫu WebApp giải quyết tập hợp vấn đề có thể gặp phải khi đối tượng, ví dụ như: xây dựng Ứng dụng web và thường kết hợp nhiều mô hình khác cập đến ở – Chain of responsibility pattern: trên. – Command pattern: These slides are designed to accompany Software Engineering: 14 These slides are designed to accompany Software Engineering: 14 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2 141 142 Khung (frameworks) Mô tả một khuôn mẫu • Bản thân khuôn mẫu có thể không đủ để phát triển một thiết kế đầy đủ • Tên khuôn mẫu—mô tả bản chất của khuôn mẫu với một cái tên ngắn nhưng biểu cảm. – Trong một số trường hợp, cần thiết phải cung cấp một cơ sở hạ tầng thực • Vấn đề—Mô tả vấn đề mà khuôn mẫu giải quyết. hiện cụ thể, được gọi là một khung (framework) cho công việc thiết kế. • Động lực—cung cấp một ví dụ cho vấn đề • Ngữ cảnh—Mô tả môi trường mà vấn đề phát sinh, bao gồm miền ứng dụng – Có nghĩa là, bạn có thể chọn một “một kiến trúc nhỏ có thể tái sử dụng • Nguồn lực— liệt kê các hệ thống của các lực lượng có ảnh hưởng đến cách thức mà cung cấp cấu trúc chung và hành vi cho một họ các sự trừu tượng hóa các vấn đề được giải quyết; bao gồm một cuộc thảo luận về các giới hạn và ràng buộc phần mềm, cùng với một ngữ cảnh xác định sự cộng tác và sử dụng của phải được xem xét chúng trong một miền nhất định” [Amb98] • Giải pháp—cung cấp một mô tả chi tiết về các giải pháp đề xuất cho vấn đề • Một framework không phải là một khuôn mẫu kiến trúc, mà là một bộ khung • Mục đích—mô tả các khuôn mẫu và những gì nó làm với một tập hợp các “plug points” (còn được gọi là hooks hay slots) cho phép • Sự cộng tác—mô tả cách các khuôn mẫu khác đóng góp vào giải pháp nó thích ứng với một miền vấn đề xác định. • Hệ quả—mô tả những sự đánh đổi tiềm năng phải được xem xét khi khuôn mẫu được – Những “plug points” cho phép bạn tích hợp các lớp vấn đề cụ thể hoặc thực hiện và những hệ quả của việc sử dụng khuôn mẫu. chức năng trong các bộ khung. • Sự triển khai—xác định các vấn đề đặc biệt cần được xem xét khi thực hiện khuôn mẫu • Ứng dụng đã biết—cung cấp các ví dụ về cách sử dụng của các khuôn mẫu thiết kế trong ứng dụng thực tế. 14 • Khuôn mẫu liên quan—tham khảo chéo liên quan đến các khuôn mẫu thiết kế 14 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4 143 144
37. Ngôn ngữ khuôn mẫu Thiết kế dựa trên khuôn mẫu • Một ngôn ngữ khuôn mẫu bao gồm tập hợp các khuôn mẫu: • Một nhà thiết kế phần mềm bắt đầu với một mô hình yêu cầu (hoặc là – được mô tả sử dụng một bản mẫu tiêu chuẩn (phần 12.1.3) và rõ ràng hay ngụ ý) trình bày một thể hiện trừu tượng của hệ thống. – quan hệ với nhau để cho thấy cách các khuôn mẫu cộng tác để giải • Các mô hình yêu cầu mô tả các tập vấn đề, thiết lập ngữ cảnh, và xác quyết vấn đề trên một miền ứng dụng. định các hệ thống của các nguồn lực. • một ngôn ngữ khuôn mẫu tương tự như một sách hướng dẫn siêu văn • Sau đó bản để giải quyết vấn đề trong một miền ứng dụng cụ thể. – Các miền vấn đề được xem xét đầu tiên được mô tả theo thứ bậc, bắt đầu với các vấn đề thiết kế rộng liên quan đến miền và sau đó tinh chỉnh từng vấn đề rộng vào mức độ trừu tượng thấp hơn. 14 14 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6 145 146 Thiết kế dựa trên khuôn mẫu Suy nghĩ trong khuôn mẫu • Shalloway và Trott [Sha05] đề xuất các phương pháp sau đây cho phép một nhà thiết kế suy nghĩ trong mô hình: 1. Hãy chắc chắn rằng bạn hiểu được bức tranh lớn - ngữ cảnh trong đó phần mềm được xây dựng. Các yêu cầu mô hình phải truyền thông điệp này cho bạn. 2. Xem xét các bức tranh lớn, trích xuất các khuôn mẫu có mặt ở mức độ trừu tượng đó. 3. Bắt đầu thiết kế của bạn với khuôn mẫu "bức tranh lớn" mà thiết lập một ngữ cảnh hoặc bộ khung cho công việc thiết kế sau này. 4. "Làm việc hướng nội từ ngữ cảnh" [Sha05] tìm kiếm các khuôn mẫu ở các mức trừu tượng thấp hơn góp phần vào các giải pháp thiết kế. 5. Lặp lại các bước 1-4 cho đến khi thiết kế hoàn chỉnh được tạo ra. 6. Hoàn thiện thiết kế bằng cách thích ứng từng mô hình vào các chi tiết cụ thể của phần mềm bạn đang cố gắng xây dựng. 14 14 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8 147 148
38. Nhiệm vụ thiết kế-I Nhiệm vụ thiết kế-II • Kiểm tra các mô hình yêu cầu và phát triển một hệ thống phân cấp vấn đề. • Nếu vấn đề thiết kế giao diện người dùng đã được phân lập (điều này là • Xác định nếu một ngôn ngữ khuôn mẫu đáng tin cậy đã được phát triển cho hầu như luôn luôn như vậy), hãy tìm kiếm các giao diện người dùng miền vấn đề. trong kho mẫu thiết kế để tìm ra khuôn mẫu phù hợp. • Bắt đầu với một vấn đề lớn, xác định một hoặc nhiều khuôn mẫu kiến trúc có • Bất kể mức độ trừu tượng của nó, nếu một ngôn ngữ khuôn mẫu và / sẵn cho nó. hoặc kho khuôn mẫu hoặc khuôn mẫu riêng cho thấy sự hứa hẹn, hãy • Sử dụng sự cộng tác được cung cấp cho các khuôn mẫu kiến trúc, kiểm tra hệ so sánh các vấn đề cần giải quyết đối với các khuôn mẫu hiện có. thống phụ hoặc các vấn đề mức thành phần và tìm kiếm các khuôn mẫu thích hợp để giải quyết chúng. • Hãy chắc chắn để tinh chỉnh các thiết kế như là nó có nguồn gốc từ các • Lặp lại các bước từ 2 đến 5 cho đến khi tất cả các vấn đề lớn đã được giải khuôn mẫu sử dụng các tiêu chí chất lượng thiết kế như một hướng quyết. dẫn. 14 15 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0 149 150 Bảng sắp xếp khuôn mẫu Lỗi thiết kế thông thường • Không đủ thời gian được sử dụng để hiểu được vấn đề cơ bản, ngữ cảnh và các nguồn lực của mình, và như một hệ quả, bạn chọn một khuôn mẫu có vẻ đúng, nhưng không phù hợp với giải pháp được yêu cầu. • Một khi chọn sai khuôn mẫu, bạn không chịu nhìn ra vấn đề và sử dụng khuôn mẫu gượng ép. • Trong các trường hợp khác, các vấn đề có nguồn lực không được xem xét bởi các khuôn mẫu bạn đã chọn, dẫn đến kết quả nghèo nàn. • Đôi khi một khuôn mẫu được áp dụng quá thô thiển và sự thích nghi cần thiết cho không gian vấn đề của bạn không được thực hiện. 15 15 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2 151 152
39. Khuôn mẫu kiến trúc Kho khuôn mẫu • Ví dụ: mỗi nhà (và mọi phong cách kiến trúc đối với nhà ở) sử dụng • Có rất nhiều nguồn cho các khuôn mẫu thiết kế có sẵn trên web. Một một khuôn mẫu nhà bếp. số khuôn mẫu có thể được lấy từ các ngôn ngữ khuôn mẫu xuất bản • Khuôn mẫu nhà bếp và các khuôn mẫu mà nó cộng tác giải quyết các riêng, trong khi những cái khác đang có sẵn như là một phần của một vấn đề liên quan tới việc lưu trữ và chuẩn bị thức ăn, các công cụ cần cổng hoặc kho khuôn mẫu. thiết để thực hiện những nhiệm vụ, và các quy tắc cho vị trí của các • Một danh sách các kho khuôn mẫu được thể hiện trong mục 12.3 công cụ liên quan đến công việc trong phòng. Ngoài ra, các mô hình có thể giải quyết các vấn đề liên quan đến mặt bàn, chiếu sáng, công tắc tường, sàn nhà • Rõ ràng, có nhiều hơn một thiết kế cho một nhà bếp, thường quyết định bởi bối cảnh và hệ thống của lực lượng. Tuy nhiên, mỗi thiết kế có thể được hình thành trong bối cảnh của "giải pháp" được đề xuất bởi các khuôn mẫu nhà bếp. 15 15 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4 153 154 Khuôn mẫu mức thành phần Khuôn mẫu mức thành phần • Các khuôn mẫu thiết kế mức thành phần cung cấp một giải pháp đã • Sau khi đề ra các vấn đề phụ cần giải quyết, xem xét ngữ cảnh và hệ thống được chứng minh để giải quyết một hoặc nhiều vấn đề phụ phát sinh từ các lực lượng có ảnh hưởng đến các giải pháp. các mô hình yêu cầu. Trong nhiều trường hợp, các khuôn mẫu thiết kế • Kiểm tra các trường hợp sử dụng các yêu cầu mô hình thích hợp, các đặc của loại hình này tập trung vào một số yếu tố chức năng của một hệ điểm kỹ thuật cho một thiết bị SafeHome (ví dụ, một bộ cảm biến an ninh thống. hoặc camera) được sử dụng cho mục đích thông tin của người tiêu dùng. • Ví dụ, ứng dụng SafeHomeAssured.com phải giải quyết các vấn đề – Tuy nhiên, các thông tin khác có liên quan đến các đặc điểm kỹ thuật thiết kế phụ sau đây: Làm thế nào chúng ta có thể có được thông số kỹ (ví dụ, giá cả) có thể được sử dụng khi chức năng thương mại điện tử được chọn. thuật sản phẩm và các thông tin liên quan cho bất kỳ thiết bị SafeHome • Các giải pháp cho vấn đề phụ bao gồm một sự tìm kiếm. Kể từ khi tìm nào? kiếm trở thành vấn đề rất phổ biến, không có gì ngạc nhiên khi có rất nhiều các khuôn mẫu liên quan đến tìm kiếm. • Xem Phần 12.4 15 15 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6 155 156
40. Khuôn mẫu giao diện người dùng (UI Paerns) Khuôn mẫu WebApp • Giao diện người dùng tổng thể (Whole UI). Cung cấp hướng dẫn thiết kế cho các cấu trúc • Khuôn mẫu kiến trúc thông tin liên quan đến cấu trúc tổng thể của không gian thông tin, và cấp cao nhất và điều hướng trong suốt toàn bộ giao diện. những cách mà người dùng sẽ tương tác với thông tin. • Bố cục trang. Giải quyết các tổ chức chung của trang (cho các trang web) hay hiển thị màn • Khuôn mẫu điều hướng xác định cấu trúc liên kết chuyển hướng, chẳng hạn như hệ thống hình riêng biệt (cho các ứng dụng tương tác) phân cấp, vòng, tours, • Biểu mẫu và đầu vào. Xem xét nhiều kỹ thuật thiết kế cho việc hoàn thành đầu vào dạng • Khuôn mẫu tương tác đóng góp vào việc thiết kế giao diện người dùng. Các khuôn mẫu loại biểu mẫu. này chỉ ra cách giao diện người dùng thông báo về hệ quả của một hành động cụ thể; làm • Bảng. Cung cấp hướng dẫn thiết kế cho việc tạo và xử lý dữ liệu dạng bảng dưới mọi dạng. thế nào một người dùng mở rộng nội dung dựa trên việc sử dụng ngữ cảnh và mong muốn • Xử lý dữ liệu trực tiếp. Address data editing, modification, and transformation. của người dùng; làm thế nào để mô tả tốt nhất đích đến đằng sau một liên kết; làm thế nào • Điều hướng. Hỗ trợ người dùng định hướng xuyên suốt menu phân cấp, các trang web và để thông báo cho người dùng về tình trạng của một tương tác đang thực hiện, và các vấn đề màn hình hiển thị tương tác. liên quan đến giao diện. • Tìm kiếm. Cho phép tính năng tìm kiếm nội dung cụ thể thông qua các thông tin được duy • Khuôn mẫu trình diễn hỗ trợ trong việc trình bày các nội dung cho người sử dụng thông qua trì trong một trang Web hoặc được lưu trữ trong cơ sở dữ liệu có thể truy cập thông qua một giao diện. Các khuôn mẫu loại này giải quyết vấn đề tổ chức các chức năng điều khiển giao ứng dụng tương tác diện người dùng cho khả năng sử dụng tốt hơn; vấn đề hiển thị các mối quan hệ giữa một • Các phần tử trang. Thực hiện các phần tử cụ thể của một trang web hoặc màn hình hiển thị. hành động giao diện và các đối tượng nội dung nó ảnh hưởng, và vấn đề thiết lập hệ thống • Thương mại điện tử. Tùy vào các trang web, các mô hình triển khai các yếu tố định kỳ của phân cấp nội dung hiệu quả. các ứng dụng thương mại điện tử. • Khuôn mẫu chức năng xác định các quy trình công việc, hành vi, xử lý, truyền thông, và các yếu tố khác trong một thuật toán WebApp. 15 15 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8 157 158 Thiết kế mức độ chi tiết Thiết kế mức độ chi tiết • Khi một vấn đề liên quan đến vấn đề "bức tranh lớn", cố gắng phát • Khuôn mẫu kiến trúc. Mức độ trừu tượng này thường sẽ liên quan đến các triển các giải pháp (và sử dụng các khuôn mẫu có liên quan) tập trung khuôn mẫu xác định cấu trúc tổng thể của WebApp, chỉ ra các mối quan hệ vào bức tranh lớn. giữa các thành phần khác nhau, và xác định các quy tắc để xác định mối quan • Ngược lại, khi sự tập trung là rất hẹp (ví dụ, duy nhất chọn một mục từ hệ giữa các yếu tố (các trang, gói, thành phần, hệ thống con) của kiến trúc. • Khuôn mẫu thiết kế. Những khuôn mẫu này chỉ ra một yếu tố cụ thể của thiết một tập hợp nhỏ của năm mặt hàng hoặc ít hơn), các giải pháp (và các kế như một tập hợp của các thành phần để giải quyết một số vấn đề thiết kế, khuôn mẫu tương ứng) có mục tiêu khá hẹp. mối quan hệ giữa các yếu tố trên một trang, hoặc các cơ chế ảnh hưởng đến • Xét về mức độ chi tiết, khuôn mẫu có thể được mô tả theo các mức giao tiếp giữa các thành phần. Một ví dụ có thể là khuôn mẫu Broadsheet cho sau: cách bố trí của một trang chủ WebApp. • Khuôn mẫu thành phần. Mức độ trừu tượng này liên quan đến các yếu tố quy mô nhỏ lẻ của WebApp. Các ví dụ bao gồm các yếu tố tương tác cá nhân, các mục chuyển hướng, hoặc các yếu tố chức năng. 15 16 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0 159 160
41. Thiết kế phần mềm Thiết kế ứng dụng WebApp “Có hai phương pháp thiết kế cơ bản: ý tưởng nghệ thuật để thể hiện • Nội dung bản thân và ý tưởng kỹ thuật để giải quyết vấn đề cho khách hàng.” 1. Tổng quan thiết kế phần mềm Jakob Nielsen 2. Thiết kế kiến trúc phần mềm • Khi nào cần nhấn mạnh thiết kế WebApp 3. Thiết kế chi ết phần mềm – Khi các nội dung và chức năng rất phức tạp 4. Thiết kế giao diện người dùng – Khi kích thước của WebApp bao gồm hàng trăm đối tượng, hàm và 5. Thiết kế mẫu lớp phân tích 6. Thiết kế giao diện cho ứng dụng WebApp – Khi sự thành công của WebApp sẽ tác động trực tiếp tới sự thành công của doanh nghiệp 16 161 These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2 161 162 Thiết kế và chất lượng WebApp Chất lượng với người dùng • An ninh • Thời gian – Trang Web thay đổi bao nhiêu sau khi nâng cấp – Ngăn ngừa tấn công từ bên ngoài – Các phần thay đổi có được highlight? – Loại trừ truy cập trái phép • Cấu trúc – Đảm bảo sự riêng tư của người dùng/khách hàng – Các bộ phận của website kết nối với nhau như thế nào? • Khả dụng – Mọi liên kết trong/ngoài trang web có hoạt động? – Ước lượng được tỉ lệ thời gian WebApp khả dụng – Tất cả các hình ảnh có được hiển thị? • Khả năng mở rộng – Có phần nào của website không được kết nối? – WebApp có thể xử lý sự thay đổi đáng kể trong khối lượng người • Nội dung dùng/giao dịch – Nội dung các trang quan trọng có khớp với thông tin tại đó? • Thời gian ra thị trường – Các từ khóa có tồn tại liên tục với các trang thay đổi nhanh? – Các trang quan trọng có duy trì được chất lượng nội dung? – Có thể tự động tạo các trang HTML? 16 16 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 3 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 4 163 164
42. Chất lượng với người dùng Mục tiêu thiết kế • Độ chính xác, nhất quán • Nhất quán – Bản sao của ngày hôm qua có giống hôm nay? – Nội dung cần được xây dựng nhất quán – Dữ liệu được trình bày chính xác, đầy đủ? – Thiết kế đồ họa nên có một các nhìn nhất quán trên các phần của • Thời gian đáp ứng và độ trễ ứng dụng web – Server web có đáp ứng yêu cầu trình duyệt trong thời gian nhất định? – Thiết kế kiến trúc cần đưa ra mẫu dẫn đến một cấu trúc siêu – Trong thương mại điện tử, làm sao đảm bảo thời gian đáp ứng sau khi phương tiện phù hợp gửi một lệnh – Thiết kế giao diện nên xác định các tương tác, chuyển hướng và – Có phần nào của web quá chậm, khiến người dùng không tiếp tục sử hiển thị phù hợp dụng? – Cơ chế điều hướng nên sử dụng nhất quán trên tất cả các yếu tố • Hiệu năng của ứng dụng – Kết nối có đủ nhanh? – Hiệu suất thay đổi như thế nào theo thời gian trong ngày? – Hiệu suất có đáp ứng được các ứng dụng thương mại điện tử 16 16 These slides are designed to accompany Software Engineering: These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 5 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 6 165 166 Mục tiêu thiết kế Tháp thiết kế user • Identity – Thiết lập một “Identity-bản sắc" phù hợp với mục đích nghiệp vụ • Robustness Interface – Người dùng kỳ vọng nội dung và chức năng mạnh mẽ có liên quan design đến nhu cầu của người sử dụng Aesthetic design • Navigability Content design – Được thiết kế một cách trực quan và dễ dự đoán Navigation design • Visual appeal – Nhìn và cảm nhận về nội dung, bố trí giao diện, phối hợp màu sắc, sự Architecture design cân bằng của văn bản, đồ họa và các phương tiện truyền thông khác, Component design cơ chế điều hướng đến người dùng cuối cùng • Compatibility technology – Với tất cả các môi trường và cấu hình phù hợp These slides are designed to accompany Software Engineering: 16 These slides are designed to accompany Software Engineering: 16 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 7 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 8 167 168
43. Thiết kế giao diện Giao diện WebApp hiệu quả • Giao diện cần • Bruce Tognozzi [TOG01] đề nghị – Cung cấp dấu hiệu truy cập – Giao diện hiệu quả cần trực quan, người sử dụng có thể nhanh – Thông báo cho người sử dụng vị trí của họ trong nội dung phân chóng xem các lựa chọn, nắm bắt xem làm thế nào để đạt mục tiêu cấp và làm việc • Giao diện luôn giúp người dùng hiểu tùy chọn hiện tại của họ – Người sử dụng không liên quan đến hoạt động bên trong của hệ – Những chức năng nào khả dụng thống. Công việc thực hiện xuyên suốt và thường xuyên được lưu, – Những liên kết nào còn sử dụng được với các tùy chọn đầy đủ để có thể hoàn tác. – Những nội dung nào có liên quan – Thực hiện công việc một cách tối đa, trong khi nhận thông tin ít • Giao diện cần tạo điều kiện chuyển hướng nhất từ người dùng – Cung cấp một “bản đồ” dễ hiểu để người dùng có thể chuyển hướng trong ứng dụng These slides are designed to accompany Software Engineering: 16 These slides are designed to accompany Software Engineering: 17 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 9 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0 169 170 Nguyên lý thiết kế giao diện I Nguyên lý thiết kế giao diện II • Tiên đoán — WebApp nên thiết kế để dự kiến được hành động tiếp theo • Tập trung — Giao diện và nội dung nên tập trung vào các tác vụ người của người dùng dùng đang sử dụng • Truyền thông — Giao diện cần truyền thông các trạng thái của các hoạt • Luật Fitt — “Thời gian đạt được mục tiêu là hàm của khoảng cách và kích động của người dùng thước mục tiêu” • Nhất quán — Sử dụng công cụ điều hướng, menu, biểu tượng • Đối tượng giao diện người dùng — Một thư viện lớn của các đối tượng • Kiểm soát quyền tự trị — Giao diện tạo điều kiện cho người dùng di giao diện tái sử dụng, phát triển cho WebApp chuyển trong ứng dụng, theo các quy ước điều hướng được quy định trong • Giảm độ trễ — Ứng dụng thực hiện đa nhiệm tuy nhiên vẫn cho phép ứng dụng người dùng thực hiện công việc liên tục • Hiệu quả — Thiết kế của WebApp và giao diện nên được tối ưu hóa hiệu • Thời gian học — Giao diện nên thiết kế giảm thiểu thời gian học, và sau quả làm việc của người dùng, chứ không nên tối ưu hóa theo công việc khi học để giảm thiểu thời gian học lại khi được truy cập lại. của kỹ sư hay môi trường thực thi These slides are designed to accompany Software Engineering: 17 These slides are designed to accompany Software Engineering: 17 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 1 A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 2 171 172