Bài giảng Công nghệ phần mềm: Chương 3 - ĐH Công nghệ TP.HCM

Bài giảng Công nghệ phần mềm: Chương 3 Thiết kế phần mềm cung cấp cho người học những kiến thức như: Tổng quan về thiết kế; Kiến trúc phần mềm; Phương pháp thiết kế phần mềm; Ví dụ minh họa. Mời các bạn cùng tham khảo!

Jens Martensson

Insert or Drag and Drop your Image

THIẾT KẾ PHẦN MỀM

Jens Martensson

• Mục tiêu của việc thiết kế là định hình hệ thống và tìm dạng thức của phần mềm có thể đáp ứng

được mọi yêu cầu

• Dữ liệu đầu vào của giai đọn thiết kế: Kết quả thu được từ bước phân tích trước đó.

3

3.1 Tổng quan về thiết kế

• Mục đích thiết kế:

• Hiểu rõ về yêu cầu và những ràng buộc có liên quan, khả năng tái sử

dụng của các thành phần

• Tạo đầu vào thích hợp và điểm xuất phát cho các hoạt động hiện thực

• Có thể phân rã việc cài đặt thành các phần nhỏ dễ quản lý để nhiều nhóm phát triển xử lý đồng thời

• Lựa chọn kiến trúc phù hợp với hệ thống

3.1 Tổng quan về thiết kế

Jens Martensson

• Có hai phương pháp chính:

• Thiết kế từ trên xuống (Top- Down)

• Thiết kế từ dưới lên (Bottom – Up)

5

3.1.1 Kỹ thuật thiết kế phần mềm

• Quá trình thiết kế được bắt đầu bằng những thành phần tổng quan nhất của hệ thống.

• Triển khai thành những module nhỏ hơn , quá trình này được lặp lại cho đến khi những nhiệm vụ con trở nên đơn giản sao cho một thuật toán có thể tính toán và giải quyết được.

3.1.1.1 Thiết kế trên xuống (top-down)

Jens Martensson

• Thiết kế từ dưới lên bắt đầu từ một công việc nhỏ nhất và cụ thể, phát triển liên tiếp thành một

thành phần trừu tượng cho đến khi đạt được kết quả mà là các chức năng theo yêu cầu của người dùng.

7

3.1.1.2 Thiết kế từ dưới lên (bottom–up)

• Thiết kế hệ thống phần mềm có ba cấp độ kết quả:

• Thiết kế kiến ​​trúc: Thiết kế kiến ​​trúc là phiên bản trừu tượng cao nhất của

hệ thống Nó xác định phần mềm là một hệ thống có nhiều thành phần tương tác với nhau

• Thiết kế cấp cao : Thiết kế cấp cao tập trung vào cách hệ thống cùng với

tất cả các thành phần của nó có thể được thực hiện dưới dạng các đun

mô-• Thiết kế chi tiết: Thiết kế chi tiết liên quan đến phần thực hiện của một hệ

thống và các hệ thống con, xác định cấu trúc logic của từng mô-đun và giao diện của chúng để giao tiếp với các module khác

3.1.1.3 Thiết kế hệ thống phần mềm

Jens Martensson

• Thiết kế bản mẫu: tạo các giao diện sơ bộ, các bản thiết kế phác thảo cho người dùng tham khảo

trước khi thiết kế chi tiết

• Các bản thiết kế này được thực hiện dạng tài liệu kỹ bằng các phần mềm thiết kế nhanh như MS Visio, MS Visual Basic / C# / C++, MS Front Page / Visual Interdev …

• Đây là bước đệm cơ bản trước khi đi vào hiện thực chi tiết

9

3.1.1.4 Thiết kế bản mẫu (prototype)

• Phân rã thiết kế giúp hiện thực hóa từng phần bản thiết kế đến mức chi tiết Các nhóm phương pháp

phân rã gồm:

• Phân rã hướng chức năng

• Phân rã hướng dữ liệu

3.1.1.5 Phân rã thiết kế

Jens Martensson

• Phân rã hướng chức năng

• Dựa trên những yêu cầu chức năng để phân rã hướng đến các tác nhiệm của toàn bộ hệ thống

• Xác định các chức năng dựa trên mô tả các tính chất của đầu vào và đầu ra

• Xác định phạm vi của hệ thống

• Phân hoạch chức năng

• Tạo nền tảng cho thiết kế kiến trúc hệ thống

11

3.1.1.5 Phân rã thiết kế

• Phân rã hướng dữ liệu

• Tiến trình thiết kế tập trung vào dữ liệu

• Chiến lược thiết kế hướng đến các đối tượng dữ liệu cần được thực hiện

• Việc phân rã hệ thống dựa trên việc phân tích dữ liệu, bao gồm sơ đồ

luồng dữ liệu (Data flow diagram - DFD), giúp xem toàn bộ luồng dữ liệu

bên trong hệ thống và cách dữ liệu được xử lý theo nhiều mức chi tiết

khác nhau và nhiều biến thể mở rộng khác nhau

3.1.1.5 Phân rã thiết kế

Jens Martensson

• Ví dụ: DFD hệ thống bán vé

13

3.1.1.5 Phân rã thiết kế

3.1.1.5 Phân rã thiết kế

• Tiếp cận từ trên xuống (top-down)

cả các yêu cầu xử lý)

• Phân rã các xử lý thành nhiều xử lý con và quyết định các luồng dữ liệu tương

ứng

• Phân rã các luồng dữ liệu nhập xuất thành nhiều luồng dữ liệu con và quyết

định các xử lý tương ứng

• Quá trình kết thúc khi đạt đến các sơ đồ không thể tiếp tục phân rã được nữa,

đây là sơ đồ tương ứng với công việc cụ thể.

Jens Martensson

• Nhận xét: Cách tiếp cận từ trên xuống

• Thích hợp với phần mềm có số lượng người dùng, số lượng các yêu cầu ít

(nếu ngược lại sơ đồ cấp 0 sẽ rất phức tạp và khó lập chính xác)

• Đặc biệt thích hợp với các loại phần mềm mà yêu cầu chưa được xác định

rõ ngay từ đầu (ví dụ các phần mềm hệ thống) ít được sử dụng.

15

3.1.1.5 Phân rã thiết kế

• Tiếp cận từ dưới lên (bottom-up)

• Lập sơ đồ luồng dữ liệu ở mức cao nhất

• Tích hợp các sơ đồ này để tạo các sơ đồ có cấp nhỏ hơn theo cách:

• Tích hợp các xử lý của các sơ đồ cấp k vào sơ đồ cấp k-1 và giữ nguyên

các luồng dữ liệu của các sơ đồ cấp k

• Tích hợp đồng thời các xử lý và các luồng dữ liệu của các sơ đồ cấp k

để tạo lập sơ đồ cấp k-1

• Quá trình kết thúc khi đạt đến các sơ đồ cấp 0

3.1.1.5 Phân rã thiết kế

Jens Martensson

• Nhận xét: Cách tiếp cận từ dưới lên

• Thích hợp với các phần mềm có yêu cầu chi tiết, cụ thể và có quy mô

• Hướng tiếp cận phối hợp:

• Lập sơ đồ luồng dữ liệu cấp k theo tiêu chí xác định

• Phân rã sơ đồ cấp k thành nhiều sơ đồ cấp k+1 tiếp tục cho đến khi đạt

Jens Martensson

• Lập sơ đồ luồng dữ liệu cho từng công việc

• Việc lập các sơ đồ luồng dữ liệu cho toàn bộ phần mềm sẽ trở thành lập

sơ đồ luồng dữ liệu cho từng công việc.

• Bước 1: Xác định dữ liệu nhập , dữ liệu nhập phải thỏa điều kiện sau:

• Không nhập vào các dữ liệu có thể tính toán được dựa trên quy định hay

công thức đã có

• Không nhập vào các dữ liệu đã được lưu trữ trước đó

• Dữ liệu nhập từ thiết bị nhập khác chỉ được xem xét khi có yêu cầu đặc

biệt trong một số phần mềm đặc biệt như: hệ thống thời gian thực, hệ

thống bản đồ, nhập qua điện thoại tổng đài …

3.1.1.5 Phân rã thiết kế

Jens Martensson

• Bước 2: Xác định dữ liệu xuất

• Cần phải có các thông báo giúp người dùng biết được kết quả xử lý của hệ thống Ví dụ thông báo việc mượn sách là không

• Bước 3: Mô tả Xử lý

• Chỉ mô tả cách xử lý mà không cần chú ý đến cách thực hiện nhập xuất

• Khi mô tả cách sử dụng dữ liệu nhập để tạo dữ liệu xuất, việc mô tả

càng chi tiết thì việc thiết kế xử lý càng dễ dàng

• Chỉ chú trọng đến tính đúng đắn

• Mô tả chính xác thứ tự nhập/xuất

3.1.1.5 Phân rã thiết kế

Jens Martensson

• Xây dựng mô hình thực thể kết hợp (ERD)

• Mô hình ERD là dạng sơ đồ giúp thể hiện các đối tượng dữ liệu được đặc tả trong yêu cầu của phần

mềm, tạo nền tảng cho việc thiết kế chi tiết cơ sở dữ liệu cho phần mềm.

23

3.1.1.5 Phân rã thiết kế

• Phân rã hướng đối tượng

• Một hệ thống phần mềm được xem như tập hợp các đối tượng, mỗi đối tượng có cấu trúc dữ liệu và hành vi

• Phân rã hướng đối tượng hướng đến tính đồng nhất giữa dữ liệu, hành vi dựa trên sự che dấu thống tin và dẫn xuất kế thừa

3.1.1.5 Phân rã thiết kế

Jens Martensson

• Thiết kế giao diện người dùng

• Thiết kế giao diện được hỗ trợ một phần trong thiết kế dạng mô hình bản mẫu (prototype) nhằm làm rỏ các yêu cầu từ

người dùng và đáp ứng các yêu cầu về giao diện

• Nếu khách hàng đồng ý với bản mẫu đã đưa ra trong giai đoạn xác định yêu cầu, kỹ sư thiết kế sẽ hoàn chỉnh thêm để đảm

bảo chính xác yêu cầu người dùng.

25

3.1.2 Thiết kế giao diện người dùng

• Các yếu tố cần quan tâm trong thiết kế giao diện

• Chế độ (modes):

• Trường hợp mà người dùng chỉ có thể thực hiện ở một số thao tác giới

hạn

• Kỹ thuật tạo/sử dụng cửa sổ có thể cung cấp dịch vụ có giá trị về biểu

diễn chế độ của chương trình, giúp thực hiện các thao tác trong những

cửa sổ khác nhau thể hiện bởi những chế độ chương trình khác nhau

3.1.2 Thiết kế giao diện người dùng

Jens Martensson

• Thanh menu: giúp người dùng chọn lệnh của chương trình Có hai dạng menu

• Dạng Pop-up menu: là menu có thể xuất hiện ở một vị trí bất kỳ

• Dialog window: dạng hộp thoại giúp người dùng có thể tương tác với chương trình linh hoạt hơn.

• Khi thiết kế hộp thoại, ta cần đảm bảo tính đồng nhất trong giao diện

người dùng, nên ngắn gọn cô động như cách đặt nhãn Label, Checkbox,

Button, List box

• Màu sắc Màu được dùng ở những nơi cần làm nổi bật những yêu cầu hoặc cần nhấn mạnh một nội dung, hoặc dấu hiệu cảnh

báo nguy hiểm.

• Nên sử dụng màu hài hòa trong toàn bộ hệ thống

• Sử dụng màu phải phù hợp với từng loại giao diện của chương trình

3.1.2 Thiết kế giao diện người dùng

Jens Martensson

• Âm Thanh là cách tốt nhất tập trung sự chú ý của người dùng Chúng được phần mềm phù hợp trong các tình huống xử lý lỗi,

sự kiện không chắc chắn, tạm thời

• Nên tạo những âm thanh khác nhau với những sự kiện khác nhau, tránh

dùng âm thanh gây ồn

• Tính kiên định

• Phím tắt: nên dùng cho một số chức năng của phần mềm và nên cố

• Thiết kế hướng chức năng: tập trung vào thuật toán để giải quyết vấn đề

• Xem một thuật toán như một hàm tính toán với các tham số đầu vào

• Tại thời điểm bắt đầu giai đoạn thiết kế, thuật toán chưa xác định

• Cần xây dựng những thuật toán để giải quyết những tác nhiệm khó hoặc phức tạp của phần mềm

• Việc module hóa để phân rã những công việc thành các công việc con độc lập dựa vào thuật toán xử lý các công việc con

• Kết quả chung của những giải pháp dựa trên các thuật toán con gộp lại.

3.1.3 Thiết kế hướng chức năng

Jens Martensson

• Thiết kế hướng đối tượng là tổ chức thiết kế xoay quanh những đối tượng và mối liên hệ giữa

• Thiết kế dữ liệu: thiết kế cách thức tổ chức lưu trữ các đối tượng trên bộ nhớ phụ.

31

3.1.3 Thiết kế hướng đối tượng

• Kiến trúc phần mềm của một chương trình máy tính là cấu trúc của các thành phần bên trong hệ

thống, các mối quan hệ (cấu trúc) và cách tương tác giữa các thành phần với nhau.

• Kiến trúc phần mềm bao gồm các phần tử chức năng, các thuộc tính và mối quan hệ giữa chúng

• Kiến trúc phần mềm giúp việc quyết định ở mức cao trong thiết kế phần mềm dễ dàng hơn và cho phép tái sử dụng các thành

phần và mẫu thiết kế của các dự án.

3.2 Kiến trúc phần mềm

Jens Martensson 33

3.2 Kiến trúc phần mềm

• Kiến trúc phần mềm bao gồm các thành phần cơ bản: Giao diện, Xử lý, Dữ liệu

• Khi thiết kế một phần mềm, nhóm thiết kế phải chọn lựa và ra quyết định về các “vật liệu” được dùng trong các thành phần

• Kết quả được trình bày trên các bảng vẽ, dưới dạng tài liệu kỹ thuật, tạo thành các mô hình phần mềm

3.2 Kiến trúc phần mềm

Jens Martensson

• Thành phần Giao diện

• Nội dung và hình thức trình bày các chức năng giao tiếp

• Các thao tác của người dùng trên giao diện để thực hiện các giao tiếp và các chức năng xử lý

• Thành phần Xử lý:

• Các kiểu dữ liệu được mô tả về cách tổ chức lưu trữ trong bộ nhớ chính

• Các hàm thực hiện các xử lý (ví dụ kiểm tra tính hợp lệ việc cho mượn sách, ghi vào sổ việc cho mượn sách …)

35

3.2 Kiến trúc phần mềm

• Thành phần Dữ liệu:

• cách tổ chức lưu trữ dữ liệu trong bộ nhớ

• Cách lưu trữ của dữ liệu được sử dụng của phần mềm,

• Hệ thống các thành phần lưu trữ và mối quan hệ giữa các dữ liệu.

3.2 Kiến trúc phần mềm

• Kiến trúc Model-View-Controller – MVC

• Hệ thống được cấu trúc thành ba thành phần logic tương tác với nhau.

• Model : quản lý dữ liệu của hệ thống và các thao tác trên dữ liệu

• View : định nghĩa và quản lý cách dữ liệu được hiển thị cho người dùng

• Controller: Quản lý tương tác người dùng (VD, ấn phím, nhấp chuột, )

và chuyển các tương tác này tới View và Model

3.2 Kiến trúc phần mềm

Jens Martensson

• Kiến trúc Model-View-Controller – MVC

• Hoạt động của MVC

• Controller chuyển yêu cầu dữ liệu của người dùng cho Model.

• Model Lấy được dữ liệu chuyển cho Controller.

• Controller chuyển dữ liệu cho View

• View Hiển thị thông tin cho người dùng.

39

3.2 Kiến trúc phần mềm

• Kiến trúc Client-Server (máy khách-máy chủ) là một mô hình máy tính, trong đó máy chủ (server),

3.2 Kiến trúc phần mềm

Jens Martensson

• Kiến trúc 3 Layer: gồm có 3 thành phần: Presentation Layers, Business Logic Layers, và Data Access

Layers

cơ sở dữ liệu.

41

3.2 Kiến trúc phần mềm

• Kiến trúc 3 Layer: Cách vận hành:

• Người dùng giao tiếp với tầng giao diện (GUI) để gửi yêu cầu, các thông tin sẽ được kiểm tra, nếu OK, dữ

liệu được chuyển xuống tầng nghiệp vụ (BLL).

• Tại BLL, các thông tin sẽ được xử lý, nếu không cần đến Database thì BLL sẽ gửi trả kết quả về GUI,

ngược lại dữ liệu được đưa xuống tầng truy cập dữ liệu (DAL).

• DAL sẽ thao tác với Database và trả kết quả cho BLL, BLL kiểm tra và gửi cho GUI để hiển thị cho người

dùng.

3.2 Kiến trúc phần mềm

Jens Martensson

• Phương pháp trực tiếp

• Phương pháp này được áp dụng khi thực hiện phần mềm không qua giai đoạn phân tích, việc thiết kế nhận kết quả đươc

chuyển giao trực tiếp từ giai đoạn xác định yêu cầu

• Đối với phương pháp trực tiếp: Thiết kế phần mềm là quá trình chuyển đổi từ các yêu cầu đến mô hình phần mềm tương ứng.

• Cách tiếp cận này rất khó đối với các phần mềm có quy mô lớn

43

3.3 Phương pháp thiết kế phần mềm

• Phương pháp gián tiếp

• Được áp dụng với các quy trình có giai đoạn phân tích, việc thiết kế chỉ nhận 1 phần kết quả từ giai đoạn xác định yêu cầu,

phần chính được nhận từ giai đoạn phân tích, PM được xây dựng dựa trên các mô hình trong giai đoạn phân tích.

• Cách tiếp cận này thích hợp với các phần mềm có quy mô lớn

• Đối với phương pháp gián tiếp: Thiết kế PM là quá trình chuyển từ kết quả giai đoạn phân tích đến mô hình phần mêm tương

ứng

3.3 Phương pháp thiết kế phần mềm

Jens Martensson

• Ví dụ minh họa quá trình thiết kế phần mềm sau khi thực hiện giai đoạn mô hình hóa yêu cầu.

Thiết kế phần mềm quản lý thư viện với 4 yêu cầu: Lập thẻ đọc

giả, Nhận sách, Cho mượn sách, Trả sách

45

3.4 Ví dụ minh hoạ

• Thiết kế phần mềm: Hệ thống các màn hình giao diện

• Màn hình chính

• Màn hình Lập thẻ

3.4 Ví dụ minh hoạ

Jens Martensson

• Màn hình cho mượn sách

• Màn hình Nhận sách

• Màn hình Trả sách

47

3.4 Ví dụ minh hoạ

• Hệ thống các hàm xử lý

phép cập nhật hay xóa thẻ

nhận các thông tin cho mượn sách vào kho

3.4 Ví dụ minh hoạ

Jens Martensson

quá hạn và trả về 1 nếu đúng, 0 nếu sai

1 nếu đúng và 0 nếu sai

nhiều tiêu chuẩn để cập nhật hay số phiếu cho mượn

49

3.4 Ví dụ minh hoạ

• Hệ thống các bảng dữ liệu

• Bảng THU_VIEN: các thông tin về thư viện

• Bảng DOC_GIA: các thông tin về độc giả

• Bảng SACH: các thông tin về sách

• Bảng MUON_SACH: các thông tin về mượn trả sách

3.4 Ví dụ minh hoạ

2 Các bước được gọi trong Quy trình hợp nhất (UP) là gì

Jens Martensson

3 KHÔNG phải là một hoạt động thiết kế chi tiết?

A Thiết kế phần mềm ứng dụng

B Thiết kế các cơ chế sao lưu và phục hồi hệ thống

C Thiết kế giao diện người dùng và hệ thống bên ngoài

D Thiết kế kiến trúc

53

Câu hỏi

4 là các yêu cầu và ràng buộc xác định các đặc điểm quan trọng của tài nguyên xử lý thông tin và