THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM- Chương 3: Xây dựng phần mềm

Khái niệm Xây dựng phần mềm 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) 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ử...
Nội dung trích xuất từ tài liệu:
THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM- Chương 3: Xây dựng phần mềm THIẾ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 1 Chươ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 2 3.1.Khái niệm Xây dựng phần mềm 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) 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 Component-based software engineering (CBSE) is an approach to software development that relies on reuse It emerged from the failure of object-oriented development to support effective reuse. Single object classes are too detailed and specific 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 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 Components can range in size from simple functions to entire application systems Component interfaces Requires interface Component Provides interface Component interfaces Provides interface • Defines the services that are provided by the component to other components Requires interface • Defines the services that specifies what services must be made available for the component to execute as specified Printing services component Requires interface PrintService Provides interface GetPDfile Print GetQueue PrinterInt Remove Transfer Register Unregister Component abstractions Functional abstraction • The component implements a single function such as a mathematical function Casual groupings • The component is a collection of loosely related entities that might be data declarations, functions, etc. Data abstractions • The component represents a data abstraction or class in an object-oriented language Cluster abstractions • The component is a group of related classes that work together System abstraction • The component is an entire self-contained system CBSE processes Component-based development can be integrated into a standard software process by incorporating a reuse activity in the process However, in reuse-driven development, the system requirements are modified to reflect the components that are available CBSE usually involves a prototyping or an incremental development process with components being ‘glued together’ using a scripting language An opportunistic reuse process Design Search for Incorporate Specify system reusable discovered components aachitecture components components Development with reuse Modify requirements Outline Search for according to system reusable discovered requirements components components Specify system Search for components Architectural reusable based on reusable design components components CBSE problems Component incompatibilities may mean that cost and schedule savings are less then expected Finding and understanding components 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 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. Đố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. 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 Đặ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 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 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ý ...