Xem mẫu
- CHƯƠNG 3
PHÂN TÍCH VÀ THIẾT KẾ HTTT
THEO HƯỚNG ĐỐI TƯỢNG
ANALYSIS AND DESIGN INFORMATION SYSTEMS
IN OBJECT ORIENTED
PGS.TS. Nguyễn Mậu Hân
Khoa CNTT-ĐHKH HUẾ
nmhan2005@yahoo.com
196
- NỘI DUNG
3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM
HƯỚNG ĐỐI TƯỢNG
3.2. PHÂN TÍCH YÊU CẦU HỆ THỐNG
3.3. ĐẶC TẢ CÁC YÊU CẦU CỦA HT
3.4. THIẾT KẾ HƯỚNG ĐỐI TƯỢNG
3.5. CÁC NHÓM MẪU THIẾT KẾ
3.6. THIẾT KẾ GIAO DIỆN, BÁO BIỂU, AN TOÀN
HỆ THỐNG
- 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT
Nhận xét:
Quá trình xây dựng một sản phẩm phần mềm hoặc
nâng cấp một sản phẩm đã có được gọi là quá trình
phát triển phần mềm (Software Development Process).
Quá trình phát triển một phần mềm là quá trình xác
định:
làm cái gì (WHAT?),
làm ở đâu (WHERE?)
làm khi nào (WHEN?)
làm như thế nào (HOW?).
198
- 3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT
Có 5 bước chính cần thực hiện trong quá trình phát
triển phần mềm theo hướng đối tượng:
1. Nghiên cứu hiện trạng và xác định các yêu cầu
2. Phân tích hệ thống
3. Thiết kế hệ thống
4. Lập trình và kiểm thử hệ thống
5. Vận hành và bảo trì hệ thống.
199
- 3.1. QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT ...
3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Từ các yêu cầu của khách hàng chúng ta xác định
được mục tiêu của phần mềm cần phát triển.
Thường đó là các yêu cầu chức năng về những gì
mà hệ thống phải thực hiện. Ở giai đoạn này chưa cần
chỉ ra các chức năng đó thực hiện như thế nào.
Việc xác định đúng và đầy đủ các yêu cầu của bài
toán là nhiệm vụ rất quan trọng, nó làm cơ sở cho các
bước tiếp theo.
Do đó, phải đặc tả được các yêu cầu của hệ thống
(Sử dụng các Use Case để đặc tả các yêu cầu). 200
- 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Các công việc cần phải làm trong giai đoạn này:
Hiểu rõ miền xác định của bài toán (Domain Understanding)
Nắm bắt các yêu cầu của khách hàng/người sử dụng
Phân loại (Classification): theo tầm quan trọng hay
theo chức năng chính của những người sử dụng.
Thẩm định (Validation): Kiểm tra xem các yêu cầu có
thống nhất với nhau và đầy đủ không, đồng thời tìm
cách giải quyết các mối mâu thuẫn giữa các yêu cầu
nếu có.
201
- 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Nghiên cứu khả thi (Feasibility Study):
Tính khả thi của một dự án tin học phải được thực
hiện dựa trên các yếu tố bao gồm các khía cạnh:
tài chính
chiến lược
thị trường
con người, đối tác
kỹ thuật
công nghệ và phương pháp mô hình hoá, v.v.
202
- 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Tóm lại, giai đọan nghiên cứu sơ bộ, cần xem xét:
Các yêu cầu của NSD, những nguồn tài nguyên có
thể sử dụng, công nghệ, các ý tưởng của người sử
dụng đối với hệ thống mới.
Có thể thực hiện thảo luận, nghiên cứu, xem xét
khía cạnh thương mại, phân tích khả năng lời-lỗ
Thường trong giai đoạn này người ta cũng tiến
hành tạo một phiên bản thô của lịch trình và kế hoạch
sử dụng tài nguyên.
Kết quả của giai đoạn nghiên cứu sơ bộ là bản Báo
Cáo Kết Quả Nghiên Cứu Tính Khả Thi.
Khi hệ thống tương lai được chấp nhận dựa trên
bản báo cáo này cũng là lúc giai đoạn Phân tích bắt 203
đầu.
- 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Mục đích cụ thể của bước xác định yêu cầu:
Đi đến thỏa thuận với khách hàng và người dùng
về các chức năng của hệ thống-Những gì mà hệ
thống phải thực hiện
Cho phép các System Developer hiểu rõ hơn các
yêu cầu đối với hệ thống
Phân định ranh giới của hệ thống
Cung cấp cơ sở để hoạch định nội dung kỹ thuật
của các vòng lặp
Xác định giao diện người dùng cho hệ thống
204
- 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Khi nào thì kết thúc giai đoạn này?
Khách hàng/người sử dụng (NSD) và những người
phát triển đã hiểu hoàn toàn hệ thống chưa?
Đã nêu được đầy đủ các yêu cầu về chức năng (dịch
vụ), đầu vào/ra và những dữ liệu cần thiết chưa?
205
- 3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu
Mối quan hệ giữa các công việc trong pha phân tích các yêu cầu
206
- 3.1.2 Phân tích hướng đối tượng
Là giai đoạn quan trọng của quá trình phát triển
phần mềm, trong đó mô hình khái niệm phải được mô
tả chính xác.
Phân tích hướng đối tượng tập trung vào việc tìm
kiếm các đối tượng, khái niệm trong lĩnh vực bài toán
và xác định mối quan hệ của chúng trong hệ thống.
Phân tích hệ thống cần trả lời các câu hỏi sau:
Hệ thống gồm những thành phần, bộ phận, đối
tượng nào?
Hệ thống cần thực hiện những cái gì?
Kết quả chính của việc phân tích hệ thống hướng
đối tượng là: biểu đồ lớp, biểu đồ trạng thái, biểu đồ
trình tự, biểu đồ cộng tác và biểu đồ thành phần. 207
- 3.1.2 Phân tích hướng đối tượng ...
Tóm lại, mục tiêu cụ thể của giai đoạn phân tích là:
Xác định hệ thống cần phải làm gì.
Nghiên cứu đầy đủ các chức năng cần cung cấp và
những yếu tố liên quan.
Xây dựng một mô hình nêu bật bản chất vấn đề từ
một hướng nhìn có thực (trong đời sống thực).
Nhờ chuyên gia lĩnh vực đánh giá, góp ý.
Kết quả của giai đoạn phân tích là bản Đặc Tả Yêu
Cầu (Requirements Specifications).
208
- 3.1.3 Thiết kế hướng đối tượng
Hệ thống được tổ chức thành tập các đối tượng
tương tác với nhau và mô tả được cách để hệ
thống thực thi nhiệm vụ của bài toán.
Giai đoạn này cần trả lời các câu hỏi:
Hệ thống làm như thế nào? (HOW?)
Trong hệ thống có những lớp đối tượng nào, trách
nhiệm của chúng như thế nào?
Các đối tượng tương tác với nhau như thế nào?
Các nhiệm vụ mà mỗi lớp đối tượng phải thực hiện
như thế nào?
Dữ liệu nghiệp vụ và các giao diện được xây dựng
như thế nào?
Kiến trúc và cấu hình của hệ thống như thế nào? 209
- 3.1.3 Thiết kế hướng đối tượng
Tóm lại, nhiệm vụ chính của thiết kế hệ thống là:
Xây dựng các thiết kế chi tiết mô tả các thành phần
của hệ thống ở mức cao hơn (khâu phân tích) để
phục vụ cho việc cài đặt.
Đưa ra được kiến trúc của hệ thống để đảm bảo
cho hệ thống có thể thay đổi, có tính mở, dễ bảo trì,
thân thiện với NSD, ...
Những kết quả trên được thể hiện trong các biểu
đồ: biểu đồ lớp (chi tiết), biểu đồ hành vi, biểu đồ
thành phần và biểu đồ triển khai.
Trong các tài liệu thiết kế phải mô tả cụ thể những
thành phần nào, làm những gì và làm như thế nào. 210
- 3.1.3 Thiết kế hướng đối tượng
Một số các công việc thường được thực hiện trong
giai đoạn thiết kế:
Thiết kế database
Thiết kế các chức năng, thủ tục mô tả các quá trình
xử lý từ input đến output.
Thiết kế các forms nhập dữ liệu tùy theo các thành
phần dữ liệu cần nhập.
Thiết kế các reports và những output mà hệ thống
mới phải sản sinh
Kết quả giai đoạn thiết kế là bản Đặc Tả Thiết Kế
(Design Specifications).
Bản Đặc Tả Thiết Kế Chi Tiết sẽ được chuyển sang
cho các lập trình viên để thực hiện giai đoạn xây 211
dựng phần mềm.
- 3.1.4 Lập trình và kiểm thử hệ thống
Trong giai đoạn này, mỗi thành phần đã được thiết
kế sẽ được lập trình thành những mô đun chương
trình (chương trình con).
Mỗi mô đun này sẽ được kiểm chứng hoặc thử
nghiệm theo các tài liệu đặc tả của giai đoạn thiết kế.
Công việc này được mô tả như sau:
Quá trình xây dựng phần mềm 212
- 3.1.4 Lập trình và kiểm thử hệ thống
Phần kiểm thử được chia thành hai bước chính:
Thử nghiệm đơn vị:
Người viết code chạy thử các phần chương trình
của mình với dữ liệu giả (test/dummy data).
Mục đích chính trong giai đoạn kiểm thử này là xem
chương trình có cho ra những kết quả mong muốn.
Giai đoạn thử nghiệm đơn vị còn được gọi là “Kiểm
thử hộp trắng" (White Box Testing)
213
- 3.1.4 Lập trình và kiểm thử hệ thống
Kiểm thử đơn vị độc lập
Công việc này do một thành viên khác đảm trách.
Cần chọn người không có liên quan trực tiếp đến
việc viết code của đơn vị chương trình cần thử
nghiệm để đảm bảo tính “độc lập”.
Kiểm thử hệ thống
Sau khi các thủ tục đã được thử nghiệm riêng, cần
phải thử nghiệm toàn bộ hệ thống.
Mọi thủ tục được tích hợp và chạy thử, kiểm tra
xem mọi chi tiết ghi trong Đặc Tả Yêu Cầu.
Dữ liệu kiểm thử cần được chọn lọc đặc biệt, kết
quả cần được phân tích để phát hiện các sai sót so
với bản thiết kế. 214
- 3.1.5 Vận hành và bảo trì hệ thống
Cài đặt hệ thống phần mềm trong môi trường sử
dụng của khách hàng
Chỉnh sửa phần mềm đúng như những gì đã thiết
kế và yêu cầu của người sử dụng
Về bảo trì phần mềm:
Nâng cao hiệu quả của hệ thống
Đảm bảo sự thích nghi đối với sự thay đổi của
môi trường của hệ thống hay sự sửa đổi cho phù
hợp với những thay đổi của chính sách, qui chế
mới
215
nguon tai.lieu . vn
