Chương 3. Xây dựng phầnmềm (Software construction)

1THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM (SOFTWARE DESIGN AND CONSTRUCTION) Năm học 2008-2009 Giảng viên: PGS.Huỳnh Quyết Thắng BM Công nghệ phần mềm Khoa CNTT, ĐHBK HN 2Chương 3. Xây dựng phần mềm (Software construction) 1. Xây dựng phần mềm 2. Thiết kế thành phần phần mềm 3. Thiết kế chi tiết 4. Thiết kế chương trình 5. Câu hỏi, bài tập, tài liệu tham khảo 3.1.Khái niệm Xây dựng phần mềm z Khái niệm: • “The term software construction refers to the detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging” (IEEE) z Mối liên hệ với các giai đoạn khác • Có liên quan mật thiết đến gian đoạn thiết kế (SD) và giai đoạn kiểm thử (ST) phần mềm • Đầu ra của giai đoạn thiết kế là đầu vào của giai đoạn này • Đầu ra của giai đoạn này là đầu vào của giai đoạn kiểm thử 3.2. Thiết kế thành phần phần mềm z Component-based software engineering (CBSE) is an approach to software development that relies on reuse z It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific z Components are more abstract than object classes and can be considered to be stand- alone service providers 3.2. Thiết kế thành phần phần mềm z Components provide a service without regard to where the component is executing or its programming language • A component is an independent executable entity that can be made up of one or more executable objects • The component interface is published and all interactions are through the published interface z Components can range in size from simple functions to entire application systems Component interfaces Component Provides interfaceRequires interface Component interfaces z Provides interface • Defines the services that are provided by the component to other components z Requires interface • Defines the services that specifies what services must be made available for the component to execute as specified Printing services component Provides interfaceRequires interface Print PrintService GetQueue Remove Transfer Register Unregister GetPDfile PrinterInt Component abstractions z Functional abstraction • The component implements a single function such as a mathematical function z Casual groupings • The component is a collection of loosely related entities that might be data declarations, functions, etc. z Data abstractions • The component represents a data abstraction or class in an object-oriented language z Cluster abstractions • The component is a group of related classes that work together z System abstraction • The component is an entire self-contained system CBSE processes z Component-based development can be integrated into a standard software process by incorporating a reuse activity in the process z However, in reuse-driven development, the system requirements are modified to reflect the components that are available z CBSE usually involves a prototyping or an incremental development process with components being ‘glued together’ using a scripting language An opportunistic reuse process Design system aachitecture Specify components Search for reusable components Incorporate discovered components Development with reuse Search for reusable components Outline system requirements Modify requirements according to discovered components Search for reusable components Architectural design Specify system components based on reusable components CBSE problems z Component incompatibilities may mean that cost and schedule savings are less then expected z Finding and understanding components z Managing evolution as requirements change in situations where it may be impossible to change the system components 3.3. Thiết kế chi tiết z Là thiết kế cho các phần không thấy được. Nó là thiết kế khi được nhìn theo quan điểm của chuyên gia máy tính hay người phát triển hệ thống. z Đối lập với thiết kế ngoài: Hệ thống được thiết kế theo quan điểm người dùng. z Mục đích: • Xác định các chức năng mà phần mềm cần phải thực hiện theo quan điểm người phát triển. • Đảm bảo sự độc lập của từng pha sao cho pha nọ có thể được phân biệt rõ ràng bởi pha kia. 3.3. Thiết kế chi tiết z Đặc điểm của thiết kế trong • Minimal complexity (clever design) • Ease of maintenance (think in maintenance side) • Loose coupling (abt cls, int cls) • Extensibility • Reusability • Portability • Leanness • Stratification • Standard techniques 3.3. Thiết kế chi tiết z Quy trình Hiểu tài liệu thiết kế ngoài Phân hoạch và cấu trúc chức năng Thiết kế dữ liệu vật lý Thiết kế vào/ra chi tiết Reuse Tạo tài liệu thiết kế chi tiết Xét duyệt tài liệu 3.3. Thiết kế chi tiết z 3.3.1. Hiểu tài liệu thiết kế ngoài • Kết quả của pha trước phải được hiểu rõ trong pha này theo tổng thể của hệ thống • Bao gồm: • Luồng hệ thống -> phân chia hệ con • Bản thiết kế cái vào cái ra -> thiết kế I/O • Bản thiết kế dữ liệu logic -> thiết kế DL Vật lý • Cấu hình và hiệu năng hệ thống 3.3. Thiết kế chi tiết z 3.3.2. Phân hoạch và cấu trúc các chức năng: • Các chức năng được định nghĩa qua việc phát triển các hệ thống con trong giai đoạn thiết kế ngoài phải được xác định và việc thiết kế chương trình cho từng thao tác phải được chuẩn bị • Hai bước: Bước phân hoạch và bước cấu trúc chức năng 3.3. Thiết kế chi tiết z 3.3.2 Phân hoạch và cấu trúc các chức năng (tiếp): • Trong giai đoạn thiết kế ngoài, hệ con được phân hoạch thành các chức năng. Trong giai đoạn thiết kế trong, hệ con được phân hoạch thành các chương trình dựa trên các chức năng của nó. • Thứ tự thực hiện chương trình được xác định để cài đặt các chức năng và để thực hiện các thao tác một cách có hiệu quả. 3.3. Thiết kế chi tiết z Thủ tục phân hoạch & cấu trúc chức năng • Nghiên cứu kỹ các chức năng • Làm rõ luồng dữ liệu • Gộp nhóm chức năng • Thiết lập cấu trúc phân cấp 3.3. Thiết kế chi tiết z Thủ tục phân hoạch & cấu trúc chức năng • Trả lời 3 câu hỏi • WHY: “Tại sao từng hệ con được phân chia trong giai đoạn thiết kế ngoài phải được làm rõ” • WHAT: “Cái gì xác định chức năng của hệ con” gồm có • Chức năng của hệ con được chia ra làm nhiều chức năng • Các chức năng gộp nhóm • Xác định 1 chức năng mà từng nhóm thực hiện • HOW: “Thủ tục cho việc phát triển chức năng cho từng nhóm” 3.3. Thiết kế chi tiết z Cấu trúc chức năng • Các chức năng chi tiết của chương trình được kiểm điểm • Dữ liệu truyền trong chương trình phải được làm rõ • Thủ tục xử lý chương trình được xác định 3.3. Thiết kế chi tiết z 3.3.3 Thiết kế dữ liệu vật lý z Thiết kế đường truy nhập CSDL, soạn thảo và tổ chức dữ liệu vật lý dựa trên thiết kế dữ liệu logic của thiết kế ngoài. z Quy trình: • Phân tích các đặc trưng dữ liệu • Xác định cấu trúc, tổ chức logic của tệp • Xác định cấu trúc, tổ chức vật lý của tệp • Xác định các phương tiện lưu trữ dữ liệu • Thiết kế tổ chức các khoản mục dữ liệu 3.3. Thiết kế chi tiết z 3.3.3 Thiết kế dữ liệu vật lý z Phân tích đặc trưng dữ liệu • Các đặc trưng của việc dùng dữ liệu: chính hay giao tác, thời gian duy trì • Các thao tác thêm xóa hay thay đổi dữ liệu và khối lượng dữ liệu • Cách thức dữ liệu được dùng: batch or online 3.3. Thiết kế chi tiết z 3.3.3 Thiết kế dữ liệu vật lý z Xác định hệ thống tổ chức dữ liệu trong cấu trúc logic • Liệu hệ thống tổ chức DL vật lý có cho phép tổ chức theo cấu trúc logic không? • Chấp nhận: Hệ thống cho cấu trúc thành phần logic trước tiên rồi đến thiết kế cấu trúc vật lý • Không chấp nhận: Ngược lại 3.3. Thiết kế chi tiết z 3.3.3 Thiết kế dữ liệu vật lý z Xác định phương tiện lưu trữ dữ liệu • Xác định phương tiện lưu trữ • Tính dung lượng nhớ và thời gian truy cập: chú ý tới kiểu bản ghi • Thiết kế cách bố trí các bản ghi 3.3. Thiết kế chi tiết z 3.3.4.Thiết kế vào/ra chi tiết • Sự phù hợp của quá trình Vào/Ra dữ liệu với các quá trình khác • Tính toán các hạn chế liên quan đến phần cứng • Để ý tới việc giải quyết lỗi dữ liệu vào • Đảm bảo dễ bảo trì và tính đúng đắn của phương tiện vào/ra 3.3. Thiết kế chi tiết z 3.3.4.Thiết kế vào/ra chi tiết z Thiết kế màn hình: Là nhân tố quan trọng để NSD đánh giá hệ thống tốt hay tồi • Thủ tục: • Bố trí màn hình để các chức năng được đáp ứng và mức độ thành thạo của người dùng phải được làm rõ • Màn hình bản mẫu được tạo ra bằng ngôn ngữ trực quan • Người dùng đánh giá màn hình bản mẫu và cải tiến sửa đổi để hoàn chỉnh thiết kế màn hình 3.3. Thiết kế chi tiết z 3.3.4.Thiết kế vào/ra chi tiết z Thiết kế ra chi tiết: Là việc thiết kế hiển thị dữ liệu kết quả. Các mẫu đưa ra kết quả phải được thiết kế sao cho dễ hiểu và dễ dùng cho thao tác xử lý dữ liệu sau này z Thủ tục: • Xác định vị trí tiêu đề và các dòng chi tiết • Xác định vị trí của khoản mục dữ liệu và định dạng • Bố trí các khoản mục khoa học 3.3. Thiết kế chi tiết z 3.3.5.Tạo và dùng lại các bộ phận z 2 loại thách thức đối với reuse: • Thách thức về “tìm kiếm”, “đăng ký”, “thay đổi” • Thách thức về “sự nhất quán”, “hệ thống hóa”, “tính độc lập của các bộ phận” z Tiếp cận hướng đối tượng là thích hợp cho việc dùng lại các sản phẩm công việc 3.3. Thiết kế chi tiết z 3.3.5.Tạo và dùng lại các bộ phận z Lựa chọn đơn vị xử lý có thể tạo thành phần tái sử dụng -> tập trung các thông tin về thành phần đó z Phân tích và tổ chức lại thông tin đã thu nhận z Đặc tả thành phần z Tạo thành phần tái sử dụng như là tạo 1 bộ phận thông thường z Viết documentation để third party có thể sử dụng 3.3. Thiết kế chi tiết z 3.3.5.Tạo và dùng lại các bộ phận z Thiết lập thư viện các chương trình con: Các chương trình con được cung cấp như là các gói thông thường. z Thiết lập thư viện lớp: Do đặc thù của phát triển hướng đối tượng reuse được thực hiện dễ dàng bằng các thư viện lớp 3.3. Thiết kế chi tiết z 3.3.6.Tạo tài liệu thiết kế trong z Thiết kế trong được chuẩn bị dựa trên tài liệu thiết kế ngoài ghi lại các dữ liệu trong quá trình thiết kế trong z Có nhiệm vụ thỏa mãn mọi yêu cầu người dùng do thiết kế ngoài xác định 3.3. Thiết kế chi tiết z 3.3.6.Tạo tài liệu thiết kế trong Kế hoạch kiểm thử Hiệu năng hệ thống Cấu hình tệp Bố trí vào/ra Bố trí màn hình Chức năng chương trình Cấu hình hệ thống Chính sách thiết kế trong 3.3. Thiết kế chi tiết z 3.3.6.Tạo tài liệu thiết kế trong • Chính sách thiết kế trong: Phương pháp thiết kế, kỹ thuật làm tài liệu • Cấu hình hệ thống: Luồng và cấu trúc hệ thống, giao diện giữa các chương trình, tổng quan vận hành • Chức năng chương trình: Mô tả các hệ con và chức năng của từng đơn vị • Bố trí màn hình: Toàn cảnh về màn hình và biểu đồ chuyển màn hình 3.3. Thiết kế chi tiết z 3.3.6.Tạo tài liệu thiết kế trong • Báo cáo bố trí vào/ra: Thiết kế tài liệu đưa vào và đưa ra • Cấu hình tệp: DS tệp dùng trong hệ thống, chi tiết về tên, dung lượng, cách bố trí… • Hiệu năng hệ thống: Tính toán khối lượng DL sinh ra và dữ liệu vào giờ G cộng với thời gian xử lý dữ liệu • Kế hoạch kiểm thử: Mô tả kế hoạch kiểm thử 3.3. Thiết kế chi tiết z 3.3.7.Xét duyệt thiết kế trong • Làm hợp lệ rằng yêu cầu của ngườii dùng được thỏa mãn • Kiểm chứng tính nhất quán với thiết kế ngoài. Đảm bảo dữ liệu thiết kế trong đã chuẩn bị có thể được trao cho giai đoạn thiết kế chương trình. 3.3. Thiết kế chi tiết z 3.3.7.Xét duyệt thiết kế trong • Được tổ chức thành cuộc họp được chuẩn bị trước kế hoạch, đầy đủ về tài liệu và danh sách kiểm điểm • Do đặc thù của thiết kế trong nên cuộc họp kiểm duyệt nên có sự tham dự của người sử dụng 3.4. Thiết kế phần mềm z Là một tiến trình quan trọng vì nó làm cho các nhiệm vụ lập trình trở lên trôi chảy, dễ dàng. z Nhiệm vụ chính là phân hoạch module đơn vị chức năng được xác định trong thiết kế trong. z Nội dung tài liệu thiết kế trong phải được hiểu thấu đáo. 3.4. Thiết kế phần mềm z Là một tiến trình quan trọng vì nó làm cho các nhiệm vụ lập trình trở lên trôi chảy, dễ dàng. z Nhiệm vụ chính là phân hoạch module đơn vị chức năng được xác định trong thiết kế trong. z Nội dung tài liệu thiết kế trong phải được hiểu thấu đáo. 3.4. Thiết kế phần mềm z Để thiết kế kiến trúc trong của một chương trình z Phương pháp thiết kế cấu trúc phân chia chương trình thành các module z Các đối tượng được phân chia trong phát triển hệ thống: Hệ thống–Hệ thống con– Giao dịch/công việc–Chương trình– module-Thủ tục/Hàm-Lệnh 3.4. Thiết kế phần mềm z Quy trình thiết kế chương trình 1. Xác nhận tài liệu thiết kế chi tiết 2. Phân chia module 3. Chuẩn bị đặc tả module 4. Chuẩn bị tài liệu thiết kế chương trình 5. Chuẩn bị các đặc tả kiểm thử 6. Xét duyệt thiết kế 3.4. Thiết kế phần mềm 3.4.1. Xác nhận tài liệu thiết kế chi tiết z Đảm bảo tính nhất quán của công việc thiết kế (thiết kế ngoài, thiết kế trong, thiết kế chương trình) z Xem xét • Định nghĩa các hàm (what to do) • Thông tin đầu vào (what to input) • Các xử lý (what type of processing) • Output (what to output) 3.4. Thiết kế phần mềm 3.4.2. Phân chia module z Đảm bảo tính độc lập module z Nâng cao hiệu năng xử lý • Giảm thiểu mối quan hệ với các module khác -> hiệu năng tăng z Tạo lập và tái sử dụng các thành phần z Nâng cao độ tin cậy và độ hiệu quả của việc bảo trì • Khi thay đổi hệ thống chỉ cần thay đổi module cần thiết 3.4. Thiết kế phần mềm 3.4.3 Chuẩn bị đặc tả module z Xác định nội dung mà mỗi module cần xử lý z Cần phải rất tỉ mỉ, chi tiết, tránh thiếu hụt chức năng 3.4. Thiết kế phần mềm 3.4.4. Chuẩn bị tài liệu thiết kế chương trình z Tài liệu này tổng hợp các kết quả của 3 bước trước, là chỉ dẫn cho công việc coding z Mô tả: • Đường lối thiết kế chương trình • Tổng quan chương trình • Lược đồ cấu trúc chương trình (PSD) • Các chi tiết xử lý • Test case • Mô tả các khoản mục cần thiết 3.4. Thiết kế phần mềm 3.4.5. Chuẩn bị các đặc tả kiểm thử z Được chuẩn bị dựa theo mục đích của từng loại kiểm thử • Kiểm thử đơn vị (unit test) • Kiểm thử tích hợp (integration test) 3.4. Thiết kế phần mềm 3.4.6 Xét duyệt thiết kế z Mục đích • Xác nhận các yêu cầu người dùng • Thẩm tra tính nhất quán với thiết kế trong, và xem đã sẵn sàng chuyển sang giai đoạn lập trình chưa z Các điểm cần lưu ý • Phải kiểm tra các nội dung của tài liệu thiết kế chương trình, so sánh với tài liệu thiết kế trong, chỉ ra các chức năng còn thiếu • Xác nhận việc phân chia module đã được thực hiện đúng đắn • Kiểm tra sự đầy đủ và nhất quán về giao diện giữa các module 3.4. Thiết kế phần mềm 3.4.7. Trình tự thiết kế cấu trúc hóa Xác định module mức cao nhất Phân tích chức năng mỗi module Xác định giao diện giữa các module Chọn phương pháp phân chia Program -> Modules Phân chia END + - 3.4. Thiết kế phần mềm (1) Xác định mô-đun mức cao nhất z Là module được gọi khi chương trình bắt đầu z Thông thường nó thực hiện các chức năng • Điều khiển toàn bộ chương trình • Thiết lập giá trị khởi tạo cho mỗi item • Mở và đóng file 3.4. Thiết kế phần mềm (2) Phân tích chức năng cho mỗi mô-đun • Xác định mọi chức năng cần để chạy chương trình • Chúng có thể được phân chia tiếp hoặc kết hợp lại • Các chức năng • Đọc file • Kiểm tra lỗi đầu vào • Xư lý dữ liệu • Ra dữ liệu • Kiểm soát lỗi 3.4. Thiết kế phần mềm z (3) Chọn phương pháp phân chia module z Theo luồng dữ liệu: phù hợp cho các hệ thống giao dịch trực tuyến • Phân chia STS • Phân chia TR • Phương pháp phân chia các chức năng dùng chung z Theo cấu trúc dữ liệu: thích hợp cho xử lý theo lô (khi chủ yếu làm việc với file) • Phương pháp Jackson • Phương pháp Wanier 3.4. Thiết kế phần mềm z Phân chia chương trình thành các module z Các mức module được phân chia bằng cách xác định module mức cao và sau đó xác định các module được gọi từ module đó z Các thông số cần quan tâm • Số module mỗi mức nên ≤ 10 • Chiều sâu phân cấp nên ≤ 4 Xác định giao diện giữa các module z Mô tả dữ liệu, các điều kiện cần thiết để truyền dữ liệu giữa các module z Khuyến cáo: số khoản mục dữ liệu truyền qua một giao diện nên ≤ 8 Các phương pháp phân chia module z Kỹ thuật phân chia dựa vào luồng dữ liệu • Phương pháp STS • Phương pháp TR • Phương pháp phân chia chức năng chung z Phân chia hướng cấu trúc dữ liệu • Phương pháp Jackson • Phương pháp Warnier Phương pháp STS z Chương trình được chia thành 3 phần: • Source: hàm xử lý đầu vào • Transform: hàm xử lý dữ liệu • Sink: xử lý đầu ra z Thích hợp với các module mức cao chứa các chức năng vào, xử lý và ra dữ liệu Phương pháp TR (transaction) z Được sử dụng khi kiểu giao dịch có thể được xác định qua kiểu dữ liệu: nhóm các module theo kiểu giao dịch Phương pháp chức năng chung z Được dùng khi có các module có các chức năng chung Tìm tệp nhân viên Tìm bản ghi nhân viên thích hợp Tìm giao dịch vào thích hợp Hiển thị thông điệp lỗi Hiển thị bản ghi lên màn hình Phương pháp Jackson z Các module được phân chia theo sự liên hệ cấu trúc chương trình và cấu trúc của dữ liệu vào/ra z Ký pháp A C D E B G I F J H Cấu trúc chương trình theo JS Phương pháp Warnier z Dựa vào lý thuyết tập (set theory) z Dược sử dụng rộng rãi trong xử lý file và các ứng dụng doanh nghiệp z Cơ sở: là phân tích dữ liệu z Phân tích trên xuống dựa vào “khi nào, ở đâu và bao nhiêu lần” z JS: dựa chủ yếu vào dữ liệu ra Warnier: dựa vào dữ liệu vào Tiêu chuẩn phân chia module z Độ mạnh (strength) của module z Kết nối (coupling) module z Tiêu chuẩn về kích thước z Tạo ra và dùng lại các bộ phận Độ mạnh của module z Sắp xếp theo mức độ tăng dần (tính độc lập module cũng tăng dần): • Độ mạnh trùng hợp (coincidential strength) • Độ mạnh logic (logical strength) • Độ mạnh thời gian (time strength) • Độ mạnh thủ tục (procedural strength) • Độ mạnh giao tiếp (communicative strength) • Độ mạnh thông tin (informâtionl strength) • Độ bền chức năng (functional strength) Độ kết nối module z Các module càng độc lập nhau độ kết nối càng thấp z Theo chiều giảm dần • Kết nối nội dung (content) • Kết nối chung (common) • Kết nối ngoại (external) • Kết nối điều khiển (control) • Kết nối dấu (stamp) • Kết nối dữ liệu (data) Các tiêu chí về kích thước z Với chương trình nhỏ, cấu trúc tốt (200- 300 lệnh NN bậc cao được thực thi): trung bình là 30 lệnh z Chương trình trung bình (2000-3000): trung bình 40-50 lệnh z Chương trình lớn (≥10,000): 100-150 lệnh z Module theo độ mạnh thông tin (xét riêng): 40-50 Phân hoạch chương trình z Độ rộng và chiều sâu cho cây phân cấp module toàn bộ chương trình nên ≤10 Đặc tả module z Thiết kế logic module: các chi tiết xử lý được thực thi bởi mỗi module z Các bước • Phân tích cấu trúc dữ liệu • Phân lớp cấu trúc dữ liệu • Xây dựng giải thuật • Thường được tài liệu hóa dạng mã giả pseudo- codes Đặc tả test z Trong giai đoạn thiết kế chương trình • unit test: kiểm định cấu trúc logic của module, sử dụng white-box test • Integration test: kiểm tra giao diện giữa các module, sử dụng black-box test z Các điểm quan trọng • Test case: không chỉ là dữ liệu test mà còn là kế hoạch test và các tài liệu khác. • Dữ liệu test chuẩn bị cần xem xét kỹ thuật test, chuẩn bị cả dữ liệu lỗi • Năng suất tỷ lệ nghịch với độ phủ: nên cần thiết kế dữ liệu test sao cho cân bằng năng suất và chất lượng test Tạo tài liệu thiết kế chương trình z Nội dung gồm • Đường lối thiết kế chương trình • Tổng quan chương trình • Lược đồ cấu hình chương trình • Các chi tiết xử lý • Các đặc tả test • Mô tả các khoản mục dữ liệu Tạo tài liệu thiết kế chương trình (tiếp) z Các điểm quan trọng cần lưu ý • Các chức năng mô tả trong tài liệu thiết kế trong cần phải được mô tả trong tài liệu thiết kế chương trình • Mọi dữ liệu vào/ra đều phải được mô tả rõ ràng • Mô tả rõ ràng mọi quy tắc xử lý lỗi Xét duyệt thiết kế z Các