Phát triển dự án tiến hành theo thứ tự Xác định yêu cầu-> Thiết kế cơ bản-> Thiết kế chi tiết-> Lập trình-> Kiểm thử đơn vị (Unit Test)-> Kiểm thử tích hợp (Integration Test)-> Kiểm tra toàn diện-> Kiểm tra hoạt động-> Triển khai và bảo trì hệ thống
Ở trên là một mô hình đầy đủ cho một quy trình phát triển phần mềm, nhưng người ta vẫn sẽ tự hỏi là khi nào thì nên viết một bản thiết kế chi tiết.
Trong bài viết này, tôi sẽ giới thiệu một mẫu thiết kế chi tiết và giải thích cách viết nó.
Thiết kế chi tiết là gì?
Thiết kế chi tiết đôi khi được gọi là thiết kế nội bộ, nhưng trên trang web này, nó được tiêu chuẩn hóa như thiết kế chi tiết.
Thiết kế chi tiết là một quá trình có thể dễ bị hiểu lầm. Nhiều người cho rằng thiết kế chi tiết là không cần thiết khi kiểm tra thiết kế chi tiết trực tuyến.
Trước hết, thiết kế chi tiết không phải là “Viết mã lập trình bằng tiếng Nhật”. Tài liệu này được gọi là “Tài liệu đặc tả lập trình (coding)” và đôi khi được phát triển trong quá trình offshore (Ủy thác phát triển sản phẩm ở nước ngoài). Nếu phát triển sản phẩm ở trong nước thì tài liệu đặc tả lập trình là không cần thiết.
Thiết kế chi tiết là một bước quan trọng trong việc xác định cấu trúc bên trong của một chức năng.
Nếu quy mô hệ thống nhỏ và bạn đang phát triển một mình, tốt hơn là suy nghĩ về cấu trúc bên trong trong khi lập trình. Nếu không, sao chép mã sẽ xảy ra và những rủi ro sau đây sẽ phát sinh.
- Phát sinh ra việc kiểm thử vô ích.
- Tăng các bộ phận cần phải kiểm tra bảo trì thại thời điểm bảo trì
- Tăng số lượng nhân công khảo sát trong thời gian bảo trì.
Dưới đây, tôi xin giới thiệu một vài cách viết thiết kế chi tiết.
Các tài liệu thiết kế chi tiết
Chi tiết thiết kế bàn giao:
Vì các sản phẩm của tài liệu thiết kế chi tiết khác nhau tùy thuộc vào công ty, tổ chức hoặc dự án, điều quan trọng là phải làm rõ loại sản phẩm nào được chỉ định.
Các tài liệu sau đây được giới thiệu ở đây là tài liệu thiết kế chi tiết.
- Sơ đồ hoạt động
- Sơ đồ trình tự
- Sơ đồ lớp
- Mô tả chức năng xử lý (IPO)
- Cấu trúc mô đun
Sơ đồ hoạt động
Một sơ đồ hoạt động gần giống với một flowchart, trong khi flowchart chỉ mô tả hoạt động của chương trình thì sơ đồ hoạt động sẽ mô tả cả các hoạt động của người dùng cũng như hướng vận hành của hệ thống.
Bằng cách mô tả hoạt động của người dùng, có thể dễ dàng hơn trong việc đánh giá xử lý nào ở thời gian nào.
Cách viết:
- Có thể viết giống với cách viết flowchart.
- Viết các hành động của người dùng và hệ thống vào khung và thể hiện sự liên kết trong quy trình đó bằng một mũi tên.
- Các nhánh điều kiện sẽ được thể hiện bằng ký tự quả trám như thể hiện ở sơ đồ trong hình minh họa.
Sơ đồ trình tự
Một sơ đồ trình tự được dùng để mô tả trình tự bên trong của hệ thống các chi tiết cụ thể hơn sơ đồ hoạt động, nó thể hiện sự khác biệt giữa các lớp và đối tượng theo trục thời gian.
Trong việc sử dụng tài liệu, sử dụng sơ đồ hoạt động để nắm bắt luồng người dùng và các chức năng một cách tổng quát, và xem sơ đồ trình tự để hiểu xử lý chi tiết hơn.
Cách viết:
- Có thể tham khảo từ ví dụ mẫu, trục dọc biểu thị thời gian và trục ngang đại diện cho người dùng và các chức năng hệ thống (đối tượng).
- Để phản hồi một hành động từ người dùng, một đối tượng thể hiện thông tin nào mà đối tượng nhận được và thông tin nào được truyền cho đối tượng tiếp theo.
- Ngoài ra, có một mô tả để thể hiện cấu trúc xử lý. Trong mẫu trên, vòng lặp “loop| và “opt” được sử dụng.
- Vòng lặp liên tục có nghĩa là hoạt động/ xử lý được lặp đi lặp lại, còn vòng lặp opt có nghĩa là nó được thực hiện khi một điều kiện cụ thể được đáp ứng.
Sơ đồ lớp
Thể hiện mối quan hệ giữa các tầng và các lớp tạo nên hệ thống.
Đây là một bản phác thảo để lập trình và rất hữu ích để phân công các ưu tiên công việc và chia sẻ công việc giữa nhiều người.
Mặc dù sơ đồ lớp có thể hiểu cấu hình hệ thống, sơ đồ trình tự được mô tả ở trên là cần thiết để nắm bắt luồng xử lý.
Cách viết:
- Thực hiện theo các quy tắc trên để vẽ sơ đồ lớp.
- Xác định các lớp từ sơ đồ hoạt động và sơ đồ trình tự, tạo các lớp cha trong khi xem xét các mối quan hệ giữa các lớp và viết ra các tổng hợp và phụ thuộc.
Cách viết class diagram :
Bước 1: Tìm các Classes dự kiến
Bước 2: Tìm các thuộc tính và phương thức cho lớp
– Tìm thuộc tính: phân tích thông tin từ các form mẫu có sẵn, bạn sẽ tìm ra thuộc tính cho các đối tượng của lớp.
– Tìm phương thức: phương thức là các hoạt động mà các đối tượng của lớp này có thể thực hiện.
Bước 3: Xây dựng các quan hệ giữa các lớp và phát hiện các lớp phát sinh
- Đặc tả Class
Nhìn vào Class Diagram chúng ta có thể thấy cấu trúc của hệ thống gồm những lớp nào nhưng để cài đặt chúng, chúng ta phải đặc tả chi tiết hơn nữa. Trong đó, cần mô tả:
– Các thuộc tính: Tên, kiểu dữ liệu, kích thước
– Các phương thức:
- Tên
- Mô tả
- Tham số đầu vào: Tên, kiểu dữ liệu, kích thước
- Kết quả đầu ra: Tên, kiểu dữ liệu, kích thước
- Luồng xử lý
- Điều kiện bắt đầu
- Điều kiện kết thúc
Tuy nhiên, việc này cũng mất khá nhiều thời gian. Nếu phát triển theo mô hình Agile thì bạn không phải làm việc này mà các thành viên phát triển phải nắm điều này để cài đặt.
Bản mô tả chức năng
Bản mô tả chức năng xử lý:
IPO là viết tắt của I = Input, P = Process, O = Output.
Theo kinh nghiệm của tôi, các mô tả chức năng xử lý được định nghĩa là các sản phẩm có thể phân phối trong các hệ thống máy tính lớn, nhưng dường như không có nhiều cơ hội để tạo chúng trong các hệ thống web.
Cách viết:
- Mô tả quá trình xử lý sẽ được thực hiện bằng cách sử dụng dữ liệu đầu vào để tạo dữ liệu đầu ra.
- Thể hiện rõ ràng dữ liệu đầu vào sẽ dẫn tới quy trình nào và cho ra đầu ra là gì.
Sơ đồ cấu trúc mô đun
Sơ đồ này cũng được sử dụng trên các máy tính lớn và đề cập đến các mô-đun sau khi biên dịch các ngôn ngữ máy tính lớn như COBOL.
Nó diễn tả loại mô-đun mà mỗi chức năng hệ thống được cấu thành và có thể dự kiến sẽ cải thiện năng suất bằng cách chia sẻ logic. (Hoạt động chung của logic cải thiện năng suất vận hành và bảo trì).
Cách viết:
- Xem xét quá trình có thể được chia sẻ trong khi viết ra quy trình cấu thành chức năng và chia nhỏ xuống các cấp độ thấp hơn.
- Quá trình xử lý được chia sẻ là một mô hình con được gọi từ mô đun chính, sau đó phân chia ra nhiều mô đun khác gọi là mô đun phụ.
- Theo như ví dụ dưới đây, có thể thấy danh sách tổng hợp bao gồm ba mô-đun: Trích xuất dữ liệu, phát hành danh sách và cập nhật dữ liệu.
Tổng kết
Trên đây tôi đã giới thiệu so qua làm thế nào để có thể viết được tài liệu thiết kế chi tiết.
Như đã đề cập ở phần đầu, tài liệu thiết kế chi tiết không bắt buộc đối với một số dự án. Ngoài ra còn có các định nghĩa khác nhau của các tài liệu thiết kế chi tiết. (Sơ đồ lớp hoặc mô tả chức năng xử lý). Tùy vào đặc điểm của dự án mà người ta sẽ xem xét có hay không nên dành effort vào việc viết tài liệu thiết kế chi tiết này.
Ngay cả khi bạn không cần một tài liệu thiết kế chi tiết thì bản thân công việc thiết kế chi tiết là cần thiết. Đây có thể là một vấn đề liên quan đến QCD (chất lượng, chi phí, thời gian bàn giao) của dự án và nó có thể dẫn đến giảm năng suất vận hành và bảo trì.
Hi vọng bạn có thể tìm thấy điều gì đó bổ ích qua bài viết này.