Chương 2. Thiết kế phần mềm (Software Design)

1THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM (SOFTWARE DESIGN AND CONSTRUCTION) Năm học 2008-2009 Giáo viên: PGS.Huỳnh Quyết Thắng BM Công nghệ phần mềm Khoa CNTT, ĐHBK HN 2Chương 2. Thiết kế phần mềm (Software Design) 1. Các khái niệm căn bản trong thiết kế phần mềm 2. Thiết kế kiến trúc phần mềm (Software Architectrure Design) 3. Các chiến thuật và phương pháp thiết kế phần mềm 4. Xây dựng các đặc tả thiết kế phần mềm (Software Design Specification) 5. Giới thiệu một số tài liệu liên quan đến nội dung chương 6. Câu hỏi và bài tập 32.1. Các khái niệm cơ bản trong thiết kế phần mềm • Khái niệm • Nhiệm vụ • Quy trình • Các kỹ thuật trong thiết kế phần mềm 42.1. Các khái niệm cơ bản trong thiết kế phần mềm • Khái niệm: Thiết kế phần mềm được định nghĩa trong IEEE610.12-90 bao gồm: Quá trình xác định kiến trúc, các thành phần, giao diện và các đặc tính kỹ thuật của hệ thống hoặc thành phần . • Thiết kế phần mềm sẽ là cơ sỏ cho giai đoạn tiếp theo là xây dựng phần mềm. • Thiết kế phần mềm đóng vai trò quan trọng trong phát triển phần mềm: • Cho phép xem xét, so sánh các phương án kỹ thuật khác nhau trong thiết kế phần mềm • Cho phép xác định phương án phù hợp nhất với các yêu cầu phần mềm • Cho phép lập các kế hoạch chi tiết cho giai đoạn xây dựng phần mềm 52.1. Các khái niệm cơ bản trong thiết kế phần mềm • Nhiệm vụ: Theo IEEE/EIA 12207 Software Life Cycle Processes và [IEEE12207.0-96], Thiết kế phần mềm có hai nhiệm vụ chính: • Thiết kế kiến trúc phần mềm - Software architectural design (Một số tài liệu phân tích thiết kế còn gọi nhiệm vụ này là Thiết kế phần mềm mức cao - Toplevel design): Xác định mô hình mức cao của phần mềm, xác định các thành phần của mô hình. • Thiết kế chi tiết phần mềm - Software detailed design: thiết kế chi tiết từng thành phần, xác định đầy đủ các thông tin tương ứng cho từng thành phần để có thể tiến hành xây dựng phần mềm. 62.1. Các khái niệm cơ bản trong thiết kế phần mềm • Quy trình: Thiết kế phần mềm được chia làm hai tiến trình công việc: • Thiết kế kiến trúc phần mềm - Architectural Design mục đích xác định mô hình kiến trúc và các thành phần trong kiến trúc IEEEP1471-00 • Thiết kế chi tiết - Detailed Design mục đích xác định các đặc tính kỹ thuật và đặc tả các thành phần của kiến trúc phần mềm. IEEE1016-98 72.1. Các khái niệm cơ bản trong thiết kế phần mềm • Các kỹ thuật trong thiết kế phần mềm: • Abstraction • Coupling and cohesion • Decomposition and modularization • Encapsulation/information hiding • Separation of interface and implementation • Sufficiency, completeness and primitiveness 82.1. Các khái niệm cơ bản trong thiết kế phần mềm • Các kỹ thuật trong thiết kế phần mềm: • Abstraction: is “the process of forgetting information so that things that are different can be treated as if they were the same”. [Lis01] In the context of software design, two key abstraction mechanisms are parameterization and specification. Abstraction by specification leads to three major kinds of abstraction: procedural abstraction, data abstraction and control (iteration) abstraction. 92.1. Các khái niệm cơ bản trong thiết kế phần mềm • Các kỹ thuật trong thiết kế phần mềm: • Coupling and cohesion: Coupling is defined as the strength of the relationships between modules, whereas cohesion is defined by how the elements making up a module are related. • Decomposition and modularization: Decomposing and modularizing large software into a number of smaller independent ones, usually with the goal of placing different functionalities or responsibilities in different components. 10 2.1. Các khái niệm cơ bản trong thiết kế phần mềm • Các kỹ thuật trong thiết kế phần mềm: • Separation of interface and implementation: Separating interface and implementation involves defining a component by specifying a public interface, known to the clients, separate from the details of how the component is realized. • Sufficiency, completeness and primitiveness: Achieving sufficiency, completeness, and primitiveness means ensuring that a software component captures all the important characteristics of an abstraction, and nothing more. 11 Chương 2. Thiết kế phần mềm (Software Design) 1. Các khái niệm căn bản trong thiết kế phần mềm 2. Thiết kế kiến trúc phần mềm (Software Architectrure Design) 3. Các chiến thuật và phương pháp thiết kế phần mềm 4. Xây dựng các đặc tả thiết kế phần mềm (Software Design Specification) 5. Giới thiệu một số tài liệu liên quan đến nội dung chương 6. Câu hỏi và bài tập 12 2.2. Thiết kế kiến trúc phần mềm • Định nghĩa Kiến trúc phần mềm • Xác định các yêu cầu đối với kiến trúc phần mềm • Xây dựng kiến trúc phần mềm • Phần cứng • Phần mềm • Các phần mềm tiện ích trợ giúp • Một số kỹ thuật tiêu biểu thiết kế kiến trúc phần mềm • Đánh giá và kiểm thử kiến trúc phần mềm • Các phương pháp kiểm thử kiến trúc phần mềm • Các tiêu chí đánh giá chất lượng kiến trúc phần mềm 13 2.2. Thiết kế kiến trúc phần mềm • Định nghĩa Kiến trúc phần mềm • Một số kỹ thuật tiêu biểu thiết kế kiến trúc phần mềm • Đánh giá và kiểm thử kiến trúc phần mềm • Các phương pháp kiểm thử kiến trúc phần mềm • Các tiêu chí đánh giá chất lượng kiến trúc phần mềm 14 2.2. Thiết kế kiến trúc phần mềm • Định nghĩa Kiến trúc phần mềm: Kiến trúc phần mềm bao gồm hệ thống các thành phần (components) và các mối quan hệ (relations). Thuật ngữ thành phần có thể là hệ thống con (subsystems), các quy trình (processes), các mô đun phần mềm (software modules), các thành phần phần cứng (hardware components)… Các mối quan hệ gồm luồng dữ liệu (data flows), luồng điều khiển (control flows), các mối quan hệ triệu gọi (call-relation)… 15 2.2. Thiết kế kiến trúc phần mềm • Định nghĩa kiến trúc phần mềm: • "The logical and physical structure of a system, forged by all the strategic and tactical design decisions applied during development" [Booch 91] • The structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. [Garlan 95] • "The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them." [Bass 98] 16 2.2. Thiết kế kiến trúc phần mềm Prospectus Requirements Architecture High-Level Design Low-Level Design Planning and Architecture Phase Discovery Review Architecture Review Source: Joe Maranzano ATT Bell Labs 17 2.2. Thiết kế kiến trúc phần mềm Một số kỹ thuật tiêu biểu thiết kế kiến trúc phần mềm (Meta-Model for Architecture Design Approaches): z Artifact-driven Architecture Design z Use-Case driven Architecture Design z Domain-driven Architecture Design z Pattern-driven Architecture Design 18 Meta-Model for Architecture Design Approaches(1/3) 19 Meta-Model for Architecture Design Approaches(2/3) z Client: những người được quan tâm trong phát triển của một thiết kế kiến trúc phần mềm gồm: khách hàng (customer), người sử dụng cuối (end-user), người phát triển hệ thống (system developer), người bảo trì hệ thống (system maintainer), người quản lý việc bán (sales manager) … z Domain Knowledge: vùng kiến thức để giải quyết một vấn đề nào đó. z Requirement Specification: xác định việc mô tả các yêu cầu cho kiến trúc được phát triển. z Artifact: mô tả cho một phương thức nào đó (Class, Operation, Attribute ) z … 20 Meta-Model for Architecture Design Approaches(3/3) Domain Knowledge 21 Artifact-driven Architecture Design (1/2) Mô hình mức khái niệm 22 Artifact-driven Architecture Design (2/2) Problems z “Textual requirements are imprecise, ambiguous or incomplete and are less useful as a source for deriving architectural abstractions”(các yêu cầu mơ hồ, nhập nhằng, hoặc không đầy đủ và ít khi hữu ích) z Subsystems have poor semantics to serve as architectural components (các hệ thống con nghèo nàn ngữ nghĩa để phục vụ như là các thành phần kiến trúc ) z Composition of subsystems is not well-supported (kết cấu của hệ thống con không được hỗ trợ tốt) 23 Use-Case driven Architecture Design (1/2) Mô hình mức khái niệm 24 Use-Case driven Architecture Design (2/2) Problems z Leveraging detail of domain model and business model is difficult z Selecting architecturally relevant use-cases is not systematically supported z Use-cases do not provide a solid basis for architectural abstractions z Package construct has poor semantics to serve as an architectural component 25 Domain-driven Architecture Design (1/3) Mô hình mức khái niệm 26 Domain-driven Architecture Design (2/3) Product-line Architecture Design 27 Domain-driven Architecture Design (3/3) Domain Specific Software Architecture Design 28 Pattern-driven Architecture Design (1/3) Mô hình mức khái niệm 29 Pattern-driven Architecture Design (2/3) Mô tả quy trình Để xác nhận pattern, mục đích (intent) của pattern sẵn có sẽ được kiểm tra kỹ. Nếu mục đích của pattern được tìm thấy phù hợp cho vấn đề đã được đưa ra thì mô tả ngữ cảnh (Context) được phân tích. Nếu pattern này phù hợp với ngữ cảnh của vấn đề đưa ra thì tiếp theo gọi hàm 3:Apply, khi đó sub-concept là Solution được khởi tạo để cung cấp một giải pháp cho vấn đề. Cuối cùng hàm 4:Compose để hợp nhất mẫu kiến trúc (architecture pattern) thành mô tả kiến trúc (architecture description.) 30 Pattern-driven Architecture Design (3/3) Problems: z Pattern base may not be sufficient for dealing with the wide range of architectural abstractions z Selecting patterns is merely based on the general knowledge and experience of the software engineer z Applying patterns is not straightforward and requires thorough analysis of the problem z Composing patterns is not well-supported 31 Các phương pháp phân tích kiến trúc phần mềm z SAAM (Software Architecture Analysis Method) z ASAAM (Aspectual Software Architecture Analysis Method) z SAAMCS z ESAAMI z SAAMER z ATAM z .... 32 Chương 2. Thiết kế phần mềm (Software Design) 1. Các khái niệm căn bản trong thiết kế phần mềm 2. Thiết kế kiến trúc phần mềm (Software Architectrure Design) 3. Các chiến thuật và phương pháp phân tích kiến trúc phần mềm 4. Xây dựng các đặc tả thiết kế phần mềm (Software Design Specification) 5. Câu hỏi và bài tập 6. Giới thiệu một số tài liệu liên quan đến nội dung chương 33 3. Các chiến thuật và phương pháp phân tích kiến trúc phần mềm z There exist various general strategies to help guide the design process. z General Strategies: Some often-cited examples of general strategies useful in the design process are: • Divide-and-conquer and stepwise refinement • Top-down vs. bottom-up strategies, • Data abstraction and information hiding • Use of heuristics • Use of patterns and pattern languages • Use of an iterative and incremental approach. 34 3. Các chiến thuật và phương pháp phân tích kiến trúc phần mềm z In contrast with general strategies, methods are more specific in that they generally suggest and provide a set of notations to be used with the method, a description of the process to be used when following the method and a set of guidelines in using the method. • Function-oriented (structured) Design • Object-oriented Design • Data-structure Centered Design • Component-based Design (CBD) 35 Chương 2. Thiết kế phần mềm (Software Design) 1. Các khái niệm căn bản trong thiết kế phần mềm 2. Thiết kế kiến trúc phần mềm (Software Architectrure Design) 3. Các chiến thuật và phương pháp thiết kế phần mềm 4. Xây dựng các đặc tả thiết kế phần mềm (Software Design Specification) 5. Câu hỏi và bài tập 6. Giới thiệu một số tài liệu liên quan đến nội dung chương 36 4. Xây dựng các đặc tả thiết kế phần mềm z The software architecture for a system plays a central role in system development and in the organization that produces it. The architecture serves as the blueprint for both the system and the project developing it. It defines the work assignments that must be carried out by design and implementation teams and it is the primary carrier of system qualities such as performance, modifiability, and security—none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. Moreover, architecture holds the key to post-deployment system understanding, maintenance, and mining efforts. In short, architecture is the conceptual glue that holds every phase of the project together for all of its many stakeholders. 37 4. Xây dựng các đặc tả thiết kế phần mềm z Documenting the architecture is the crowning step to crafting it. Even a perfect architecture is useless if no one understands it or (perhaps worse) if key stakeholders misunderstand it. If you go to the trouble of creating a strong architecture, you must describe it in sufficent detail, without ambiguity, and organized in such a way that others can quickly find needed information. Otherwise, your effort will have been wasted because the architecture will be unusable 38 4. Xây dựng các đặc tả thiết kế phần mềm z The architecture for a system depends on the requirements levied on it, so too does the documentation for an architecture depend on the requirements levied on it—that is, how we expect it will be used. Documentation is decidedly not a case of "one size fits all." It should be sufficiently abstract to be quickly understood by new employees but sufficiently detailed to serve as a blueprint for analysis. The architectural documentation for, say, security analysis may well be different from the architectural documentation we would hand to an implementor. And both of these will be different from what we put in a new hire's familiarization reading list. 39 4. Xây dựng các đặc tả thiết kế phần mềm z Architecture documentation is both prescriptive and descriptive. That is, for some audiences it prescribes what should be true by placing constraints on decisions to be made. For other audiences it describes what is true by recounting decisions already made about a system's design. z All of this tells us that different stakeholders for the documentation have different needs—different kinds of information, different levels of information, and different treatments of information. We should not expect to produce one architectural document and have every consumer read it in the same way. 40 4. Xây dựng các đặc tả thiết kế phần mềm z This might mean producing different documents for different stakeholders. More likely, it means producing a single documentation suite with a roadmap that will help different stakeholders navigate through it. z Perhaps the most important concept associated with software architecture documentation is the view. z The concept of a view, which you can think of as capturing a structure, provides us with the basic principle of documenting software architecture: Documenting an architecture is a matter of documenting the relevant views and then adding documentation that applies to more than one view. 41 4. Xây dựng các đặc tả thiết kế phần mềm z Other views are available. A view simply represents a set of system elements and relationships among them, so whatever elements and relationships you deem useful to a segment of the stakeholder community constitute a valid view. Here is a simple three-step procedure for choosing the views for your project. • Produce a candidate view list. • Combine views. The candidate view list from step 1 is likely to yield an impractically large number of views. • Prioritize. After step 2 you should have an appropriate set of views to serve your stakeholder community. 42 4. Xây dựng các đặc tả thiết kế phần mềm z Documenting a View z There is no industry-standard template for documenting a view, but the seven-part standard organization that we suggest in this section has worked well in practice. First of all, whatever sections you choose to include, make sure to have a standard organization. Allocating specific information to specific sections will help the documentation writer attack the task and recognize completion, and it will help the documentation reader quickly find information of interest at the moment and skip everything else. 43 4. Xây dựng các đặc tả thiết kế phần mềm z Documenting a View z (1) Primary presentation shows the elements and the relationships among them that populate the view. The primary presentation should contain the information you wish to convey about the system (in the vocabulary of that view) first. It should certainly include the primary elements and relations of the view, but under some circumstances it might not include all of them. For example, you may wish to show the elements and relations that come into play during normal operation, but relegate error handling or exceptional processing to the supporting documentation. 44 4. Xây dựng các đặc tả thiết kế phần mềm z Documenting a View z (2) Element catalog details at least those elements and relations depicted in the primary presentation, and perhaps others. Producing the primary presentation is often what architects concentrate on, but without backup information that explains the picture, it is of little value z (3) Context diagram shows how the system depicted in the view relates to its environment in the vocabulary of the view. For example, in a component-and-connector view you show which component and connectors interact with external components and connectors, via which interfaces and protocols. 45 4. Xây dựng các đặc tả thiết kế phần mềm z Documenting a View z (4) Variability guide shows how to exercise any variation points that are a part of the architecture shown in this view. In some architectures, decisions are left unbound until a later stage of the development process, and yet the architecture must still be documented. z (5) Architecture background explains why the design reflected in the view came to be. The goal of this section is to explain to someone why the design is as it is and to provide a convincing argument that it is sound. An architecture background includes: -rationale, explaining why the decisions reflected in the view were made and why alternatives were rejected; analysis results, which justify the design or explain what would have to change in the face of a modification.;assumptions reflected in the design. 46 4. Xây dựng các đặc tả thiết kế phần mềm z Documenting a View z (6) Glossary of terms used in the views, with a brief description of each z (7) Other information. The precise contents of this section will vary according to the standard practices of your organization. They might include management information such as authorship, configuration control data, and change histories. Or the architect might record references to specific sections of a requirements document to establish traceability. Strictly speaking, information such as this is not architectural. Nevertheless, it is convenient to record it alongside the architecture, and this section is provided for that purpose. In any case, the first part of this section must detail its specific contents 47 4. Xây dựng các đặc tả thiết kế phần mềm z DOCUMENTING BEHAVIOR z Behavior can be documented either about an element or about an ensemble of elements working in concert. Exactly what to model will depend on the type of system being designed. For example, if it is a real-time embedded system, you will need to say a lot about timing properties