Bài viết trước thì mình có nói về UML bản vẽ thi công phần mểm, nhưng có lẽ đó chỉ là mảnh ghép nhỏ trong cả một kho tài liệu hệ thống của phần mềm, bạn có thể đọc lại tại đây nhé!
Có mấy vấn đề mình cần đề cập để các bạn phân biệt được trước khi bắt đầu bài viết.
Đầu tiên phần mềm được tạo ra không chỉ bao gồm phần chương trình chạy và mã nguồn (source code) mà nó còn phải đi kèm cả một kho hệ thống tài liệu, hướng dẫn, vận hành, thi công, triển khai, và UML chỉ là một mảnh rất nhỏ trong một bức tranh rất lớn.
Thứ 2 đó là kiến trúc phần mềm (Software Architecture) khác với (Software Design) thiết kế phần mềm.
Software Architecture là thiết kế bộ khung cho hệ thống, cách phân chia và tương tác giữa các component. Nó là quá trình chuyển các đặc tính của phần mềm như linh hoạt, khả năng mở rộng, tái sử dụng, bảo mật… thành một giải pháp có tính tổ chức mà đáp ứng được nhu cầu về business cũng như về mặt kỹ thuật
Software Design là bước đầu tiên trong software design life cycle, nó sẽ chuyển hóa từ ý tưởng thành hiện thực, và cố gắng thực hiên các yêu cầu được đề cập trong requirement. Software Design được định nghĩa là quá trình xác định kiến trúc (architecture), thành phần (components), giao diện (interfaces), và những yếu tố khác làm thành hệ thống phần mềm. Vậy Software Architecture là một phần của Software Design.
Còn một ý nữa là từ thiết kế hay bị nhầm với cả UI/UX Design và ở đây thì nó là một mảnh nhỏ của mảnh ghép giao diện (interfaces) ở trên. Đừng đánh đồng 4 khái niệm này làm một nhé.
UI Design (User Interface Design) có nghĩa là thiết kế giao diện người dùng với mục đích giúp con người có khả năng trao đổi trực tiếp với máy tính.
UX Design (User Experience Design) là nghiên cứu và đánh giá cách người dùng cảm nhận về một hệ thống.
Trong software design có 3 level : architectural design, high-level design, và detailed design. Đến đây thì lại xuất hiện 2 thuật ngữ dễ nhầm lẫn khác đó là mẫu kiến trúc (Architectural Pattern) và mẫu thiết kế (Design Pattern)
Pattern là một giải pháp ứng với một vấn đề lặp đi lặp lại.
Với Architectural Patterns thì chúng ta sẽ cần những lớp nào và chúng sẽ tương tác như thế nào, để xây dựng một hệ thống với một tập các layer cụ thể” hoặc “những high-level module nào sẽ có trong Service-Oriented Architecture của chúng ta và cách chúng giao tiếp. Thế rồi chúng ta sẽ có bao nhiêu tiers trong kiến trúc Client-Server.
Design Patterns khác Architectural Patterns ở phạm vi (scope) của chúng. Design Patterns giải quyết các vấn đề cục bộ, nhỏ lẻ hơn, nó không ảnh hưởng lớn đến code base mà chỉ là 1 phần nhỏ trong đó.
Architectural Patterns sẽ là một mảnh ghép nằm trong Architectural Design và High-Level Design còn Design Patterns thì lại có thể có hoặc không trong Detailed Design
Túm cái váy lại thì mình có thể tạm so sánh như sau (mình so sánh tương đổi để hiểu chứ không thực sự cái nọ bao gồm cái kia nhé)
Software Development > Technical Documentation > Software Design > Software Architecture > Architectural Design > High-Level Design > Architectural Patterns > Detailed Design > Design Patterns > UI/UX Design
Bắt đầu phần chính bài viết nào!
SAD là 3 ký tự nhưng rất nhiều kiểu viết tắt trong phần mềm. Có chỗ thì quy định nó là System Architecture Document, có chỗ thì là System Analyst Designer hay System Application Design, có chỗ lại là Solution Architecture Document rồi Software Architecture Document. Vậy nên nếu ai đó có nói bạn về thuật ngữ này thì nên hỏi nó là gì nhé, mất công nhầm lẫn 
Ở bài viết này mình đề cập thì nó là Software Architecture Document. Nó là một tài liệu được yêu cầu trình bày trong giai đoạn sơ khởi của dự án và bắt buộc bàn giao trong quá trình phát triển sản phẩm.
Dưới đây là lý do cần có Software Architecture Document
-
Giúp nhà phát triển hiểu lý do đằng sau các quyết định chọn lựa kiến trúc.
-
Để truyền đạt thông tin liên quan hệ thống đến các thành viên tham gia thiết kế và phát triển hệ thống.
-
Tài liệu hoá liên quan đến kiến trúc có tính ảnh hưởng sâu rộng đến hệ thống. Nó giúp việc nâng cấp, bảo trì trở nên dễ dàng trong tương lai.
-
Tài liệu chứa thông tin (các thuộc tính chất lượng cần ưu tiên theo yêu cầu nghiệp vụ, các kịch bản, bảng đánh giá so sánh các giải pháp thiết kế thay thế,…) liên quan đến việc đưa ra quyết định chọn lựa kiến trúc và nó sẽ là tài liệu quyết định cuối cùng về kiến trúc.
-
Để tích hợp giữa hệ thống đang có với các hệ thống khác và cung cấp thông tin tham khảo cho các nhà thiết kế kiến trúc khác tham khảo và tái sử dụng lại (Reuse) cho các sản phẩm khác trong tương lai.
-
Là căn cứ nhằm ước lượng, lên kế hoạch cho dự án và cung cấp cơ sở cho quá trình hình thành cấu trúc nhóm phát triển.
-
Đánh giá hiệu năng của hệ thống trước khi nó được xây dựng, đánh giá các ràng buộc (constraints), những hạn hế (limitations) của sản phẩm để đảm bảo chất lượng phần mềm.
–
Đọc tiếp tại đây nhé!
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?