Bài giảng Phân tích và thiết kế hệ thống thông tin: Chương 3 - PGS.TS. Nguyễn Mậu Hân

Bài giảng Phân tích và thiết kế hệ thống thông tin: Chương 3 Phân tích và thiết kế hệ thống thông tin theo hướng đối tượng cung cấp cho người học những kiến thức như: Phân tích yêu cầu hệ thống; Đặc tả các yêu cầu của hệ thống; Thiết kế hướng đối tượng; Các nhóm mẫu thiết kế nội dung; Quá trình phát triển phần mềm hướng đối tượng; Thiết kế giao diện, báo biểu, an toàn hệ thống. Mời các bạn cùng tham khảo!

PHÂN TÍCH VÀ THIẾT KẾ HTTT

THEO HƯỚNG ĐỐI TƯỢNG

PGS.TS Nguyễn Mậu Hân Khoa CNTT-ĐHKH HUẾ

CHƯƠNG 3

ANALYSIS AND DESIGN INFORMATION SYSTEMS

IN OBJECT ORIENTED

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Ế

NỘI DUNG

3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM

HƯỚNG ĐỐI TƯỢNG

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

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?)

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ì

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

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ó

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ó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 đầ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

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

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?

3.1.1 Nghiên cứu hiện trạng và xác định các yêu cầu

 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:

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à:

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

3.1.2 Phân tích 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?

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

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ế:

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:

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)

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

3.1.4 Lập trình và kiểm thử 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

3.1.5 Vận hành và bảo trì hệ thống

3.1 QUÁ TRÌNH PHÁT TRIỂN PHẦN MỀM HĐT

BÀI TOÁN 1: HỆ THỐNG BÁN HÀNG (HBH)

Một Công ty muốn xây dựng HTTT để phục vụ và quản lý các hoạt động kinh doanh Công ty có nhiều điểm bán hàng đầu cuối (POST: Point Of Sale Terminal), đó là những cửa hàng, siêu thị, Do đó hệ thống cần phải ghi nhận các hoạt động bán hàng và xử lý các công việc thanh toán với khách hàng, chủ yếu khách hàng mua lẻ Ngoài ra hệ thống còn giúp lãnh đạo Công ty theo dõi được các hoạt động kinh doanh, tự động kiểm kê các mặt hàng tồn đọng trong kho, các mặt hàng bán chạy, để hỗ trợ ra quyết định trong các hoạt động kinh doanh của Công ty Trong mỗi cửa hàng đầu cuối đều có các thiết bị phần cứng như: máy tính, máy đọc mã vạch và phần mềm hệ thống để chạy hệ thống sẽ được xây dựng”.

3.2 PHÂN TÍCH YÊU CẦU HỆ THỐNG

 Tăng nhanh hoặc tự động hoá việc bán hàng, ghi nhận các mặt hàng: loại sản phẩm, mô tả sản phẩm, số lượng và xác định giá bán, tính tiền, v.v., đáp ứng mọi yêu cầu của khách hàng,

 Thanh toán nhanh với khách hàng bằng các phương thức: tiền mặt, thẻ tín dụng, hay séc

 Phân tích, xử lý các kết quả bán hàng nhanh và chính xác để

hỗ trợ quyết định trong các hoạt động kinh doanh.

 Thực hiện tự động kiểm kê các mặt hàng trong kho, theo dõi được những mặt hàng bán chạy, những mặt hàng tồn kho để

có được những quyết định kịp thời trong kinh doanh

 Tóm lại, hệ thống xây dựng nhằm tự động hoá các hoạt động kinh doanh, phục vụ khách hàng nhanh hơn, tốt hơn và rẻ

Mục đích của hệ thống HBH

Trong giai đoạn phân tích

Đối với bài toán 1, giai đoạn OOA sẽ nhận biết được các

đối tượng như:

Ngân hàng VietinBank có các máy rút tiền tự động (ATM) đặt ở những vị trí khác nhau trong thành

phố Chúng được nối với Trung tâm tại trụ sở

Ngân hàng thông qua hệ thống mạng máy tính

Máy tính trung tâm lưu trữ và quản trị CSDL khách hàng, xử lý những công việc chuyên ngành của

ngân hàng và yêu cầu ATM trả tiền

Máy rút tiền tự động bao gồm máy đọc thẻ từ, màn hình và bàn phím để tương tác với người sử dụng

Khách hàng có thể rút tiền tự động, chuyển tiền,

xem số dư trong tài khoản và thực hiện thanh toán với hệ thống tín dụng của Ngân hàng

BÀI TOÁN 2: HỆ THỐNG ATM

Trong những trường hợp đặc biệt như bị mất thẻ, hay muốn thay đổi số thẻ thì khách hàng có thể

thay đổi mật khẩu cá nhân (PIN) và tương tự như vậy, khi khách hàng báo bị mất thẻ thì Ngân hàng cũng có thể quyết định thay đổi số thẻ và báo cho khách hàng biết để đảm bảo không cho những

người không phải chủ sở hữu rút được tiền

BÀI TOÁN 2: HỆ THỐNG ATM

 Đại học Huế cần xây dựng một hệ thống thông tin giúp sinh

viên (SV) đăng ký học phần (HP) mới Hệ thống cho phép SV đăng ký học phần và xem điểm từ một máy tính cá nhân được kết nối vào hệ thống mạng của ĐHH Các giáo viên cũng có thể truy cập vào hệ thống này để biết được lớp dạy và nhập điểm cho các HP.

 Vào đầu mỗi học kỳ SV dựa vào TKB và giáo viên sẽ phụ trách môn học để đăng ký HP được giảng dạy trong học kỳ đó

Thông tin về mỗi HP bao gồm: tên HP, tên giáo viên giảng dạy, Khoa chuyên môn, các HP tiên quyết, để giup SV đăng ký

 Hệ thống mới cho phép SV chọn 4 học phần được mở trong

học kỳ tới SV cũng có thể chọn 2 HP tự chọn trong trường hợp không thể đăng ký theo nguyện vọng chính

 Số tối thiểu và tối đa SV cho mỗi HP là 30 và 60 Các HP có ít

BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN

 Khi quá trình đăng ký hoàn tất cho mỗi SV hệ thống sẽ gửi thông tin đến ngân hàng VietinBank để SV có thể đóng học phí qua thẻ ATM

 Nếu một lớp bị hết chỗ trong quá trình đăng ký, SV sẽ được thông báo về sự thay đổi trước khi xác nhận đăng ký HP

 Cuối học kỳ SV có thể truy cập vào hệ thống để xem phiếu điểm Hiễn nhiên, mỗi SV được hệ thống cung cấp một tài khoản cá nhân để bảo mật thông tin của mình.

 Các giáo viên có thể truy cập vào hệ thống để biết TKB và danh sách SV của HP sẽ dạy

 Giáo viên có nhiệm vụ nhập các điểm QTHT, điểm thi, kiểm tra sau khi HP kết thúc

BÀI TOÁN 3: HỆ THỐNG ĐĂNG KÝ HỌC PHẦN

Các công cụ để mô tả yêu cầu người dùng

Chức năng của hệ thống là những gì mà hệ thống

được yêu cầu thực hiện

Các chức năng có thể phân loại theo lĩnh vực chức năng để tránh sự nhầm lẫn giữa chúng Các chức năng hệ thống có thể chia thành:

 Chức năng hiển (Evident): chọn hàng, tính tiền,

 Chức năng ẩn (Hiddent): cập nhật dữ liệu, tồn kho

 Chức năng tuỳ chọn (optional) : tăng mức độ thân

thiện của hệ thống nhưng không ảnh hưởng tới giá trị cũng như các chức năng khác

Các chức năng, nhiệm vụ của hệ thống là gì?

Ví dụ: Các chức năng của hệ thống HBH có thể chia

thành hai nhóm chính:

 Các chức năng bán hàng

Các chức năng, nhiệm vụ của hệ thống là gì?

Bảng liệt kê các chức năng

Bảng liệt kê các chức năng

 Các chức năng hệ thống thường được đánh số theo các qui

tắc tham chiếu (Reference Rule) để tiện cho việc sử dụng tham

chiếu trong các mục phân tích sau này

1 Use Case

Use Case mô tả tập các hoạt động của hệ thống

theo quan điểm của các tác nhân (Actor) Nó mô tả các yêu cầu của hệ thống và trả lời cho câu hỏi:

Use Case mô tả các yêu cầu về mặt chức năng của

hệ thống -các chức năng này có từ sự thỏa thuận giữa khách hàng và nhóm phát triển phần mềm

3.3 ĐẶC TẢ CÁC YÊU CẦU CỦA HỆ THỐNG

Làm cơ sở để:

 người phân tích viên hiểu

 người thiết kế xây dựng các kiến trúc

 người lập trình cài đặt các chức năng

 người kiểm thử kiểm tra các kết quả thực hiện

của hệ thống

Làm công cụ giao tiếp cho những người phát triển, đảm bảo hệ thống thỏa mãn đúng những yêu cầu của Users

2 Mục tiêu của Use Case

Nhà phát triển cần đến các mô hình Use Case để

hiểu hệ thống cần phải làm gì, và qua đó có được

một nền tảng cho những công việc tương lai

Customers/Users quan tâm đến Use Case vì nó đặc

tả chức năng của hệ thống và mô tả xem hệ thống có thể và sẽ được sử dụng như thế nào

Tester cần đến Use Case để thử nghiệm và kiểm tra xem hệ thống có đảm bảo sẽ thực hiện đúng chức

năng đã được đặc tả trong giai đoạn đầu

Những người liên quan đến những hoạt động liên kết đến chức năng của hệ thống như nhóm tiếp thị, bán hàng, hỗ trợ khách hàng và nhóm soạn thảo tài liệu

3 Ai cần Use Case? - Để làm gì?

Một biểu đồ Use Case thể hiện:

Hệ thống

Tác nhân

Use Case

Ví dụ biểu đồ Use Case trong UML:

4 Cách thể hiện một biểu đồ Use Case

Actors Hệ thống

Use Case

Hệ thống là một thành phần của Use Case nên ranh giới của hệ thống cần phải được xác định rõ ràng.

Một hệ thống không nhất thiết là một hệ thống phần mềm; nó có thể là một chiếc máy, hoặc là một doanh nghiệp

Ký hiệu của hệ thống: hình chữ nhật có kèm theo tên

Người hoặc một vật nào đó tương tác

với hệ thống, sử dụng hệ thống

Một tác nhân có thể là người, thiết bị mà cũng có thể

là một hệ thống khác

Tên gọi của tác nhân được mô tả bằng các danh từ

(chung) và thường phải đặc tả được vai trò của nó đối với hệ thống

Một tác nhân là một dạng tập thực thể (một lớp) chứ không phải một thực thể Tác nhân mô tả và đại diện cho một vai trò, chứ không phải là một người sử

dụng thật sự và cụ thể của hệ thống

b Tác nhân

 Dùng để giải thích các khái niệm, định nghĩa, thuật ngữ, ngôn ngữ công việc trong hệ thống

c Bảng chú giải

a Để xác định các tác nhân là dựa trên các câu trả lời những câu hỏi sau:

Ai sẽ sử dụng các chức năng chính của hệ thống?

Ai cần sự hỗ trợ của hệ thống để thực hiện các

công việc hàng ngày?

Ai quản trị, bảo dưỡng để đảm bảo cho hệ thống

hoạt động thường xuyên?

Hệ thống quản lý, sử dụng những thiết bị nào?

Hệ thống cần tương tác với những bộ phận, hệ

thống nào khác?

Ai hay cái gì quan tâm đến kết quả xử lý của hệ

5 Cách xác định các tác nhân và các Use Case

b Có hai phương pháp để xác định các Use Case

 Xác định Use Case dựa vào các tác nhân:

Xác định những tác nhân liên quan đến hệ thống

giao tiếp/tương tác với hệ thống

5 Cách xác định các tác nhân và các Use Case

Xác định những sự kiện bên ngoài có tác động đến

hệ thống hay hệ thống phải trả lời

Tìm mối liên quan giữa các sự kiện và các UC

Hãy trả lời những câu hỏi sau để tìm ra các UC:

 Nhiệm vụ chính của các tác nhân là gì?

 Tác nhân cần phải đọc, ghi, sửa đổi, cập nhật, hay lưu trữ thông tin hay không?

 Những thay đổi bên ngoài hệ thống thì tác nhân có cần phải thông báo cho hệ thống hay không?

 Những tác nhân nào cần được thông báo về những thay đổi của hệ thống?

 Hệ thống cần có những đầu vào/ra nào? từ đâu và đến

Xác định các Use Case và các sự kiện

a Xác định các actor: Danh sách các actor

+ Khách hàng: là những người được hệ HBH phục vụ,

là khách hàng

+ Người bán hàng: những người cần sử dụng chức năng bán hàng của hệ thống để thực hiện nhiệm vụ của mình

+ Người quản lý: những người được phép khởi động

hay kết thúc cả hệ thống tại các điểm bán hàng đầu cuối

+ Người quản trị hệ thống: có thể bổ sung, thay đổi

những NSD

Ví dụ1: Xác định các Actor và Use Case của HBH