THIẾT KẾ VÀ XÂY DỰNG PHẦN MỀM - Chương 2 Thiết kế phần mềm potx

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 đặ

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

2.1 Các khái niệm cơ bản trong thiết kế phần mềm

2.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

• 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

2.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ủaphầ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ácthô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

2.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

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:

• 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 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.

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:

• 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 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

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

• 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

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

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]

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]

Planning and Architecture Phase

Discovery

Review

Architecture Review

Source:

Joe Maranzano

ATT Bell Labs

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

Meta-Model for Architecture Design Approaches(1/3)

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 )

Meta-Model for Architecture Design Approaches(3/3) Domain Knowledge

Artifact-driven Architecture Design (1/2) Mô hình mức

khái niệm

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)

Use-Case driven Architecture Design (1/2)

Mô hình mức khái niệm

Use-Case driven Architecture Design (2/2)

Domain-driven Architecture Design (1/3)

Mô hình mức khái niệm

Domain-driven Architecture Design (2/3)

Product-line Architecture Design

Domain-driven Architecture Design (3/3)

Domain Specific Software Architecture Design

Pattern-driven Architecture Design (1/3)

Mô hình mức khái niệm

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.)

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

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

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

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

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

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)

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

4 Xây dựng các đặc tả thiết kế phần mềm

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.

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 sufficentdetail, 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

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

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

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

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

to yield an impractically large number of views

views to serve your stakeholder community.

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

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

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