Bài giảng Phát triển vận hành và bảo trì phần mềm - Chương 2

Mục tiêu của chương 2 Phát triển phần mềm thuộc bài giảng Phát triển vận hành và bảo trì phần mềm trình bày các kiến thức cơ bản như: hoạt động và các nguyên tắc để phát triển phần mềm theo hướng cấu trúc và hướng đối tượng...mời các bạn thma khảo tài liệu này để hiểu sâu hơn về phát triển phần mềm.

CHƯƠNG 2

PHÁT TRIỂN PHẦN MỀM

Mục đich: Chương này tập trung vào các hoạt động và các nguyên tắc để phát triển phần mềm theo hướng cấu trúc và hướng đối tượng

2.1.1 Thiết kế phần mềm

• Là công việc đầu tiên của giai đoạn ↑

• Nhằm tạo ra các biểu diễn và dữ kiện

của hệ thống p/mềm cần x/dựng từ kết quả phân tích yêu cầu để có thể dễ dàng thực hiện sau đó

• Là lĩnh vực tương đối mới mẻ và đang

phát triển với nhiều phương pháp khác nhau

2.1.1 Thiết kế phần mềm

đối tượng

2.1.1.1 Cơ sở của thiết kế p/mềm

a) Trừu tượng hóa

• Quá trình thiết kế trải qua nhiều mức độ trừu tượng hóa khác nhau:

– Mức cao nhất: Vần đề cần thiết kế được mô

tả một cách tổng quát sử dụng thuật ngữ

hướng vấn đề

– Mức thấp hơn: Hướng đến thủ tục xử lý chi

tiết; kết hợp các thuật ngữ hướng đến hiện thực

– Mức thấp nhất: Vấn đề được mô tả theo cách

có thể thực hiện trực tiếp

a) Trừu tượng hóa

• Phân loại giữa trừu tượng hóa thủ tục và

dữ liệu

* Trừu tượng hóa thủ tục: Là chuỗi các lệnh liên

tiếp thực hiện một chức năng nào đó

Ví dụ:

- Mở cửa bao gồm: đi đến cửa, cầm lấy tay

nắm, xoay tay nám, kéo cánh cửa ra

- Thêm một phần tử vào danh sách có thứ tự: Xác định vị trí, chèn phần tử mới

a) Trừu tượng hóa

• * Trừu tượng hóa dữ liệu: Là tổ hợp dữ

liệu mô tả một đối tượng dữ liệu

• Ví dụ: một đối tượng thực thể là sự trừu tượng hóa của các tính chất và hành vi

b) Tinh chế

• Tinh chế là quá trình làm rõ vấn đề Tinh chế và trừu tượng hóa là 2 khái niệm bù trừ nhau thể hiện: Càng tinh chế thì càng

hạ thấp mức độ trừu tượng hóa

c) Phân chia moddule

• p/mềm được thực hiện bằng cách phân chia

thành nhiều module, sau đó sẽ được tích hợp lại

• Phân chia module làm cho việc quản lý phần

mềm khoa học hơn Thật vậy:

– Giả sử C(x) là độ phức tạp của X, E(X) là công sức

để thực hiện X Rõ ràng nếu C(p1)>C(p2) thì

E(p1)>E(p2) Nếu phân chia p = p1+p2 ta thấy (một cách trực quan) C(p1+p2) >C (p1)+C(p2) 

E(p1+p2)>E(p1) +E(p2)

c) Phân chia moddule

• Số lượng module phụ thuộc vào độ phức tạp của hệ thống phần mềm cần xây

dựng Quá ít hay quá nhiều module đều không tốt

Công sức bỏ ra

Vùng tối ưu

Công sức tích hợp Công sức từng module

Số lượng module

d) Kiến trúc phần mềm

• Kiến trúc phần mềm mô tả các thành phần kiếntạo nên hệ thống phần mềm và sự giao tiếpgiữa các thành phần đó

=> Kiến trúc p/m = tập hợp các module/thành phần

và quan hệ giữa chúng

– Các thành phần/module có thể là:

• Các module mã nguồn: hàm/nhóm hàm/lớp

• Các file thực thi (*.dll *.exe; *.class)

• Các thành phần của kiến trúc hệ thống: ActiveX control, bean,

• Các trang html: *.asp, *.jsp

– Quan hệ: Sử dụng/gọi/kế thừa, ….

Phần mềm nhìn từ cấu trúc phân cấp

• Cấu trúc phần mềm là cấu trúc phân cấp

(hierarchical structure): mức trên là hệ thống (system), dưới là các hệ thống con

(subsystems)

• Dưới hệ thống con là các chương trình

• Dưới chương trình là các Modules hoặc

Subroutines với các đối số (arguments)

d) Kiến trúc phần mềm

Phần mềm nhìn từ cấu trúc và thủ tục

• Hai yếu tố cấu thành của phần mềm

– Phương diện cấu trúc

– Phương diện thủ tục

• Cấu trúc phần mềm: biểu thị kiến trúc các chức năng mà phần mềm đó có và điều kiện phân cấp các chức năng (thiết kế cấu trúc)

• Thiết kế chức năng: theo chiều đứng (càng sâu càng phức tạp) và chiều ngang (càng rộng càng nhiều chức năng, qui mô càng lớn)

d) Kiến trúc phần mềm

• Sơ đồ phân cấp module được dùng để mô

tả sự phân rã,quan hệ phụ thuộc giữa các

môđun và giao diện (interface) giữa chúng

Hệ số gộp đầu vào (fan - in) Chiều sâu Hệ số phân chia đẩu ra (fan - out)

Chiều rộng

d) Kiến trúc phần mềm

– Quan hệ trên dưới: không cần nêu số lần gọi

– Tên môđun biểu thị chức năng (“làm gì”), đặt tên sao cho các môđun ở phía dưới tổng hợp lại sẽ biểu thị đủ chức năng của môđun tương ứng phía trên

– Biến số (arguments) biểu thị giao diện giữa các môđun, biến số ở các môđun gọi/bịgọi có thể khác nhau

– Mũi tên với đuôi tròn trắng biểu thị dữ liệu, đuôi tròn đen (hồng) biểu thị flag

– Chiều của mũi tên là hướng truyền tham số

d) Kiến trúc phần mềm

– Chia sẻ dịch vụ: Mô hình client/server

– Mô hình phân lớp (layered model)

d) Kiến trúc phần mềm

(1) Mô hình kho dữ liệu dùng

chung

* Nguyên tắc:

- Dữ liệu chia sẻ được tập trung trong một CSDL

- Các hệ thống con đều truy cập vào CSDL chung

* Khi một lượng lớn dữ liệu cần chia sẻ giữa các hệ thống con => Mô hình này thường được sd

Ưu điểm

- Đơn giản

- Hiệu quả khi chia sẻ một khối lượng lớn dữ liệu

- Đảm bảo sự độc lập của các hệ thống con

Hạn chế

- Các hệ thống con phải thống nhất trên mô hình kho dữ liệu dùng chung

(2) Mô hình Client – Server

(còn gọi là mô hình phân tán)

- Các client yêu cầu các dịch vụ

- Phương thức trao đổi giữa Client và server: Trên mạng hay trên một máy tính

e) Cấu trúc dữ liệu

• Cấu trúc dữ liệu mô tả sự tổ chức, phương thức truy xuất, mức độ liên kết và các xử lí khác của thông tin

– Dữ liệu đơn là dạng cấu trúc dữ liệu đơn giảnnhất

– Một số dạng cấu trúc dữ liệu phức tạp hơnnhư: Véc tơ, ma trận, mảng nhiều chiều, danhsách liên kết, hàng đợi, ngăn xếp, cây,

g) Che dấu thông tin

• Che dấu thông tin là một trong các nguyên

lý quan trọng của việc phân chia module Các module giao tiếp với nhau bằng những thông tin thực sự cần thiết.

• Những thông tin về thủ tục và dữ liệu cục

bộ phải được che dấu khỏi các module khác

• Lợi ích: Kiểm soát được thay đổi và sửa lỗi dễ dàng

2.1.2.2 Phân chia module hiệu quả

• Phân chia module là bắt buộc trong giai

đoạn thiết kế.

=> phân chia kiến trúc phần mềm thành một bộ module như thế nào là tốt nhất?

Tiêu chí quan trọng nhất là tính độc lập chức năng của các module Tính độc lập chức năng được đo bằng 2 tiêu chuẩn đó là

độ kết dính (cohesion) và sự liên kết (coupling) => Các tiêu chuẩn để phân chia

a) Độ kết dính (cohesion)

• Dùng để đo sự phụ thuộc lẫn nhau giữa các tác

vụ (task) của một module

• Module có độ kết dính cao nhất nếu nó chỉ đảm nhận đúng một tác vụ kết dính chức năng:

– Một module là một đơn vị logic

– Toàn bộ module cùng góp phần thực hiện một mục tiêu

Khi thiết kế kiến trúc phần mềm ta cố gắng tăng độ

kết dính

a) Độ kết dính

• Có nhiều mức độ kết dính (từ thấp đến cao):

- Ngẫu nhiên: Các tác vụ không liên hệ với nhau

- Lý luận: Các tác vụ liên quan logic với nhau

- Nhất thời: các tác vụ phải được thực thi trong

một khoảng thời gian

- Giao tiếp: các tác vụ có sử dụng chung một dữ liệu nào đó

- Thủ tục: các tác vụ phải được thực hiện theo một thứ tự nhất định

- Chức năng: Chỉ có một tác vụ

b) Sự liên kết (coupling)

• Dùng để đo đạc quá trình giao tiếp giữa

các module

• Giao tiếp của module chứa nhiều tác vụ

và nhiều thông số thì sự liên kết càng cao.

Khi thiết kế kiến trúc phần mềm cố gắng giảm

sự liên kết: các module nên liên kết lỏng lẻo (ít ràng buộc, phụ thuộc lẫn nhau)

- Liên kết Stamp: Truyền cấu trúc dữ liệu phức tạp

- Liên kết dữ liệu: Truyền các thông số đơn giản

c) Một số phương pháp phân chia

(1) Phương pháp phân chia STS

• 1) Chia đối tượng “bài toán” thành các chức năng thành phần

Bài toán Problem

F1

F2 F3

F4 F5

2) Tìm ra luồng dữ liệu chính đi qua các chức năng: từ đầu vào (Input) tới đầu ra (Output)

OUTPUT Luồng dữ

liệu chính

• 3) Theo luồng dữ liệu chính: thay từng chức

năng bởi bong bóng và làm rõ dữ liệu giữa các bong bóng

F1

• 4) Xác định vị trí trừu tượng hóa tối đa đầu

• 5) Chuyển sang sơ đồ phân cấp

Source Module

Transform Module

Sink Module

0

• 6) Xác định các tham số giữa các môđun dựa theo quan hệ phụ thuộc

7) Với từng môđun (Source, Transform, Sink) lại áp dụng cách phân chia STS lặp lại các bước từ 1) đến 6) Đôi khi có trường hợp không chia thành 3 mô đun nhỏ mà thành 2 hoặc 1

8) Tiếp tục chia đến mức cấu trúc lôgic khi môđun tương ứng với thuật toán đã biết thì dừng Tổng hợp lại ta được cấu trúc phân cấp: mỗi nút là 1 môđun với số nhánh phía dưới không nhiều hơn 3

(2) Phương pháp phân chia TR

• Khi không tồn tại luồng dữ liệu chính, mà dữ liệu vào có đặc thù khác nhau ( như những nguồn khác nhau) => xem như các giao dịch

khác nhau

• Mỗi giao dịch ứng với 1 môđun xử lý nó

d) Các kinh nghiệm cho việc

phân chia module

- Sửa lại bản thiết kế ban đầu để tăng độ kết dính

và giảm độ liên kết

- Khi chiều sâu tăng, hạn chế fan-out trong khi sử dụng fan – in

- Giữ cho tầm ảnh hưởng của một module nằm

bên trong tầm điều khiển của nó

- Loại bỏ dư thừa trong giao tiếp của các module

- Ưu tiên các module tất định, hạn chế các module nhiều ràng buộc

- Đóng gói các module để đạt được tính khả

chuyển (portability)

• Định nghĩa giao diện giữa các thành phần

• Định nghĩa phần vấn đề được giải quyết bởi mỗi thành phần

• Chọn chiến lược cài đặt và quản trị CSDL

• Có thể được thực hiện bởi nhiều mức độ trừu tượng

– Thiết kế chi tiết

• Thiết kế thuật toán

• Thiết kế cấu trúc dữ liệu

• Các giai đoạn thiết kế

Lợi ích của thiết kế

• Có một kiến trúc tốt

– Làm chủ được kiến trúc hệ thống

– Chia để trị

• Đạt được các tiêu chuẩn chất lượng

– Tái sử dụng, dễ kiểm thử, dễ bảo trì

• Thiết kế hướng đến sự thay đổi

– Sự thay đổi là một tính chất đặc trưng của phần mềm – Dự báo thay đổi là cần thiết (vì giúp giảm chi phí bảo trì)

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

• Mục tiêu:

– Xây dựng sơ đồ phân cấp module từ DFD

– Đặt nền móng để thiết kế chi tiết thủ tục và dữ liệu

• Phân biệt dòng biến đổi (transform) và dòng

xử lí (transaction) trong DFD

Dòng biến đổi (transform)

• Được mô tả như sau:

Dòng đi vào

Dòng biến đổi

Dòng đi ra

a Thiết kế dữ liệu

• Các bước:

– Tìm kiếm biểu diễn lý luận cho các phần tử

dữ liệu đã được nhận diện trong giai đoạn

phân tích yêu cầu

– Thiết kế các cấu trúc dữ liệu của chương trình

và cơ sở dữ liệu

– Thực hiện tinh chế từng bước

a Thiết kế dữ liệu

• Một số nguyên tắc thiết kế dữ liệu

– Nhận diện cả cấu trúc dữ liệu và tác vụ truy xuất

– Chú ý sử dụng từ điển dữ liệu

– Trì hoãn thiết kế dữ liệu mức thấp cho đến cuối giai đoạn này

– Che dấu biểu diễn bên trong của cấu trúc dữ liệu

– Phát triển một thư viện các cấu trúc dữ liệu và các tác

vụ thường gặp

– Nên áp dụng kiểu ADT trong thiết kế cũng như trong lập trình

c Thiết kế giao diện

• Một số hướng dẫn chung;

– Nên đồng nhất: menu, lệnh, hiển thị …

– Nên cung cấp feedback cho người dùng

– Yêu cầu xác nhận những tác vụ mang tính chất phá hoại như xóa file, account, …

– Nên hỗ trợ UNDO và REDO

– Hạn chế lượng thông tin phải ghi nhớ giữa hai tác vụ liên tiếp

– Tối ưu trong trình bày hộp thoại và di chuyển mouse – Chấp nhận lỗi từ phía người sử dụng

– Cung cập trợ giúp trực tuyến

– Dùng động từ đơn giản và ngắn gọn để đặt tên các lệnh

c Thiết kế giao diện

• Đối với thông tin hiển thị (output):

– Chỉ hiển thị những thông tin phù hợp với ngữ cảnh hiện tại

– Dùng tên, từ viết tắt và mầu gợi nhớ

– Cho phép tương tác trực quan

– Tạo thông báo lỗi có ý nghĩa

– Hiển thị dữ liệu ở nhiều dạng khác nhau trong cửa sổ – Thiết lập biểu diễn tương tự

– Sử dụng không gian màn hình một cách tối ưu

c Thiết kế giao diện

• Đối với thông tin input:

– Hạn chế input trực tiếp (có thể lựa chọn từ một số dữ liệu có sẵn)

– Nên đồng nhất giữa thông tin input và output

– Nên cho phép tùy biến input

– Cấm các chức năng không thích hợp trong ngữ cảnh hiện taị

– Cho phép input ở nhiều dạng khác nhau

– Để cho người sử dụng kiểm soát dòng điều khiển

tương tác

– Tự động tính các giá trị input cho người sử dụng nếu

có thể

2.2.2.4 Phương pháp thiết kế

hướng đối tượng

- Lấy đối tượng làm trung tâm

- Hệ thống = tập hợp các đối tượng + Quan hệ giữa

các đối tượng

-Các đổi tượng trao đổi bằng cách truyền các thông

điệp => Không sử dụng biến toàn cục

-Hỗ trợ đóng gói

-Cho phép kế thừa

- Tập hợp các đối tượng = chương trình

- Đối tượng = thuật toán + cấu trúc dữ liệu

a) Giới thiệu Tk

• Giai đoạn thiết kế nhằm trả lời câu hỏi

“how”:

– Xác định các tác nhân tham gia hệ thống

– Thứ tự các thông điệp trao đổi, thông số củathông điệp

– Thuật giải của tác vụ đáp ứng

– Cấu trúc dữ liệu cho các thuộc tính

– Framework (console, document/view, 3 –tier )

a) Giới thiệu TK

• Thiết kế cũng chụi ảnh hưởng từ:

– Ngôn ngữ lập trình và thư viện lập trình (hỗ trợ list, map, véc tơ hay không, có hỗ trợ template hay không?)

– Kiến trúc hệ thống (COM, CORBA hay EJB)?

• Thiết lập mô hình động và chi tiết hóa mô hình tĩnh

b Thiết kế hành vi

(2) Tương tác giữa các đối tượng

- Sự cộng tác

– Miêu tả trình tự

(3) Lược đồ trạng thái

(4) Lược đồ hoạt động

(1)Khái niệm mô hình tĩnh/động

• Lược đồ lớp chỉ mô tả khía cạnh tĩnh của hệ

thống => mô hình tĩnh (xác định các lớp và các thuộc

tính, cũng như mối quan hệ của các lớp)

• Hành vi của hệ thống được mô tả bằng các mô hình động Các mô hình động bao gồm:

– Tương tác giữa các đối tượng: Cộng tác hay trình tự

– Trạng thái của đối tượng, lớp: Mô hình trạng thái

– Quá trình hoạt động của lớp đối tượng: Lược đồ hoạt động

(2)Tương tác giữa các đối tượng

- Đối tượng tương tác với nhau bằng cách gửi - nhận các kích thích

- Actor cũng có thể gửi các kích thích đến

đối tượng

- Kích thích khiến:

- 1 tác vụ thực thi,

- 1 đối tượng được tạo ra hay hủy đi,

- hoặc gây ra một tín hiệu

(2)Tương tác giữa các đối tượng

• Thông điệp là một đặc tả của kích thích

Các loại thông điệp:

Đơn giản:

Đồng bộ

Bất đồng bộ

Trả về của gọi hàm

Bât đồng bộ/đồng bộ: Khi đối tượng gửi thông điệp đến đối tượng khác, nó không chờ đợi

mà tiếp tục thực hiện công việc khác/ chờ đợi để thực hiện công việc khác=>đồng bộ

(2)Tương tác giữa các đối tượng

Sự tương tác được biểu diễn qua 2

lược đồ:

- Lược đồ cộng tác

- Lược đồ miêu tả trình tự

Lược đồ cộng tác

• Định nghĩa một tập hợp các thành phần tham gia

và quan hệ giữa chúng (nhấn mạnh cấu trúc kết

hợp của các thành phần – khía cạnh không gian )

• Các thành phần tham gia tương tác là các đốitượng/lớp nhau

• Thiết lập để cụ thể hóa một use – case hoặc một tác vụ

• Tương tác được thể hiện bằng việc gửi/nhận

thông điệp có thứ tự và điều kiện

Lược đồ cộng tác

Lược đồ cộng tác

Vi dụ:

Lược đồ cộng tác

Ví dụ: Biểu đồ cộng tác của tác vụ thanh toán

Lược đồ miêu tả trình tự

• Lược đồ trình tự nhấn mạnh trình tự của tương tác

Lược đồ miêu tả trình tự

Ví dụ: Biểu đồ trình tự của chức năng thanh toán

Nhận xét

Giữa biểu đồ lớp và biểu đồ tương tác có mối quan hệ chặt chẽ với nhau Ví dụ:

(3) Lược đồ trạng thái

• Trạng thái và sự biến đổi trạng thái

(State transition)

• Biểu đồ trạng thái

Trạng thái và sự biến đổi trạng

thái (State transition)

• Tất cả các đối tượng đều có trạng thái;

• Trạng thái là một kết quả của các hoạt động trước đó đã được đối tượng thực hiện và nó thường được xác định qua giá trị của các thuộc tính

• Một lớp có thể có một thuộc tính đặc biệt xác định trạng thái

• Ví dụ về các trạng thái của đối tượng:

– Hóa đơn (đối tượng) đã được trả tiền (trạng thái)

– Chiếc xe ô tô (đối tượng) đang đứng yên

(trạng thái)

– Động cơ (đối tượng) đang chạy (trạng thái).– Jen (đối tượng) đang đóng vai trò người bán hàng (trạng thái)

– Kate (đối tượng) đã lấy chồng (trạng thái)

Trạng thái và sự biến đổi trạng

thái (State transition)

• Một đối tượng sẽ thay đổi trạng thái khi có một việc nào đó xảy ra (sự kiện xảy ra);

– ví dụ có ai đó trả tiền cho hóa đơn, bật động cơ xe ô

tô hay là lấy chồng lấy vợ

• Khía cạnh động có hai chiều không gian:

– tương tác: miêu tả lối ứng xử đối ngoại của các đối tượng và chỉ ra đối tượng này sẽ tương tác với các đối tượng khác ra sao (qua việc gửi thông điệp, nối kết hoặc chấm dứt nối kết)

– và sự biến đổi trạng thái nội bộ: miêu tả một đối

tượng sẽ thay đổi các trạng thái ra sao – ví dụ giá trị các thuộc tính nội bộ của nó sẽ thay đổi như thế nào

Trạng thái và sự biến đổi trạng

thái (State transition)