THIẾ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 Chương Thiết kế phần mềm (Software Design) Các khái niệm thiết kế phần mềm Thiết kế kiến trúc phần mềm (Software Architectrure Design) Các chiến thuật phương pháp thiết kế phần mềm Xây dựng đặc tả thiết kế phần mềm (Software Design Specification) Giới thiệu số tài liệu liên quan đến nội dung chương Câu hỏi tập 2.1 Các khái niệm thiết kế phần mềm • • • • Khái niệm Nhiệm vụ Quy trình Các kỹ thuật thiết kế phần mềm 2.1 Các khái niệm thiết kế phần mềm • • • Khái niệm: Thiết kế phần mềm định nghĩa IEEE610.12-90 bao gồm: Quá trình xác định kiến trúc, thành phần, giao diện đặc tính kỹ thuật hệ thống thành phần Thiết kế phần mềm sỏ cho giai đoạn xây dựng phần mềm Thiết kế phần mềm đóng vai trị quan trọng phát triển phần mềm: • Cho phép xem xét, so sánh phương án kỹ thuật khác thiết kế phần mềm • Cho phép xác định phương án phù hợp với yêu cầu phần mềm • Cho phép lập kế hoạch chi tiết cho giai đoạn xây dựng phần mềm 2.1 Các khái niệm thiết kế phần mềm • Nhiệm vụ: Theo IEEE/EIA 12207 Software Life Cycle Processes [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ụ Thiết kế phần mềm mức cao Toplevel design): Xác định mơ hình mức cao phần mềm, xác định thành phần mơ hình Thiết kế chi tiết phần mềm - Software detailed design: thiết kế chi tiết thành phần, xác định đầy đủ thông tin tương ứng cho thành phần để tiến hành xây dựng phần mềm 2.1 Các khái niệm thiết kế phần mềm • Quy trình: Thiết kế phần mềm 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 thành phần kiến trúc IEEEP1471-00 Thiết kế chi tiết - Detailed Design mục đích xác định đặc tính kỹ thuật đặc tả thành phần kiến trúc phần mềm IEEE1016-98 2.1 Các khái niệm thiết kế phần mềm • Các kỹ thuật 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 2.1 Các khái niệm thiết kế phần mềm • Các kỹ thuật 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 2.1 Các khái niệm thiết kế phần mềm • Các kỹ thuật 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 2.1 Các khái niệm thiết kế phần mềm • Các kỹ thuật 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 10 Xây dựng đặc tả thiết kế phần mềm Documenting a View (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 43 Xây dựng đặc tả thiết kế phần mềm Documenting a View (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 (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 44 Xây dựng đặc tả thiết kế phần mềm Documenting a View (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 (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 45 Xây dựng đặc tả thiết kế phần mềm Documenting a View (6) Glossary of terms used in the views, with a brief description of each (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 46 Xây dựng đặc tả thiết kế phần mềm DOCUMENTING BEHAVIOR 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 and the time of events In a banking system, the sequence of events is more important than the actual time of events being considered Different modeling techniques and notations are used depending on the type of analysis to be performed 47 Xây dựng đặc tả thiết kế phần mềm DOCUMENTING BEHAVIOR Statecharts are a formalism developed in the 1980s for describing reactive systems They add a number of useful extensions to traditional state diagrams such as nesting of state and "and" states, which provide the expressive power to model abstraction and concurrency Statecharts allow reasoning about the totality of the system All of the states are assumed to be represented and the analysis techniques are general with respect to the system 48 Xây dựng đặc tả thiết kế phần mềm DOCUMENTING BEHAVIOR A sequence diagram documents a sequence of stimuli exchanges It presents a collaboration in terms of component instances and their interactions and shows the interaction arranged in time sequence The vertical dimension represents time and the horizontal dimension represents different components Sequence diagrams allow reasoning based on a particular usage scenario They show how the system reacts to a particular stimulus and represent a choice of paths through the system They make it possible to answer a question such as What parallel activities occur when the system is responding to these specific stimuli under these specific conditions? 49 Xây dựng đặc tả thiết kế phần mềm DOCUMENTING INTERFACES An interface is a boundary across which two independent entities meet and interact or communicate with each other Documenting an interface consists of naming and identifying it and documenting its syntactic and semantic information An interface is documented with an interface specification, which is a statement of element properties the architect chooses to make known The architect should expose only what is needed to interact with the interface Put another way, the architect chooses what information is permissible and appropriate for people to assume about the element, and what is unlikely to change Documenting an interface is a matter of striking a balance between disclosing too little information and disclosing too much 50 Xây dựng đặc tả thiết kế phần mềm A Template for Documenting Interfaces (1) Interface identity When an element has multiple interfaces, identify the individual interfaces to distinguish them (2) Resources provided The heart of an interface document is the resources that the element provides (3) Data type definitions If any interface resources employ a data type other than one provided by the underlying programming language, the architect needs to communicate the definition of that data type (4) Exception definitions These describe exceptions that can be raised by the resources on the interface (5) Variability provided by the interface Does the interface allow the element to be configured in some way? These configuration parameters and how they affect the semantics of the interface must be documented 51 Xây dựng đặc tả thiết kế phần mềm A Template for Documenting Interfaces (6) Quality attribute characteristics of the interface The architect needs to document what quality attribute characteristics (such as performance or reliability) the interface makes known to the element's users (7) Element requirements What the element requires may be specific, named resources provided by other elements (8) Rationale and design issues As with rationale for the architecture (or architectural views) at large, the architect should record the reasons for an element's interface design (9) Usage guide Item and item document an element's semantic information on a per resource basis This sometimes falls short of what is needed In some cases semantics need to be reasoned about in terms of how a broad number of individual interactions interrelate 52 Chương Thiết kế phần mềm (Software Design) Các khái niệm thiết kế phần mềm Thiết kế kiến trúc phần mềm (Software Architectrure Design) Các chiến thuật phương pháp thiết kế phần mềm Xây dựng đặc tả thiết kế phần mềm (Software Design Specification) Giới thiệu số tài liệu liên quan đến nội dung chương Câu hỏi tập 53 Giới thiệu số tài liệu liên quan đến nội dung chương MicroSoft Press Analyzing Requirements and Define Microsoft NET Solution Architectures, 2003 Luke Hohmann Beyond Software Architecture – Creating and Sustaining Winning Solutions, 2002 Len Bass, Paul Clements, Rick Kazman Software Architecture in Practice, Second Edition Addison Wesley, 2003 54 Chương Thiết kế phần mềm (Software Design) Các khái niệm thiết kế phần mềm Thiết kế kiến trúc phần mềm (Software Architectrure Design) Các chiến thuật phương pháp thiết kế phần mềm Xây dựng đặc tả thiết kế phần mềm (Software Design Specification) Giới thiệu số tài liệu liên quan đến nội dung chương Câu hỏi tập 55 Câu hỏi tập MicroSoft Press Analyzing Requirements and Define Microsoft NET Solution Architectures, 2003 Phân cơng nhóm tìm hiểu: Chương Creating the Logical Design Chương Creating the Physical Design Chương Designing the Presentation Layer Chương Designing the Data Layer Chương Designing Security Specifications Chương 10 Completing the Planning Phase Chương 11 Stabilizing and Deploying the Solution 56 Câu hỏi tập Luke Hohmann Beyond Software Architecture – Creating and Sustaining Winning Solutions, 2002 Phân cơng nhóm tìm hiểu: Chương (Software Architecture) + Chương (Produc Development Primer) Chương (The difference between MarketArchitecture and Tarchitecture) + Chương Business and License Model Symbiosis Chương Technology in-Licéning + Chương Brand and Brand Elements + Chương Portability Chương Deployment Architecturre + Chương Produc Development Primer Chương Integration and Extension + Chương 13 Usability + Configuration and Customization 57 .. .Chương Thiết kế phần mềm (Software Design) Các khái niệm thiết kế phần mềm Thiết kế kiến trúc phần mềm (Software Architectrure Design) Các chiến thuật phương pháp thiết kế phần mềm Xây dựng. .. thành phần Thiết kế phần mềm sỏ cho giai đoạn xây dựng phần mềm Thiết kế phần mềm đóng vai trị quan trọng phát triển phần mềm: • Cho phép xem xét, so sánh phương án kỹ thuật khác thiết kế phần mềm. .. 10 Chương Thiết kế phần mềm (Software Design) Các khái niệm thiết kế phần mềm Thiết kế kiến trúc phần mềm (Software Architectrure Design) Các chiến thuật phương pháp thiết kế phần mềm Xây dựng