Thiết kế phần mềm

Tuy nhiên, ngày nay phần lớn mọi người phát triển phần mềm theo tổ. Thành viên tổ của bạn không thể đọc được điều có trong đầy bạn cho nên bạn cần làm tài liệu cho thiết kế để trao đổi các quan niệm với những người khác trong dự án. Thiết kế điển hình có hai phần chính: Mức cao hay kiến trúc và mức thấp hay thiết kế chi tiết.

Tài liệu thiết kế mô tả các khu vực cần được nghiên cứu để nhận diện cái gì có thể làm việc và cái gì có thể không. Vì dự án phần mềm được thực hiện bởi tổ con người, điều quan trọng là chia sẻ thiết kế để cho tổ có thể đánh giá và thảo luận để nhận diện bất kì lỗi nào trong dự án. Vì yêu cầu phần mềm thường thay đổi, thiết kế cung cấp điểm tham chiếu chung cho tổ để đánh giá tác động của thay đổi và ra quyết định.

Mức cao hay kiến trúc phần mềm chỉ ra cách hệ thống được phân chia thành các cấu phần chính; cách những cấu phần này có quan hệ lẫn nhau; cách chúng giao tiếp với người dùng; cách chúng tương tác với hệ thống khác; và cách chúng tương tác giữa chúng với nhau. Kiến trúc phần mềm cũng nhận diện các định nghĩa dữ liệu; dữ liệu nào sẽ được lưu giữ và chỗ chúng sẽ được lưu giữ. Kiến trúc sư nhận diện các ràng buộc hệ thống, đặc tính chất lượng như hiệu năng, sự mở rộng, an ninh, tính khả chuyển và công nghệ nền (như, dựa trên PC, dựa trên mây).

Từ kiến trúc, những người phát triển dịch chuyển sang mức thấp hay thiết kế chi tiết nơi họ chia từng cấu phần thành các mô đun nhỏ hơn trong đó từng chức năng có thể được xác định cũng như các ràng buộc của nó trên giao diện của nó. Từng mô đun cũng có tiêu chí vào và ra với cấu trúc dữ liệu và thuật toán được xác định.

Thông tin thiết kế có thể được làm tài liệu trong chú thích văn bản (như, “Máy phục vụ đáp ứng mỗi năm giây bằng cái ra XYZ,” “Cấu phần ABC sẽ giải quyết mọi lỗi,” hay “Cơ sở dữ liệu sẽ đồng bộ cứ mỗi 5 phút,”) hay nó có thể được làm tài liệu dưới dạng đồ hoạ (như, ngôn ngữ mô hình hoá, UML, bảng biến cố, biểu đồ hoàn cảnh, biểu đồ luồng, biểu đồ thời gian v.v.) hay nó có thể được làm tài liệu như mã giả – mô tả văn bản về điều mã sẽ làm.

—-Engish version—-

Software design

A programmer wrote to me: “Why do we have to document software design? Is it possible keeping the design in your mind and start to write code instead? What is the difference between architecture and design?

Answer: Basically design is a map of the software product that you are going to build. If you are the only person who build the product then it is possible not to document it. You can start coding from what you have in mind.

However, today most people develop software in team. Your team members cannot read your mind so you need to document your design to communicate the concepts to other people in the project. Typical Design has two major parts: The high level or the architecture and the low level or the detailed design.

Design document describes areas that need to be investigated to identify what may works and what may not. Since software project is done by a team of people, it is important to share the design so the team can evaluate and discuss to identify any errors early in the project. Since software requirements often change, the design provides a common reference point for the team to assess the impact of changes and make design decisions.

The high level or the software architecture indicates how the system is divided into major components; how these components are related to each other; how they interfaces to the user; how they interact to other systems; and how they interact between themselves. The software architecture also identifies data definitions; what data will be stored and where they will be stored. The architect identifies system constraints, quality attributes such as performance, expansion, security, portability and platform technology (e.g., PC-based, cloud-based).

From the architecture, developers shifts to the low-level or detailed design where they breakdown each component into smaller modules where each functions could be specified as well as its constraints on its interface. Each module should also have entry and exit criteria with internal data structures and algorithms defined.

Design information can be documented in textual notes (e.g., “The server responds every 5 seconds with XYZ output,” “Component ABC will handle all errors,” or “The databases will be synced every 5 minutes:”) or it can be documented in graphical form (e.g., modeling languages, UML, event tables, context diagram, flow diagrams, timing diagrams etc.) or it can be documented as pseudo code – a textual description of what the code will do.