Thiết kế phần mềm - Tổng quan

PGS.TS. Huỳnh Xuân Hiệp BÔ ̣ MÔN CÔNG NGHÊ ̣ PHẦN MỀM Khoa CNTT& TT – Trường ĐH Cần Thơ 1  Tổng quan  Thiết kế dữ liệu/lớp  Thiết kế kiến trúc  Thiết kế giao diện  Thiết kế thành phần  Thiết kế hướng mẫu  Thiết kế hướng web  Thiết kế hướng dịch vụ 2 [1] IBM Rational Software, DEV496 Mastering IBM Rational Software Architect – Acme Case Study (Part No. 800-027176-000), IBM Rational University, 2005. [2] IBM Rational Software, DEV496 Mastering IBM Rational Software Architect – Student Exercise Guide (Part No. 800-027175-000), IBM Rational University, 2005. [3] Julia H. Allen et al., Software Security Engineering, Pearson Education, 2008. [4] Barry W. Boehm, Software Engineering, IEEE Computer Society - Wiley, 2007. [5] Alphonse Carlier, Le développement du logiciel, Hermes, 1995. [6] Scott E. Donaldson and Stanley G. Siegel, Successful Software Development (2nd edition), Prentice Hall, 2000. [7] Christopher Harris-Jones, Knowledge Based Systems Methods: A Practitioners’ Guide, Prentice Hall, 1995. [8] IEEE, Guide to the Software Engineering Body of Knowledge - SWEBOK®, IEEE Computer Society, 2004. [9] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminilogy, IEEE, 1990. [10] Stephen H. Kan, Metrics and Models in Software Quality Engineering, Addison-Wesley, 2002. [11] Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP, Addison Wesley, 2003. [12] Philippe Kruchten, The Rational Unified Process: An Introduction (2nd, 3rd editions), Addison Wesley, 2000, 2003. [13] Craig Larman, Agile and Iterative Development: A Manager's Guide, Addison Wesley, 2003. [14] Timothy C. Lethbridge and Robert Laganière, Obiect-Oriented Software Engineering: Practical Software Development Using UML and Java, McGraw-Hill, 2002. 3 [15] Raymond J. Madachy, Software Process Dynamics, IEEE Press – Wiley, 2008. [16] Mario E. Moreira, Software Configuration Management Implementation Roadmap, Wiley, 2004. [17] Rational Software White Paper, Reaching CMM Levels 2 and 3 with the Rational Unified Process, Rational Software Corporation, 2000. [18] John W. Rittinghouse, Managing Software Deliverables: A Software Development Management Methodology, Digital Press – Elsevier, 2004. [19] Robert E. Park, Software Size Measurement: A Framework for Counting Source Statements, Technical Report CMU/SEI-92-TR-020 ESC-TR-92-020, 1996. [20] Roger S. Pressman, Software Engineering: A Practitioner’s Approach (5th, 6th, 7th editions), McGraw-Hill, 2003, 2005, 2009. [21] Stephen R. Schach, Object-Oriented and Classical Software Engineering (5th,6th,7th, 8th editions), McGraw-Hill, 2002, 2005, 2007, 2011. [23] Ian Sommerville, Software Engineering (6th,8th editions), Addison-Wesley, 2001, 2006. [24] Jeff Tian, Software Quality Engineering: Testing Quality Assurance and Quantifiable Improvement, IEEE Computer Society - Wiley, 2005. [25] Hans van Vliet, Software Engineering: Principals and Practice (2nd edition), Wiley, 2000. [26] MK.PUB, Design Patterns, Nhà xuất bản Phương Đông, 2005. [27] [28] [29] 4 TỔNG QUAN (Overview) 5  Thiết kế phần mềm bao gồm tập hợp các nguyên tắc, khái niệm và thực hành dẫn đến sự phát triển của một hệ thống chất lượng cao hoặc sản phẩm.  Nguyên tắc thiết kế thiết lập một triết lý quan trọng mà sẽ hướng dẫn người thiết kế trong công việc thiết kế phải thực hiện.  Khái niệm thiết kế phải được hiểu trước khi cơ chế thực hành thiết kế được áp dụng.  Việc thực hành thiết kế dẫn đến việc tạo ra các đại diện khác nhau của phần mềm.  Thiết kế đóng vai trò then chốt cho sự thành công của công nghệ phần mềm. 6  Mục đích của thiết kế là tạo ra một mô hình hoặc một miêu tả thể hiện độ vững chắc, tính thương phẩm và sự thích thú. Để thực hiện điều này, cần phải thực hành đa dạng hóa (diversification) và sau đó hội tụ (convergence). 7  Quyết định thiết kế với các thiết kế thay thế từ những lựa chọn khác nhau: ◦ Đường thẳng biểu diễn cho các tùy chọn ◦ Đường đậm nét là tập hợp các quyết định được đưa ra 8  Thiết kế phần mềm nằm ở lõi kỹ thuật (technical kernel) của công nghệ phần mềm và được áp dụng không phụ thuộc vào mô hình quy trình phần mềm được sử dụng.  Bắt đầu từ ngay khi yêu cầu phần mềm đã được phân tích và mô hình hóa, thiết kế phần mềm là hành động công nghệ phần mềm cuối cùng trong hoạt động mô hình hóa (modeling) và đặt ra giai đoạn xây dựng (sinh mã lệnh và kiểm thử). 9  Mỗi một phần tử trong mô hình yêu cầu (requirements model) cung cấp thông tin đó là cần thiết để tạo ra bốn mô hình thiết kế (design model) cần thiết cho một đặc tả thiết kế hoàn chỉnh.  4 mô hình thiết kế: ◦ Thiết kế dữ liệu/lớp (data/class design) ◦ Thiết kế kiến trúc (architectural design) ◦ Thiết kế giao diện (interface design) ◦ Thiết kế thành phần (component design) 10 11 12  Thiết kế dữ liệu/lớp chuyển đổi các mô hình lớp (class models) vào thiết kế lớp một cách rõ ràng và các cấu trúc dữ liệu cần thiết theo yêu cầu để cài đặt phần mềm.  Các đối tượng (objects) và các mối quan hệ (relationships) được xác định trong sơ đồ CRC (class- responsibility-collaboration) và nội dung dữ liệu chi tiết được mô tả bởi các thuộc tính lớp và ký hiệu khác tạo cơ sở cho các hoạt động thiết kế dữ liệu.  Một phần của thiết kế lớp có thể được kết hợp với thiết kế của kiến trúc phần mềm.  Thiết kế lớp chi tiết hơn được thực hiện khi thực hiện thiết kế mỗi thành phần của phần mềm. 13  Thiết kế kiến ​​trúc xác định mối quan hệ giữa các phần tử cấu trúc chính của phần mềm.  Các phong cách kiến ​​trúc (architectural styles) và các mẫu thiết kế (design patterns) có thể được sử dụng để đạt được các yêu cầu quy định cho hệ thống, và những rang buộc ảnh hưởng đến cách thức mà kiến trúc có thể được thực hiện.  Thiết kế kiến ​​trúc miêu tả khung của một hệ thống dựa trên máy tính lấy được từ mô hình yêu cầu. 14  Thiết kế giao diện mô tả như thế nào phần mềm giao tiếp với: ◦ Các hệ thống có tương tác ◦ Con người người sử dụng  Một giao diện có nghĩa là một luồng thông tin (ví dụ, dữ liệu và/hoặc kiểm soát) và một loại hình cụ thể của hành vi  Các kịch bản sử dụng (usage scenarios) và mô hình hành vi (behavioral model) cung cấp nhiều thông tin cần thiết cho thiết kế giao diện 15  Thiết kế thành phần chuyển đổi các phần tử cấu trúc của kiến trúc phần mềm thành một mô tả về thủ tục của các thành phần phần mềm  Thông tin thu được từ các mô hình dựa trên lớp (class- based model), các mô hình luồng (flow model), và các mô hình hành vi (behavioral model) phục vụ như là cơ sở để thiết kế thành phần 16  Trong quá trình thiết kế sẽ hình thành các quyết định mà cuối cùng sẽ ảnh hưởng đến sự thành công của việc xây dựng phần mềm và thực sự quan trọng đó là sự dễ dàng để phần mềm có thể được bảo trì.  Tầm quan trọng của thiết kế phần mềm có thể được ghi với một từ duy nhất: chất lượng.  Thiết kế là nơi mà chất lượng được nuôi dưỡng trong công nghệ phần mềm.  Thiết kế cung cấp các mô tả của phần mềm để có thể đánh giá được về chất lượng. 17  Thiết kế là cách duy nhất mà ta có thể thông dịch chính xác yêu cầu của các bên liên quan vào một sản phẩm phần mềm hoàn chỉnh hoặc hệ thống.  Thiết kế phần mềm phục vụ như là nền tảng cho tất cả các hoạt động công nghệ phần mềm và hỗ trợ phần mềm kèm theo.  Không có thiết kế, ta sẽ có nguy cơ xây dựng một hệ thống không ổn định: ◦ thất bại khi các thay đổi nhỏ được thực hiện ◦ khó khăn để đánh giá chất lượng mặc dù đã đến thời gian cuối của tiến trình phần mềm (khi thời gian còn ngắn và đã sử dụng nhiều kinh phí) 18  Thiết kế phần mềm là một tiến trình lặp đi lặp lại (iterative process) thông qua đó yêu cầu được chuyển thành một "kế hoạch chi tiết" để xây dựng phần mềm.  Kế hoạch chi tiết mô tả một cái nhìn toàn diện của phần mềm: ◦ Các thiết kế được thể hiện ở một mức độ trừu tượng cao-một mức độ mà có thể được truy vết trực tiếp đến mục tiêu cụ thể của hệ thống và dữ liệu chi tiết hơn, chức năng, và các yêu cầu về hành vi. ◦ Với việc lặp đi lặp lại của thiết kế, các tinh chỉnh tiếp theo dẫn đến việc mô tả thiết kế ở các mức trừu tượng thấp hơn nhiều. Các tinh chỉnh này vẫn có thể được truy vế từ yêu cầu, nhưng kết nối là tinh tế hơn. 19  Một thiết kế nên thể hiện một kiến ​​trúc mà ◦ đã được tạo ra bằng cách sử dụng phong cách kiến ​​trúc hoặc mẫu dễ nhận biết ◦ bao gồm các thành phần mà thể hiện các đặc tính thiết kế tốt ◦ có thể được cài đặt theo một cách thức tiến hóa, do đó sẽ tạo điều kiện cho việc cài đặt và kiểm thử  Một thiết kế nên được mô đun hóa, có nghĩa là các phần mềm nên được phân chia thành các phần tử hoặc hệ thống con một cách hợp lý  Một thiết kế cần chứa các biểu diễn khác nhau của dữ liệu, kiến trúc, giao diện và thành phần 20  Một thiết kế nên dẫn đến các cấu trúc dữ liệu phù hợp cho các lớp để được cài đặt và được rút ra từ các mẫu dữ liệu dễ nhận biết  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  Một thiết kế nên dẫn đến giao diện là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 21  Một thiết kế nên được bắt nguồn bằng sử dụng một phương pháp lặp được dẫn dắt bởi thông tin thu được trong quá trình phân tích yêu cầu phần mềm  Một thiết kế cần được thể hiện bằng cách sử dụng ký hiệu truyền tải có hiệu quả ý nghĩa của nó 22  Quá trình thiết kế không nên bị “bó hẹp tầm nhìn"  Thiết kế phải lần vết được đến mô hình phân tích  Thiết kế không được mất thời gian vào những cái đã có  Thiết kế nên "giảm thiểu khoảng cách trí tuệ" giữa phần mềm và các vấn đề như nó đã tồn tại trong thế giới thực  Thiết kế phải thể hiện tính thống nhất và tích hợp/toàn vẹn  Thiết kế phải được cấu trúc để thích ứng với sự thay đổi 23  Việc thiết kế phải được cấu trúc để làm giảm nhẹ nhàng, ngay cả khi đang gặp phải dữ liệu, sự kiện hoặc điều kiện hoạt động bất thường  Thiết kế không phải là viết mã lệnh, viết mã lệnh không phải là thiết kế  Thiết kế phải được đánh giá về chất lượng như khi nó được tạo ra, không phải trên thực tế diễn ra sau đó  Thiết kế phải được xem xét để giảm thiểu lỗi khái niệm (ngữ nghĩa) 24  Tính năng (functionality) được thẩm định bằng cách đánh giá một tập hợp các tính năng và các khả năng của chương trình, mức độ tổng quát của các hàm đã được phân phối và mức độ an toàn của toàn bộ hệ thống  Khả dụng (usability) được đánh giá bằng cách xem xét các nhân tố con người, thẩm mỹ tổng thể, nhất quán, và tài liệu  Độ tin cậy (reliability) được đánh giá bằng cách đo tần số và mức độ nghiêm trọng của thất bại, tính chính xác của kết quả đầu ra, giá trị mean-time-to-failure (MTTF), khả năng phục hồi từ thất bại, và khả năng dự đoán của chương trình 25  Hiệu suất (performance) được đo bằng cách xem xét tốc độ xử lý, thời gian đáp ứng, tiêu thụ tài nguyên, băng thông, và hiệu quả  Tính năng hỗ trợ (supportability) kết hợp các khả năng mở rộng các chương trình (tính mở rộng), khả năng thích ứng, khả năng phục vụ (ba thuộc tính này đại diện cho một thuộc tính phổ biến hơn là bảo trì) và ngoài ra còn có khả năng kiểm tra, khả năng tương thích, khả năng cấu hình (khả năng tổ chức và kiểm soát các yếu tố của cấu hình phần mềm), tính dễ dàng mà một hệ thống có thể được cài đặt và tính dễ dàng mà vấn đề có thể được bản địa hóa 26  Trừu tượng hóa (abstraction) - Mức độ trừu tượng hóa (levels of abstraction) - Trừu tượng hóa thu ̉ tục (procedural abstraction) - Trừu tượng hóa dữ liệu (data abstraction) - Trừu tượng hóa điều khiển (control abstraction)  Tinh chỉnh (refinement)  Mô đun hóa (modularity): phân tích được (decomposability), tổng hợp (composability), dễ hiểu (understandability), liên tục (continuity), bảo vệ (protection) 27 28  Kiến trúc phần mềm (software architecture) ◦ Đặc tính cấu trúc (structural properties) ◦ Đặc tính hàm ngoài (extra-functional properties) ◦ Họ các hê ̣ thống liên quan (families of related systems)  Kiến trúc phần mềm ◦ Mô hình cấu trúc (structural models) ◦ Mô hình khung (framework models) ◦ Mô hình động (dynamic models) ◦ Mô hình tiến trình (process models) ◦ Mô hình chức năng (functional models) ◦ Ngôn ngữ mô tả kiến trúc (architectural description language - ADLs) 29  Mẫu thiết kế (design patterns) ◦ Được áp dụng cho công việc hiện tại ◦ Có thể được tái sử dụng (tiết kiệm thời gian thiết kế) ◦ Có thể phục vụ như một hướng dẫn để phát triển một cách tương tự, nhưng chức năng hoặc cấu trúc khác với mẫu  Tách mối quan tâm (separation of concerns)  Thủ tục phần mềm (software procedure, program structure)  Thông tin ẩn (information hiding) 30  Độc lập chức năng (functional independence) ◦ Gắn kết (cohesion): coincidentally cohesive, logically cohesive, temporal cohesion, procedural cohesion, communicational cohesion ◦ Nối kết (coupling): data coupling, stamp coupling, control coupling, external coupling, common coupling, content coupling  Khía cạnh (aspect)  Tái cấu trúc (refactoring) 31 32  Cần thiết kế các lớp (design classes) để tinh chỉnh các lớp trong giai đoạn phân tích bằng cách cung cấp thiết kế chi tiết mà sẽ cho phép các lớp được cài đặt, và cài đặt một cơ sở hạ tầng phần mềm hỗ trợ các giải pháp nghiệp vụ.  Năm loại khác nhau của các lớp thiết kế mà từng dạng đại diện cho một tầng khác nhau của thiết kế kiến ​​trúc ◦ Lớp giao diện người dùng (user interface class) ◦ Lớp lĩnh vực nghiệp vụ (business domain class) ◦ Lớp tiến trình (process class) ◦ Lớp kéo dài (persistent class) ◦ Lớp hệ thống (system class) 33  4 đặc tính của một thiết kế tốt ◦ Hoàn chỉnh và đầy đủ (complete and sufficient) ◦ Nguyên thủy (primitiveness) ◦ Gắn kết cao (high cohesion) ◦ Nối kết thấp (low coupling) 34 35  Mô hình thiết kế có thể được xem trong hai chiều khác nhau: ◦ Chiều tiến trình (process dimension) ◦ Chiều trừu tượng hóa (abstraction dimension)  Chiều quá trình chỉ ra sự tiến hóa của mô hình thiết kế như là công việc thiết kế được thực thi như là một phần của tiến trình phần mềm  Chiều trừu tượng hóa đại diện cho mức độ chi tiết của mỗi phần tử trong mô hình phân tích được chuyển đổi sang một thiết kế tương đương và sau đó được tinh chỉnh một cách lặp đi lặp lại 36 37 38 39 40 THIẾT KẾ DỮ LIỆU/LỚP (Data/Class Design) 41  Phân tích yêu cầu (requirements analysis) cho ra kết quả là các đặc tả đặc điểm hoạt động của phần mềm, chỉ ra giao diện phần mềm với các phần tử của hệ thống khác, và thiết lập các ràng buộc mà phần mềm phải đáp ứng.  Phân tích yêu cầu cho phép bạn (kỹ sư phần mềm, chuyên gia phân tích hoặc xây dựng mô hình) để giải thích về các yêu cầu cơ bản được thiết lập trong các nhiệm vụ thành lập (inception), gợi mở (elicitation), và đàm phán (negotiation) là một phần của kỹ thuật yêu cầu (requirements engineering). 42  Mô hình hóa các yêu cầu (requirements analysis) tạo ra các dạng mô hình sau đây: ◦ Mô hình dựa trên kịch bản (scenario-based model) ◦ Mô hình dữ liệu (data model) ◦ Mô hình hướng lớp (class-oriented model) ◦ Mô hình hướng luồng (flow-oriented model) ◦ Mô hình hành vi (behavioral model)  Mục tiêu (objective) và triết lý (philosophy) ◦ Cái gì (what)? ◦ Như thế nào (how)?  Phân tích lĩnh vực (domain analysis)  Phát triển các trường hợp sử dụng (use case) 43 44 45  Hệ thống con (subsystem)  Thành phần (component)  Mô đun (modules)  Mô hình nên tập trung vào các yêu cầu mà có thể nhìn thấy trong vấn đề hoặc lĩnh vực nghiệp vụ. Mức độ trừu tượng cần được tương đối cao  Mỗi phần tử của mô hình yêu cầu nên thêm vào một sự hiểu biết tổng thể các yêu cầu phần mềm và cung cấp cái nhìn sâu sắc vào lĩnh vực thông tin, chức năng, và hành vi của hệ thống.  Trì hoãn xem xét của cơ sở hạ tầng và các mô hình không có chức năng khác cho đến khi thiết kế. 46  Giảm thiểu các nối kết (coupling) trên toàn hệ thống 47  Hãy chắc chắn rằng mô hình yêu cầu cung cấp giá trị cho tất cả các bên liên quan (stakeholders).  Giữ mô hình đơn giản như nó có thể được. 48 49 50 51  Unified Modeling Language - UML  Phát triển các sơ đồ (diagram) UML hỗ trợ các trường hợp sử dụng (use case): ◦ Sơ đồ hoạt động (activity diagram) ◦ Sơ đồ theo làn (swimlane diagram) 52 53 54  Các khái niệm của mô hình hóa dữ liệu (data modeling): ◦ Đối tượng dữ liệu (data objects) ◦ Thuộc tính dữ liệu (data attributes) ◦ Mối quan hệ (relationships) 55 56 57  Xác định các lớp phân tích (identifying analysis classes) ◦ Thực thể ngoài (external entities) ◦ Đồ vật (things) ◦ Xuất hiện hay sự kiện (occurrences or events) ◦ Vai trò (roles) ◦ Đơn vị tổ chức (organizational units) ◦ Vị trí (places) ◦ Cấu trúc (structures) 58  Xác định các thuộc tính (specifying attributes)  Định nghĩa các phương thức (defining operations)  Mô hình hóa CRC (class-responsibility-collaboration modeling)  Kết hợp và phụ thuộc (associations and dependencies)  Phân tích gói (analysis packages) 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86  Các chiến lược mô hình hóa yêu cầu (requirements modeling strategies)  Mô hình hóa hướng luồng (flow-oriented modeling) ◦ Tạo ra một mô hình luồng dữ liệu (data flow model) ◦ Tạo ra một mô hình kiểm soát luồng (control flow model) ◦ Đặc tả kiểm soát (control specification) ◦ Đặc tả tiến trình (process specification)  Tạo ra một mô hình hành vi (behavioral model) ◦ Xác định các sự kiện (events) với các trường hợp sử dụng ◦ Biểu diễn các trạng thái (states) ◦ Các sơ đồ tuần tự (sequence diagram) 87  Mẫu (patterns) cho mô hình hóa yêu cầu  Mô hình hóa yêu cầu hướng web (webapps) ◦ Phân tích bao nhiêu thì vừa đủ? ◦ Đầu vào (input) mô hình hóa yêu cầu ◦ Đâu ra (output) mô hình hóa yêu cầu ◦ Mô hình nội dung (content model) cho webapps ◦ Mô hình tương tác (interaction model) cho webapps ◦ Mô hình chức năng (functional model) ◦ Mô hình điều hướng (navigation model) ◦ Mô hình cấu hình (configuration model) 88 89 90 91 92 93 94 95 96 97 98 99 THIẾT KẾ KIẾN TRÚC (Architectural Design) 100  Kiến trúc phần mềm (software architecture) của một chương trình hoặc hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống, trong đó bao gồm các thành phần phần mềm, các thuộc tính bên ngoài có thể nhìn thấy của những thành phần này và các mối quan hệ giữa chúng  Có một sự khác biệt rõ rệt về thuật ngữ giữa kiến trúc và thiết kế: một thiết kế là một thể hiện của một kiến trúc tương tự như một đối tượng là một thể hiện của một lớp. 101  Kiến trúc không phải là phần mềm hoạt động. Thay vào đó, nó là một thể hiện cho phép ta: ◦ phân tích hiệu quả của thiết kế trong việc đáp ứng các yêu cầu đã được đề ra ◦ xem xét lựa chọn thay thế kiến trúc ở một giai đoạn khi thực hiện thay đổi thiết kế vẫn còn tương đối dễ dàng ◦ giảm thiểu rủi ro liên quan đến việc xây dựng phần mềm 102  Biểu diễn của kiến trúc phần mềm có khả năng cho phép thông tin liên lạc 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 một hệ thống dựa trên máy tính.  Các kiến ​​trúc làm nổi bật lên các quyết định thiết kế ban đầu mà sẽ có một 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à quan trọng là trên thành công cuối cùng của hệ thống như một thực thể hoạt động.  Kiến trúc "tạo thành một mô hình tương đối nhỏ, có khả năng nắm bắt tri thức về cách thức mà một hệ thống được cấu trúc như thế nào và thành phần của nó làm việc cùng nhau ra sao" 103  Mô hình thiết kế kiến trúc và các mẫu kiến trúc chứa bên trong nó có thể đổi qua lại lẫn nhau: ◦ Thể loại (genres) ◦ Phong cách (styles) ◦ Mẫu (patterns)  Có thể được áp dụng cho việc thiết kế các hệ thống khác và đại diện cho một tập hợp các trừu tượng hóa cho phép các kỹ sư phần mềm để mô tả kiến trúc theo cách thức dự đoán. 104  Mô tả kiến trúc (architectural descriptions)  Quyết định kiến trúc (architectural decisions) 105  Thể loại kiến trúc (architectural genres) thường sẽ chỉ ra cách tiếp cận kiến trúc cụ thể để cơ cấu đó phải được xây dựng. Trong bối cảnh thiết kế kiến ​​trúc, thể loại ngụ ý một thể loại cụ thể trong lĩnh vực phần mềm tổng thể.  Trong mỗi thể loại sẽ có một số tiểu thể loại.  Ví dụ: trong các thể loại của các tòa nhà, bạn sẽ gặp phải sau phong cách chung: nhà ở, căn hộ, chung cư, cao ốc văn phòng, xây dựng công nghiệp, nhà kho, và như vậy.  Mỗi phong cách (styles) sẽ có một cấu trúc có thể được mô tả bằng một tập hợp các mẫu dự đoán được (predictable patterns). 106  Trí tuệ nhân tạo (artificial intelligence): Hệ thống mô phỏng hoặc làm tăng thêm nhận thức của con người, vận động, hoặc các quá trình hữu cơ khác.  Thương mại và phi lợi nhuận (commercial and nonprofit): Hệ thống là nền tảng cho hoạt động của một doanh nghiệp kinh doanh.  Truyền thông (communications): Hệ thống cung cấp cơ sở hạ tầng để chuyển và quản lý dữ liệu, để kết nối người sử dụng dữ liệu đó, hoặc để trình bày dữ liệu ở rìa của một cơ sở hạ tầng.  Tác giả nội dung (content authoring): Hệ thống được sử dụng để tạo ra hoặc thao tác văn bản hoặc hiện vật đa phương tiện. 107  Thiết bị (devices): Hệ thống tương tác với thế giới vật chất để cung cấp một số dịch vụ điểm cho một cá nhân.  Giải trí và thể thao (entertainment and sports): Các hệ thống quản lý sự kiện công cộng hoặc cung cấp một trải nghiệm giải trí nhóm lớn.  Tài chính (financial): Hệ thống cung cấp cơ sở hạ tầng để chuyển và quản lý tiền và chứng khoán khác.  Trò chơi (games): Hệ thống cung cấp một kinh nghiệm vui chơi giải trí cho các cá nhân hoặc nhóm. 108  Chính phủ (government): Hệ thống hỗ trợ việc thực hiện và hoạt động của một địa phương, nhà nước, tổ chức chính trị liên bang toàn cầu, hoặc khác.  Công nghiệp (industrial): Hệ thống mô phỏng hoặc kiểm soát các quá trình vật lý.  Pháp lý (legal): Hệ thống hỗ trợ ngành công nghiệp pháp luật.  Y học (medical): Hệ thống chẩn đoán hay chữa lành hoặc đóng góp vào nghiên cứu y học. 109  Quân sự (military): Hệ thống tư vấn, thông tin liên lạc, chỉ huy, kiểm soát, và tình báo cũng như vũ khí tấn công và phòng thủ.  Hệ điều hành (operating systems): Hệ thống mà hiện diện ngay trên phần cứng để cung cấp cơ bản dịch vụ phần mềm.  Nền tảng (platforms): Hệ thống mà hiện diện ngay trên hệ điều hành cung cấp dịch vụ nâng cao.  Khoa học (scientific): Hệ thống được sử dụng cho nghiên cứu khoa học và ứng dụng. 110  Công cụ (tools): Hệ thống được sử dụng để phát triển các hệ thống khác.  Giao thông vận tải (transportation): Hệ thống kiểm soát xe nước, đất, không khí, hoặc không gian.  Các tiện ích (utilities): Hệ thống tương tác với các phần mềm khác để cung cấp một số điểm dịch vụ. 111  Các phần mềm được xây dựng cho các hệ thống dựa trên máy tính cũng trưng bày một trong nhiều phong cách kiến trúc (architectural styles).  Mỗi phong cách mô tả một loại hệ thống bao gồm: ◦ 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) mà thực hiện một chức năng theo yêu cầu của một hệ thống ◦ một tập hợp các kết nối cho phép "thông tin liên lạc, phối hợp và hợp tác“ giữa các thành phần ◦ ràng buộc xác định cách thức các thành phần có thể được tích hợp để tạo thành hệ thống ◦ các mô hình ngữ nghĩa cho phép một thiết kế để hiểu các thuộc tính tổng thể của một hệ thống bằng cách phân tích được biết đến đặc tính của các bộ phận cấu thành của nó 112  Kiến trúc lấy dữ liệu làm trung tâm (data-centered architectures)  Kiến trúc dòng dữ liệu (data-flow architectures)  Kiến trúc gọi và trả về có hai dạng kiến trúc con: ◦ Kiến trúc chương trình chính/chương trình con (main program/subprogram architectures) ◦ Kiến trúc thủ tục gọi từ xa (remote procedure call architecture)  Kiến trúc hướng đối tượng (object-oriented architectures)  Kiến trúc phân tầng (layered architectures) 113 114 115 116  Các thành phần của một hệ thống đóng gói dữ liệu và các hoạt động phải được áp dụng để thao tác trên dữ liệu  Thông tin liên lạc và phối hợp giữa các thành phần được thực hiện chuyển thông qua thông điệp (messages)  Các sơ đồ UML thường hay sử dụng trong thiết kế kiến trúc: ◦ Sơ đồ gói công việc (package diagram) ◦ Sơ đồ thành phần (component diagram) ◦ Sơ đồ triển khai (deployment diagram) 117 118 119 120 121 122  Biểu diễn hệ thống trong ngữ cảnh (representing the system in context) sử dụng sơ đồ ngữ cảnh kiến trúc (architectural context diagram - ACD) ◦ Superordinate systems ◦ Subordinate systems ◦ Peer-level systems ◦ Actors  Định nghĩa archetypes (defining archetypes) ◦ Node ◦ Detector ◦ Indicator ◦ Controller 123 124 125  Tinh chỉnh lại kiến trúc thành các thành phần (components)  Mô tả các thể hiện của hệ thống (describing instantiations of the system) 126 127 128 129  Phương pháp phân tích kiến trúc đánh đổi (an architecture trade-off analysis method) ◦ Thu thập các kịch bản ◦ Gợi ra yêu cầu, khó khăn, và mô tả môi trường ◦ Mô tả các phong cách kiến ​​trúc / mô hình đã được lựa chọn để giải quyết các tình huống và yêu cầu  Khung nhìn mô đun (module view)  Khung nhìn tiến trình (process view)  Khung nhìn dòng dữ liệu (data flow view) ◦ Đánh giá các thuộc tính chất lượng bằng cách xem xét từng thuộc tính trong sự cô lập ◦ Xác định sự nhạy cảm trên các thuộc tính chất lượng cho các thuộc tính kiến trúc khác nhau với một phong cách kiến ​​trúc cụ thể ◦ Bình phẩm kiến trúc bằng cách sử dụng phân tích độ nhạy 130  Độ phức tạp kiến trúc (architectural complexity) ◦ Chia sẻ phụ thuộc (sharing dependencies) ◦ Dòng phụ thuộc (flow dependencies) ◦ Ràng buộc phụ thuộc (constrained dependencies)  Ngôn ngữ mô tả kiến trúc (architectural description languages) 131  Chuyển đổi ánh xạ (transform mapping) ◦ Xem xét mô hình hệ thống cơ bản ◦ Xem xét và hoàn chỉnh sơ đồ dòng dữ liệu cho phần mềm ◦ Xác định xem dòng dữ liệu đã chuyển đổi hoặc dòng giao dịch ◦ Cô lập các trung tâm chuyển đổi bằng cách xác định ranh giới dòng đến và đi ◦ Thực hiện “nhân tố hóa mức đầu tiên" ◦ Thực hiện “nhân tố hóa mức thứ hai" ◦ Tinh chỉnh kiến ​​trúc đầu tiên sử dụng thiết kế heuristics để nâng cao chất lượng phần mềm  Tinh chỉnh lại thiết kế kiến trúc (refining the architectural design) 132 133 134 135 136 137 138 139 140  Spectrum Index (𝐼𝑆) - 𝑆𝑤 trường hợp thiết kế kiến trúc “tệ nhất” - 𝑆𝑏 trường hợp thiết kế kiến trúc “tốt nhất” 𝐼𝑆 = [(𝑆 − 𝑆𝑤)/(𝑆𝑏 − 𝑆𝑤)] × 100  Improvement Index (𝐼𝑚𝑝) 𝐼𝑚𝑝 = 𝐼𝑠1 − 𝐼𝑠2 với 𝑠1 và 𝑠2 tương ứng là hệ thống thứ nhất và thứ hai 141 Chỉ số chọn lựa thiết kế  Design Selection Index (𝑑) 𝑑 = (𝑁𝑠 −𝑁𝑎) × 100 với: 𝑁𝑠 là số lượng chiều thiết kế (design dimensions) có được bởi kiến trúc đề nghị 𝑁𝑎 là số lượng chiều trong không gian thiết kế 142  Mẫu kiến trúc đa tầng (multilayer architectural pattern)  Mẫu kiến trúc khách-chủ và các kiến trúc phân tán khác (client-server and other distributed architectural patterns)  Mẫu kiến trúc Broker (Broker architectural pattern)  Mẫu kiến trúc giao dịch-xử lý (transaction-processing architectural pattern)  Mẫu kiến trúc đường ống và bộ lọc (pipe-and-filter architectural pattern)  Mẫu kiến trúc mô hình-khung nhìn-kiểm soát (model- view-controller architectural pattern) 143  Mẫu kiến trúc hướng dịch vụ (service-oriented architectural pattern)  Mẫu kiến trúc hướng thông điệp (message-oriented architectural pattern) 144  Mẫu kiến trúc ngang hàng (peer-to-peer) cho tin nhắn tức thời (instant messaging), chỉ giữ lại một máy chủ trung tâm chỉ để tìm kiếm các địa chỉ của khách hàng 145 146 147 148 149 150 151 THIẾT KẾ THÀNH PHẦN (Component-Level Design) 152 153  Thiết kế thành phần (component design) xảy ra sau lần lặp đầu tiên của thiết kế kiến trúc đã hoàn thành. Ở giai đoạn này, các dữ liệu tổng thể và chương trình cấu trúc của phần mềm đã được thành lập.  Mục đích là để dịch (translate) mô hình thiết kế vào hoạt động phần mềm (operational software).  Mức độ trừu tượng (abstraction) của mô hình thiết kế hiện tại là tương đối cao, và mức độ trừu tượng của hoạt động chương trình là thấp. 154  Một thành phần (component) là một khối xây dựng mô đun hóa của phần mềm máy tính. ◦ Khung nhìn hướng đối tượng (object-oriented view) ◦ Khung nhìn truyền thống (traditional view) ◦ Khung nhìn tiến trình liên quan (process-related view)  [OMG - Unified Modeling Language] Thành phần là “ một phần mô-đun, triển khai, và thay thế của một hệ thống đóng gói thực hiện và đưa ra một tập hợp các giao diện. “  Giai đoạn thiết kế thành phần được triển khai sau khi hoàn thành thiết kế dữ liệu, thiết kế kiến trúc và thiết kế giao diện  Là giai đoạn làm giảm mức độ trừu tượng hóa (abstraction) để chuyển sang mức độ gần với mã lệnh (code) hơn  Kỹ sư phần mềm (software engineer) tại giai đoạn này phải mô tả cấu trúc dữ liệu, giao diện và giải thuật đủ điều kiện để sinh mã lệnh 155  Modularity  Overall simplicity  Ease of editing  Machine readability  Maintainability  Structure enforcement  Automatic processing  Data representation  Logic verification  “Code-to” ability 156 157 158 159  Các nguyên tắc thiết kế chính (basic design principles) ◦ Open-closed principle (OCP) ◦ Liskov substitution principle (LSP) ◦ Dependency inversion principle (DIP) ◦ Interface segregation principle (ISP) ◦ Release reuse equivalency principle (REP) ◦ Common closure principle (CCP) ◦ Common reuse principle (CRP)  Hướng dẫn thiết kế mức thành phần ◦ Components ◦ Interfaces ◦ Dependencies and Inheritances 160  Gắn kết (cohesion) ◦ Functional ◦ Layer ◦ Communicational ◦ Sequential ◦ Procedural ◦ Temporal ◦ Utility 161  Các chữ cái thể hiện tên viết tắt của kiểu nối kết 162  Nối kết (coupling) ◦ Content ◦ Common ◦ Control ◦ Stamp ◦ Data ◦ Routine call ◦ Type use ◦ Inclusion or import ◦ External 163 164 165 166  Xác định tất cả các lớp thiết kế tương ứng với các vấn đề tên miền  Xác định tất cả các lớp thiết kế tương ứng với tên miền cơ sở hạ tầng  Xây dựng tất cả các lớp thiết kế mà không phải mua như các thành phần tái sử dụng ◦ Ghi rõ chi tiết thông điệp khi các lớp hoặc các thành phần cộng tác với nhau ◦ Xác định các giao diện phù hợp với từng thành phần ◦ Xây dựng các thuộc tính và xác định các kiểu dữ liệu và cấu trúc dữ liệu cần thiết để thực hiện chúng ◦ Mô tả luồng xử lý trong mỗi hoạt động chi tiết 167  Mô tả các nguồn dữ liệu liên tục (cơ sở dữ liệu và các tập tin) và xác định các lớp học cần thiết để quản lý chúng  Phát triển và xây dựng cơ quan đại diện hành vi cho một lớp học hoặc một thành phần  Xây dựng sơ đồ triển khai để cung cấp thêm chi tiết thực hiện  Cấu trúc lại mỗi đại diện thiết kế thành phần cấp và luôn luôn xem xét lựa chọn thay thế 168 169 170 171 172  Thiết kế nội dung ở mức thành phần (Content Design at the Component Level)  Thiết kế chức năng ở mức thành phần (Functional Design at the Component Level) 173  Ký hiệu thiết kế đồ họa (graphical design notation)  Ký hiệu bảng thiết kế (tabular design notation)  Ngôn ngữ chương trình thiết kế (program design language) 174 175 176 177  Domain Engineering  Component Qualification, Adaptation, and Composition ◦ Component Qualification ◦ Component Adaptation ◦ Component Composition  Common object request broker architecture (OMG/CORBA)  Microsoft COM and .NET  Sun JavaBeans Components  Analysis and Design for Reuse ◦ Standard data ◦ Standard interface protocols ◦ Program templates  Classifying and Retrieving Components 178 THIẾT KẾ GIAO DIỆN (Interface Design) 179  Là “cửa sổ, cửa chính” của phần mềm giao tiếp với môi trường bên ngoài  Thiết kế trên 3 lĩnh vực: ◦ giao diện giữa các thành phần của phần mềm ◦ giao diện giữa phần mềm va ̀ nơi sản xuất (producer) va ̀ tiêu thụ (consumer) thông tin (i.e., không phải là con người) ◦ giao diện giữa phần mềm va ̀ con người 180 181  Đặt người sử dụng vào vai trò điều khiển (control)  Hạn chế việc “nạp bộ nhớ” người sử dụng  Làm cho giao diện nhất quán (consistency) 182  Xác định phương thức tương tác trong một cách mà không ép buộc một người sử dụng vào các hoạt động không cần thiết hoặc không mong muốn  Cung cấp cho sự tương tác linh hoạt  Cho phép người dùng tương tác được ngắt và không thể nén  Sắp xếp tương tác như trình độ kỹ năng thúc đẩy và cho phép tương tác để được tùy chỉnh  Ẩn ruột kỹ thuật từ người sử dụng quan hệ nhân quả  Thiết kế để 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 183  Giảm nhu cầu về bộ nhớ ngắn hạn  Thiết lập mặc định có ý nghĩa  Xác định các phím tắt mà là trực quan  Bố trí trực quan của giao diện nên được dựa trên một phép ẩn dụ thế giới thực  Tiết lộ thông tin một cách tiến bộ 184  Cho phép người dùng đặt nhiệm vụ hiện tại vào một bối cảnh có ý nghĩa  Duy trì tính nhất quán giữa một gia đình của các ứng dụng  Nếu các mô hình tương tác qua đã tạo ra những kỳ vọng của người dùng, không thay đổi trừ khi có một lý do gì để làm như vậy 185  Còn được gọi là: ◦ mô hình người sử dụng (user’s model) hay ◦ hê ̣ thống nhận thức (system perception)  Phân loại người sử dụng ◦ Novice: không có tri thức vê ̀ cú pháp (syntactic knowledge) của hê ̣ thống va ̀ biết sử dụng một chút vê ̀ hê ̣ thống (a little semantic knowledge) ◦ Knowledgeable, intermittent users ◦ Knowledgeable, frequent users 186  Người sử dụng (user), công việc (task), phân tích môi trường (environment analysis) và mô hình hóa (modeling)  Thiết kế giao diện (interface design)  Xây dựng giao diện (interface construction)  Hợp thức hóa giao diện (interface validation) 187 188 189 190 191 192 193  Thiết lập các mục tiêu (goals) và các dự định (intentions) cho mỗi công việc (task)  Ánh xạ mỗi mục tiêu và dự định vào một chuỗi các hoạt động đặc thù  Đặc tả chuỗi hành động của công việc và công việc con, gọi là kịch bản người sử dụng (user scenario), như sẽ được thực thi ở mức giao diện  Chỉ ra trạng thái của hệ thống; tức là giao diện sẽ được nhìn thấy như thế nào tại thời điểm mà kịch bản người sử dụng được thực hiện 194  Định nghĩa cơ chế điều khiển (control mechanisms); như là các đối tượng (objects) và hành động (actions) sẵn sàng cho nguòi sử dụng chuyển (alter) trạng thái hệ thống (system state)  Trình diễn cách thức cơ chế điều khiển tác động đến các trạng thái của hệ thống  Chỉ ra cách thức người dùng giải thích tình trạng của hệ thống từ các thông tin được cung cấp thông qua giao diện 195  Phân tích người sử dụng (user analysis) ◦ Phỏng vấn người sử dụng (user interviews) ◦ Đầu vào bán hang (sales inputs) ◦ Đầu vào tiếp thị (marketing input) ◦ Đầu vào hỗ trợ (support input)  Phân tích và mô hình hóa công việc (task analysis and modeling) ◦ Các trường hợp sử dụng (use cases) ◦ Nhiệm vụ xây dựng (task elaboration) ◦ Đối tượng xây dựng (object elaboration) ◦ Phân tích dòng công việc (workflow analysis) ◦ Thứ bậc đại diện (hierarchical representation) 196  Phân tích nội dung hiển thị (analysis of display content)  Phân tích môi trường làm việc (analysis of work environment) 197  Áp dụng các bước thiết kế giao diện  Sử dụng mẫu thiết kế giao diện người sử dụng  Các vấn đề thiết kế ◦ Thời gian đáp ứng (response time) ◦ Các cơ sở trợ giúp (help facilities) ◦ Xử lý lỗi (error handling) ◦ Thực đơn và ghi nhãn lệnh (menu and command labeling) ◦ Khả năng tiếp cận ứng dụng (application accesibility) ◦ Quốc tế hóa (internationalization) 198  Interface Design Principles and Guidelines ◦ Anticipation. A WebApp should be designed so that it anticipates the user’s next move. ◦ Communication. The interface should communicate the status of any activity initiated by the user ◦ Consistency. The use of navigation controls, menus, icons, and aesthetics (e.g., color, shape, layout) should be consistent throughout the WebApp ◦ Controlled autonomy. The interface should facilitate user movement throughout the WebApp, but it should do so in a manner that enforces navigation conventions that have been established for the application. 199  Interface Design Principles and Guidelines ◦ Efficiency. The design of the WebApp and its interface should optimize the user’s work efficiency, not the efficiency of the developer who designs and builds it or the clientserver environment that executes it ◦ Flexibility. The interface should be flexible enough to enable some users to accomplish tasks directly and others to explore the WebApp in a somewhat random fashion ◦ Focus. The WebApp interface (and the content it presents) should stay focused on the user task(s) at hand ◦ Human interface objects. A vast library of reusable human interface objects has been developed for WebApps. Use them. 200  Interface Design Principles and Guidelines ◦ Latency reduction. Rather than making the user wait for some internal operation to complete (e.g., downloading a complex graphical image), the WebApp should use multitasking in a way that lets the user proceed with work as if the operation has been completed. ◦ Learnability. A WebApp interface should be designed to minimize learning time, and once learned, to minimize relearning required when the WebApp is revisited. ◦ Metaphors. An interface that uses an interaction metaphor is easier to learn and easier to use, as long as the metaphor is appropriate for the application and the user 201  Interface Design Principles and Guidelines ◦ Maintain work product integrity. A work product (e.g., a form completed by the user, a user-specified list) must be automatically saved so that it will not be lost if an error occurs. ◦ Readability. All information presented through the interface should be readable by young and old. ◦ Track state. When appropriate, the state of the user interaction should be tracked and stored so that a user can logoff and return later to pick up where she left off. ◦ Visible navigation. A well-designed WebApp interface provides “the illusion that users are in the same place, with the work brought to them” 202  Interface Design Workflow for WebApps ◦ Review information contained in the requirements model and refine as required. ◦ Develop a rough sketch of the WebApp interface layout. ◦ Map user objectives into specific interface actions. ◦ Define a set of user tasks that are associated with each action. ◦ Storyboard screen images for each interface action. ◦ Refine interface layout and storyboards using input from aesthetic design. ◦ Identify user interface objects that are required to implement the interface. ◦ Develop a procedural representation of the user’s interaction with the interface. ◦ Develop a behavioral representation of the interface. ◦ Describe the interface layout for each state. ◦ Refine and review the interface design model. 203  Truy xuất hệ thống SafeHome  Nhập định danh (ID) và mật khẩu (password) để cho phép truy xuất từ xa  Kiểm tra trạng thái hệ thống system status  Bật báo động hay ngưng báo động của hệ thống SafeHome  Hiển thị floor plan và sensor locations  Hiể thị zones trên mặt phảng tầng  Thay đổi zones trên mặt phẳng tầng 204  Hiển thị vị trí của video camera locations trên mặt phảng tầng  Lựa chọn video camera để xem lại  Xem các video images (4 khung hình trên một giây)  Dừng máy hay phóng to hoặc thu nhỏ video camera 205 206  Chiều dài và phức tạp của các đặc điểm kỹ thuật bằng văn bản của hệ thống và giao diện của nó cung cấp một chỉ số về số lượng học tập theo yêu cầu của người sử dụng của hệ thống  Số lượng công việc người dùng chỉ định và số lượng trung bình của các hành động mỗi nhiệm vụ cung cấp một dấu hiệu của thời gian tương tác và hiệu quả tổng thể của hệ thống 207  Số lượng hành động, nhiệm vụ, và các quốc gia hệ thống chỉ định bởi các mô hình thiết kế bao hàm tải bộ nhớ trên hệ thống của người sử dụng  Phong cách giao diện, cơ sở giúp đỡ, và giao thức xử lý lỗi cung cấp một dấu hiệu chung của sự phức tạp của giao diện và mức độ mà nó sẽ được chấp nhận bởi người sử dụng 208 209 THIẾT KẾ HƯỚNG MẪU (Pattern-based Design) 210  Một mẫu thiết kế có thể được mô tả như là "một quy tắc ba phần diễn tả một mối quan hệ giữa một bối cảnh nhất định, một vấn đề, và một giải pháp“  Các dạng mẫu: ◦ Mẫu kiến tạo (creational patterns) ◦ Mẫu cấu trúc (structural patterns) ◦ Mẫu hành vi (behavioral patterns)  Khung công việc (frameworks)  Mô tả một mẫu thế nào (describing a pattern)?  Ngôn ngữ mẫu và lưu trữ (pattern language and repositories) 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225  Kiến tạo (creational): abstract factory, builder, factory method, prototype, singleton  Cấu trúc (structural): adapter, bridge, composite, decorator, façade, flyweight, proxy  Hành vi (behavioral): chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template method, visitor 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 THIẾT KẾ HƯỚNG WEB (WebApp Design) 251  An ninh (security)  Sẵn sang (availability)  Khả năng mở rộng (scalability)  Thời gian đưa ra thị trường (time-to-market) 252  Đơn giản (simplicity)  Chặt chẽ (consistency)  Bản sắc (identity)  Mạnh mẽ (robustness)  Điều khiển được (navigability)  Trực quan hấp dẫn (visual appeal)  Khả năng tương thích (compatibility) 253 254 255 256  Thực đơn di chuyển (navigation menus)  Các biểu tượng đồ họa (graphic icons)  Hình ảnh đồ họa (graphic image) 257  Các vấn đề về bố trí (layout issues) ◦ Đừng sợ không gian màu trắng ◦ Nhấn mạnh nội dung ◦ Tổ chức các yếu tố bố trí từ trên bên trái để dưới bên phải ◦ Hướng nhóm, nội dung và chức năng địa lý trong trang ◦ Không mở rộng bất động sản của bạn với thanh cuộn ◦ Xem xét giải quyết và kích thước cửa sổ trình duyệt khi thiết kế bố trí  Các vấn đề về thiết kế đồ họa (graphic design issues) 258  Đối tượng nội dung (content objects)  Nội dung vấn đề thiết kế (content design issues) 259 260  Kiến trúc nội dung (content architecture) ◦ Cấu trúc tuyến tính (linear structures) ◦ Cấu trúc lưới (grid structures) ◦ Cấu trúc phân cấp (hierarchical structures) ◦ Cấu trúc mạng (networked or “pure web” structure) 261 262 263 264 265 266 267  Ngữ nghĩa di chuyển (navigation semantics)  Cú pháp di chuyển (navigation syntax) ◦ Liên kết di chuyển cá thể (individual navigation link) ◦ Thanh di chuyển theo hàng ngang (horizontal navigation bar) ◦ Thanh di chuyển theo cột dọc (vertical navigation column) ◦ Các thể (tabs) ◦ Bản đồ trang web (site maps) 268 269 270 Object-Oriented Hypermedia Design Method (OOHDM)  Thiết kế khái niệm (coneptual design) cho OOHDM  Thiết kế di chuyển (navigational design) cho OOHDM  Thiết kế và cài đặt giao diện trừu tượng (abstract interface design and implementation) 271 272 273 THIẾT KẾ HƯỚNG DỊCH VỤ (Service-Oriented Architecture) 274  Service-oriented life cycle  Service-oriented discovery and analysis  Service-oriented business integration  Service-oriented design model  Service-oriented software architecture modeling principles 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299