mẫu thiết kế design patterns có thể được sử dụng để đạt được các yêu cầu quy định cho hệ thống, và những rang buộc ảnh hưởng đến cách thức mà kiến trúc có thể được thực hiện...
Trang 1PGS.TS Huỳnh Xuân Hiệp
BÔ ̣ MÔN CÔNG NGHÊ ̣ PHẦN MỀMKhoa CNTT& TT – Trường ĐH Cần Thơ
1
Trang 2 Tổng quan
Thiết kế kiến trúc
Thiết kế giao diện
Thiết kế thành phần
Thiết kế hướng dịch vụ
2
Trang 3[1] IBM Rational Software, DEV496 Mastering IBM Rational Software Architect – Acme Case Study
(Part No 800-027176-000), IBM Rational University, 2005
[2] IBM Rational Software, DEV496 Mastering IBM Rational Software Architect – Student Exercise
Guide (Part No 800-027175-000), IBM Rational University, 2005
[3] Julia H Allen et al., Software Security Engineering, Pearson Education, 2008.
[4] Barry W Boehm, Software Engineering, IEEE Computer Society - Wiley, 2007
[5] Alphonse Carlier, Le développement du logiciel, Hermes, 1995.
[6] Scott E Donaldson and Stanley G Siegel, Successful Software Development (2nd edition),
[11] Per Kroll and Philippe Kruchten, The Rational Unified Process Made Easy: A Practitioner's Guide
to the RUP, Addison Wesley, 2003.
[12] Philippe Kruchten, The Rational Unified Process: An Introduction (2nd, 3rd editions), Addison
Wesley, 2000, 2003.
[13] Craig Larman, Agile and Iterative Development: A Manager's Guide, Addison Wesley, 2003.
[14] Timothy C Lethbridge and Robert Laganière, Obiect-Oriented Software Engineering: Practical
Software Development Using UML and Java, McGraw-Hill, 2002
3
Trang 4[15] Raymond J Madachy, Software Process Dynamics, IEEE Press – Wiley, 2008.
[16] Mario E Moreira, Software Configuration Management Implementation Roadmap, Wiley, 2004.
[17] Rational Software White Paper, Reaching CMM Levels 2 and 3 with the Rational Unified Process,
Rational Software Corporation, 2000.
[18] John W Rittinghouse, Managing Software Deliverables: A Software Development Management
Methodology, Digital Press – Elsevier, 2004
[19] Robert E Park, Software Size Measurement: A Framework for Counting Source Statements,
Technical Report CMU/SEI-92-TR-020 ESC-TR-92-020, 1996
[20] Roger S Pressman, Software Engineering: A Practitioner’s Approach (5th, 6th, 7th editions),
McGraw-Hill, 2003, 2005, 2009.
[21] Stephen R Schach, Object-Oriented and Classical Software Engineering (5th,6th,7th, 8th
editions), McGraw-Hill, 2002, 2005, 2007, 2011.
[23] Ian Sommerville, Software Engineering (6th,8th editions), Addison-Wesley, 2001, 2006.
[24] Jeff Tian, Software Quality Engineering: Testing Quality Assurance and Quantifiable Improvement,
IEEE Computer Society - Wiley, 2005
[25] Hans van Vliet, Software Engineering: Principals and Practice (2nd edition), Wiley, 2000.
[26] MK.PUB, Design Patterns, Nhà xuất bản Phương Đông, 2005.
[27] http://www.rspa.com/
[28] http://www.sei.cmu.edu/
[29] http://computingcareers.acm.org/
4
Trang 5TỔNG QUAN
(Overview)
5
Trang 6 Thiết kế phần mềm bao gồm tập hợp các nguyên tắc,
khái niệm và thực hành dẫn đến sự phát triển của một
hệ thống chất lượng cao hoặc sản phẩm
sẽ hướng dẫn người thiết kế trong công việc thiết kế
phải thực hiện
hành thiết kế được áp dụng
khác nhau của phần mềm
công nghệ phần mềm
6
Trang 7 Mục đích của thiết kế là tạo ra một mô hình hoặc một
thích thú Để thực hiện điều này, cần phải thực hành đadạng hóa (diversification) và sau đó hội tụ
(convergence)
7
Trang 8 Quyết định thiết kế với các thiết kế thay thế từ những
lựa chọn khác nhau:
◦ Đường thẳng biểu diễn cho các tùy chọn
◦ Đường đậm nét là tập hợp các quyết định được đưa ra
8
Trang 9 Thiết kế phần mềm nằm ở lõi kỹ thuật (technical kernel) của công nghệ phần mềm và được áp dụng không phụ thuộc vào mô hình quy trình phần mềm được sử dụng.
tích và mô hình hóa, thiết kế phần mềm là hành động
công nghệ phần mềm cuối cùng trong hoạt động mô
hình hóa (modeling) và đặt ra giai đoạn xây dựng (sinh
9
Trang 10 Mỗi một phần tử trong mô hình yêu cầu (requirements
model) cung cấp thông tin đó là cần thiết để tạo ra bốn
mô hình thiết kế (design model) cần thiết cho một đặc tảthiết kế hoàn chỉnh
◦ Thiết kế dữ liệu/lớp (data/class design)
◦ Thiết kế kiến trúc (architectural design)
◦ Thiết kế giao diện (interface design)
◦ Thiết kế thành phần (component design)
10
Trang 13 Thiết kế dữ liệu/lớp chuyển đổi các mô hình lớp (class
models) vào thiết kế lớp một cách rõ ràng và các cấu
trúc dữ liệu cần thiết theo yêu cầu để cài đặt phần mềm
(relationships) được xác định trong sơ đồ CRC
(class-responsibility-collaboration) và nội dung dữ liệu chi tiết
được mô tả bởi các thuộc tính lớp và ký hiệu khác tạo
cơ sở cho các hoạt động thiết kế dữ liệu
Một phần của thiết kế lớp có thể được kết hợp với thiết
kế của kiến trúc phần mềm
Thiết kế lớp chi tiết hơn được thực hiện khi thực hiện
thiết kế mỗi thành phần của phần mềm
13
Trang 14 Thiết kế kiến trúc xác định mối quan hệ giữa các phần
tử cấu trúc chính của phần mềm
mẫu thiết kế (design patterns) có thể được sử dụng để
đạt được các yêu cầu quy định cho hệ thống, và những rang buộc ảnh hưởng đến cách thức mà kiến trúc có thể được thực hiện
14
Trang 15 Thiết kế giao diện mô tả như thế nào phần mềm giao
tiếp với:
◦ Các hệ thống có tương tác
◦ Con người người sử dụng
liệu và/hoặc kiểm soát) và một loại hình cụ thể của hành vi
hành vi (behavioral model) cung cấp nhiều thông tin cần thiết cho thiết kế giao diện
15
Trang 16 Thiết kế thành phần chuyển đổi các phần tử cấu trúc
của kiến trúc phần mềm thành một mô tả về thủ tục của các thành phần phần mềm
(class-based model), các mô hình luồng (flow model), và các
mô hình hành vi (behavioral model) phục vụ như là cơ
sở để thiết kế thành phần
16
Trang 17 Trong quá trình thiết kế sẽ hình thành các quyết định màcuối cùng sẽ ảnh hưởng đến sự thành công của việc
xây dựng phần mềm và thực sự quan trọng đó là sự dễ dàng để phần mềm có thể được bảo trì
công nghệ phần mềm
đánh giá được về chất lượng
17
Trang 18 Thiết kế là cách duy nhất mà ta có thể thông dịch chính xác yêu cầu của các bên liên quan vào một sản phẩm
phần mềm hoàn chỉnh hoặc hệ thống
Thiết kế phần mềm phục vụ như là nền tảng cho tất cả
các hoạt động công nghệ phần mềm và hỗ trợ phần
mềm kèm theo
thống không ổn định:
◦ thất bại khi các thay đổi nhỏ được thực hiện
◦ khó khăn để đánh giá chất lượng mặc dù đã đến thời gian cuối
của tiến trình phần mềm (khi thời gian còn ngắn và đã sử dụng
nhiều kinh phí)
18
Trang 19 Thiết kế phần mềm là một tiến trình lặp đi lặp lại
(iterative process) thông qua đó yêu cầu được chuyển
thành một "kế hoạch chi tiết" để xây dựng phần mềm
mềm:
◦ Các thiết kế được thể hiện ở một mức độ trừu tượng cao-một
mức độ mà có thể được truy vết trực tiếp đến mục tiêu cụ thể của
hệ thống và dữ liệu chi tiết hơn, chức năng, và các yêu cầu về
Trang 20 Một thiết kế nên thể hiện một kiến trúc mà
◦ đã được tạo ra bằng cách sử dụng phong cách kiến trúc hoặc
mẫu dễ nhận biết
◦ bao gồm các thành phần mà thể hiện các đặc tính thiết kế tốt
◦ có thể được cài đặt theo một cách thức tiến hóa, do đó sẽ tạo
điều kiện cho việc cài đặt và kiểm thử
mềm nên được phân chia thành các phần tử hoặc hệ
thống con một cách hợp lý
liệu, kiến trúc, giao diện và thành phần
20
Trang 21 Một thiết kế nên dẫn đến các cấu trúc dữ liệu phù hợp
cho các lớp để được cài đặt và được rút ra từ các mẫu
dữ liệu dễ nhận biết
đặc tính chức năng độc lập
tạp của các kết nối giữa các thành phần và với môi
trường bên ngoài
21
Trang 22 Một thiết kế nên được bắt nguồn bằng sử dụng một
phương pháp lặp được dẫn dắt bởi thông tin thu được
trong quá trình phân tích yêu cầu phần mềm
hiệu truyền tải có hiệu quả ý nghĩa của nó
22
Trang 23 Quá trình thiết kế không nên bị “bó hẹp tầm nhìn"
Thiết kế nên "giảm thiểu khoảng cách trí tuệ" giữa phần mềm và các vấn đề như nó đã tồn tại trong thế giới thực
vẹn
23
Trang 24 Việc thiết kế phải được cấu trúc để làm giảm nhẹ nhàng, ngay cả khi đang gặp phải dữ liệu, sự kiện hoặc điều
kiện hoạt động bất thường
phải là thiết kế
được tạo ra, không phải trên thực tế diễn ra sau đó
(ngữ nghĩa)
24
Trang 25 Tính năng (functionality) được thẩm định bằng cách
đánh giá một tập hợp các tính năng và các khả năng
của chương trình, mức độ tổng quát của các hàm đã
được phân phối và mức độ an toàn của toàn bộ hệ
thống
Khả dụng (usability) được đánh giá bằng cách xem xét
tài liệu
Độ tin cậy (reliability) được đánh giá bằng cách đo tần
số và mức độ nghiêm trọng của thất bại, tính chính xác của kết quả đầu ra, giá trị mean-time-to-failure (MTTF), khả năng phục hồi từ thất bại, và khả năng dự đoán của chương trình
25
Trang 26 Hiệu suất (performance) được đo bằng cách xem xét tốc
độ xử lý, thời gian đáp ứng, tiêu thụ tài nguyên, băng
thông, và hiệu quả
Tính năng hỗ trợ (supportability) kết hợp các khả năng
mở rộng các chương trình (tính mở rộng), khả năng
thích ứng, khả năng phục vụ (ba thuộc tính này đại diện cho một thuộc tính phổ biến hơn là bảo trì) và ngoài ra
năng cấu hình (khả năng tổ chức và kiểm soát các yếu
tố của cấu hình phần mềm), tính dễ dàng mà một hệ
thống có thể được cài đặt và tính dễ dàng mà vấn đề có thể được bản địa hóa
26
Trang 27 Trừu tượng hóa (abstraction)
Tinh chỉnh (refinement)
Mô đun hóa (modularity): phân tích được
(decomposability), tổng hợp (composability), dễ hiểu
(understandability), liên tục (continuity), bảo vệ
(protection)
27
Trang 29 Kiến trúc phần mềm (software architecture)
◦ Đặc tính cấu trúc (structural properties)
◦ Đặc tính hàm ngoài (extra-functional properties)
◦ Họ các hệ thống liên quan (families of related systems)
◦ Mô hình cấu trúc (structural models)
◦ Mô hình khung (framework models)
◦ Mô hình động (dynamic models)
◦ Mô hình tiến trình (process models)
◦ Mô hình chức năng (functional models)
◦ Ngôn ngữ mô tả kiến trúc (architectural description language
-ADLs)
29
Trang 30 Mẫu thiết kế (design patterns)
◦ Được áp dụng cho công việc hiện tại
◦ Có thể được tái sử dụng (tiết kiệm thời gian thiết kế)
◦ Có thể phục vụ như một hướng dẫn để phát triển một cách tương
tự, nhưng chức năng hoặc cấu trúc khác với mẫu
structure)
30
Trang 31 Độc lập chức năng (functional independence)
◦ Gắn kết (cohesion): coincidentally cohesive, logically cohesive,
temporal cohesion, procedural cohesion, communicational
cohesion
◦ Nối kết (coupling): data coupling, stamp coupling, control
coupling, external coupling, common coupling, content coupling
Tái cấu trúc (refactoring)
31
Trang 33 Cần thiết kế các lớp (design classes) để tinh chỉnh các
lớp trong giai đoạn phân tích bằng cách cung cấp thiết
kế chi tiết mà sẽ cho phép các lớp được cài đặt, và cài
đặt một cơ sở hạ tầng phần mềm hỗ trợ các giải pháp
nghiệp vụ
đại diện cho một tầng khác nhau của thiết kế kiến trúc
◦ Lớp giao diện người dùng (user interface class)
◦ Lớp lĩnh vực nghiệp vụ (business domain class)
◦ Lớp tiến trình (process class)
◦ Lớp kéo dài (persistent class)
◦ Lớp hệ thống (system class)
33
Trang 34 4 đặc tính của một thiết kế tốt
◦ Hoàn chỉnh và đầy đủ (complete and sufficient)
◦ Nguyên thủy (primitiveness)
◦ Gắn kết cao (high cohesion)
◦ Nối kết thấp (low coupling)
34
Trang 36 Mô hình thiết kế có thể được xem trong hai chiều khác
nhau:
◦ Chiều tiến trình (process dimension)
◦ Chiều trừu tượng hóa (abstraction dimension)
như là công việc thiết kế được thực thi như là một phần của tiến trình phần mềm
mỗi phần tử trong mô hình phân tích được chuyển đổi
chỉnh một cách lặp đi lặp lại
36
Trang 41THIẾT KẾ DỮ LIỆU/LỚP
(Data/Class Design)
41
Trang 42 Phân tích yêu cầu (requirements analysis) cho ra kết
quả là các đặc tả đặc điểm hoạt động của phần mềm,
chỉ ra giao diện phần mềm với các phần tử của hệ thống khác, và thiết lập các ràng buộc mà phần mềm phải đáp ứng
chuyên gia phân tích hoặc xây dựng mô hình) để giải
thích về các yêu cầu cơ bản được thiết lập trong các
nhiệm vụ thành lập (inception), gợi mở (elicitation), và
đàm phán (negotiation) là một phần của kỹ thuật yêu
cầu (requirements engineering)
42
Trang 43 Mô hình hóa các yêu cầu (requirements analysis) tạo ra
◦ Mô hình dựa trên kịch bản (scenario-based model)
◦ Mô hình dữ liệu (data model)
◦ Mô hình hướng lớp (class-oriented model)
◦ Mô hình hướng luồng (flow-oriented model)
◦ Mô hình hành vi (behavioral model)
Mục tiêu (objective) và triết lý (philosophy)
◦ Cái gì (what)?
◦ Như thế nào (how)?
43
Trang 45 Hệ thống con (subsystem)
Trang 46 Mô hình nên tập trung vào các yêu cầu mà có thể nhìn
thấy trong vấn đề hoặc lĩnh vực nghiệp vụ Mức độ trừu tượng cần được tương đối cao
hiểu biết tổng thể các yêu cầu phần mềm và cung cấp
cái nhìn sâu sắc vào lĩnh vực thông tin, chức năng, và
hành vi của hệ thống
không có chức năng khác cho đến khi thiết kế
46
Trang 47 Giảm thiểu các nối kết (coupling) trên toàn hệ thống
47
Trang 48 Hãy chắc chắn rằng mô hình yêu cầu cung cấp giá trị
cho tất cả các bên liên quan (stakeholders)
48
Trang 52 Unified Modeling Language - UML
hợp sử dụng (use case):
◦ Sơ đồ hoạt động (activity diagram)
◦ Sơ đồ theo làn (swimlane diagram)
52
Trang 55 Các khái niệm của mô hình hóa dữ liệu (data modeling):
◦ Đối tượng dữ liệu (data objects)
◦ Thuộc tính dữ liệu (data attributes)
◦ Mối quan hệ (relationships)
55
Trang 58 Xác định các lớp phân tích (identifying analysis classes)
◦ Thực thể ngoài (external entities)
Trang 59 Xác định các thuộc tính (specifying attributes)
modeling)
59
Trang 87 Các chiến lược mô hình hóa yêu cầu (requirements
modeling strategies)
◦ Tạo ra một mô hình luồng dữ liệu (data flow model)
◦ Tạo ra một mô hình kiểm soát luồng (control flow model)
◦ Đặc tả kiểm soát (control specification)
◦ Đặc tả tiến trình (process specification)
◦ Xác định các sự kiện (events) với các trường hợp sử dụng
◦ Biểu diễn các trạng thái (states)
◦ Các sơ đồ tuần tự (sequence diagram)
87
Trang 88 Mẫu (patterns) cho mô hình hóa yêu cầu
◦ Phân tích bao nhiêu thì vừa đủ?
◦ Đầu vào (input) mô hình hóa yêu cầu
◦ Đâu ra (output) mô hình hóa yêu cầu
◦ Mô hình nội dung (content model) cho webapps
◦ Mô hình tương tác (interaction model) cho webapps
◦ Mô hình chức năng (functional model)
◦ Mô hình điều hướng (navigation model)
◦ Mô hình cấu hình (configuration model)
88
Trang 100THIẾT KẾ KIẾN TRÚC
(Architectural Design)
100
Trang 101 Kiến trúc phần mềm (software architecture) của một
chương trình hoặc hệ thống tính toán là cấu trúc hoặc
phần phần mềm, các thuộc tính bên ngoài có thể nhìn
thấy của những thành phần này và các mối quan hệ
giữa chúng
thiết kế: một thiết kế là một thể hiện của một kiến trúc
tương tự như một đối tượng là một thể hiện của một
lớp
101
Trang 102 Kiến trúc không phải là phần mềm hoạt động Thay vào
đó, nó là một thể hiện cho phép ta:
◦ phân tích hiệu quả của thiết kế trong việc đáp ứng các yêu cầu đã được đề ra
◦ xem xét lựa chọn thay thế kiến trúc ở một giai đoạn khi thực hiện thay đổi thiết kế vẫn còn tương đối dễ dàng
◦ giảm thiểu rủi ro liên quan đến việc xây dựng phần mềm
102
Trang 103 Biểu diễn của kiến trúc phần mềm có khả năng cho
phép thông tin liên lạc giữa tất cả các bên (các bên liên quan) quan tâm đến sự phát triển của một hệ thống dựa trên máy tính
Các kiến trúc làm nổi bật lên các quyết định thiết kế ban đầu mà sẽ có một tác động sâu sắc trên tất cả các công việc kỹ thuật phần mềm sau đó và quan trọng là trên
thành công cuối cùng của hệ thống như một thực thể
hoạt động
Kiến trúc "tạo thành một mô hình tương đối nhỏ, có khảnăng nắm bắt tri thức về cách thức mà một hệ thống
được cấu trúc như thế nào và thành phần của nó làm
việc cùng nhau ra sao"
103