1. Trang chủ
  2. » Giáo án - Bài giảng

Bài Giảng Phân Tích, Thiết Kế Hệ Thống Thông Tin ( Combo Full Slide 6 Module Bài Giảng)

468 39 1

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Tiêu đề Phân Tích, Thiết Kế Hệ Thống Thông Tin (Combo Full Slide 6 Module Bài Giảng)
Trường học Trường Đại Học Công Nghệ Thông Tin - Đại Học Quốc Gia Hà Nội
Chuyên ngành Phân Tích, Thiết Kế Hệ Thống Thông Tin
Thể loại Bài Giảng
Thành phố Hà Nội
Định dạng
Số trang 468
Dung lượng 23,25 MB

Các công cụ chuyển đổi và chỉnh sửa cho tài liệu này

Nội dung

PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN NỘI DUNG 6 MODULE  Module 1 Hệ thống thông tin và Mô hình hoá trực quan  Module 2 Ngôn ngữ mô hình hoá thống nhất UML [.]

Trang 1

PHÂN TÍCH, THIẾT KẾ HỆ THỐNG THÔNG TIN

Trang 2

NỘI DUNG : 6 MODULE

 Module 1 - Hệ thống thông tin và Mô hình hoá trực quan

 Module 2 - Ngôn ngữ mô hình hoá thống nhất UML

 Module 3 - Quy trình phát triển hướng đối tượng

 Module 4 - Biểu đồ ca sử dụng và Biểu đồ hoạt động

 Module 5 - Biểu đồ tương tác và Biểu đồ lớp

 Module 6 - Các biểu đồ trong UML

Trang 3

Module 1

Hệ thống thông tin và Mô hình hoá trực quan

Trang 4

Chương 1

 PHƯƠNG PHÁP LUẬN PHÁT TRIỂN HỆ THỐNG THỐNG TIN

Trang 5

Nội dung

Hệ thống thông tin (HTTT)

• Một số khái niệm cơ bản

• Biểu diễn hệ thống thông tin

Phương pháp luận phát triển các HTTT

• Cách tiếp cận định hướng tiến trình

• Cách tiếp cận định hướng dữ liệu

• Cách tiếp cận định hướng cấu trúc

• Cách tiếp cận định hướng đối tượng

Mô hình hoá trực quan

• Tầm quan trọng

• Giới thiệu một số loại mô hình

Trang 6

Hệ thống

6

Hệ thống là tập hợp các thành phần có quan hệ chặt chẽ với nhau

tạo thành một thể thống nhất.

Cấu tạo của hệ thống: Môi trường, mục đích, giới hạn, thành phần,

mối quan hệ, giao diện, đầu vào, đầu ra và các ràng buộc.

Trang 7

Ví dụ

 Cửa hàng bán sỉ và lẻ các loại nước ngọt, nước suối, rượu, bia

 Đối tượng mà cửa hàng giao tiếp là khách hàng mua các loại nước giải khát, nhà cung cấp (các công ty sản xuất nước giải khát) cung cấp các loại nước giải khát cho cửa hàng và ngân hàng giao tiếp với cửa hàng thông qua việc gửi, rút và thanh toán tiền mặt cho nhà cung cấp.

Trang 8

Trang 9

Phân tích hệ thống (systems analysis)

 Là sự khảo sát một hệ thống hay một vấn đề để cải tiến hệ thống đang tồn tại hoặc thiết kế và cài đặt hệ thống mới

Trang 11

Các loại hệ thống thông tin

 Để dễ phân loại người ta thường chia các hệ thống

Trang 12

Các hệ thống điều khiển: Dành cho các nhà quản lý vận hành

hay quản lý hệ thống để thu được những câu trả lời cho các câu

hỏi thường ngày Ví dụ, hệ thống lưu vết trình tự các hoạt động

và giao dịch hàng ngày như các hệ xử lý giao dịch (Transaction

Processing Systems), điều khiển thiết bị hay dây chuyền sản

xuất, lưu trữ giao dịch, lập lịch, xử lý đơn đặt hàng

12

Trang 13

Các hệ cơ sở tri thức: Dành cho các nhân viên tri thức và xây

dựng dữ liệu nhằm giúp tổ chức, khám phá và tích hợp tri thức mới từ tri thức hiện thời vào nghiệp vụ của họ hay điều khiển luồng công việc Ví dụ, các hệ thống hoạt đông dựa trên tri thức,

tự động hóa văn phòng, hệ xử lý ngôn ngữ, hệ thống tư vấn trong thương mại điện tử

13

Trang 14

Các hệ thống quản lý: Dành cho các nhà quản lý trung gian để

phục vụ việc giám sát, điều khiển, ra quyết định và các hoạt động quản trị hay hỗ trợ ra các quyết định quan trọng (ít có cấu trúc) với các yêu cầu về thông tin không rõ ràng Ví dụ hệ thông tin quản lý, hệ hỗ trợ quyết định, hệ quản lý bán hàng cần biết hàng tồn kho, ngân sách hàng năm để lập kế hoạch sản xuất, phân tích chi phí, phân tích giá cả/lợi nhuận

14

Trang 15

Các hệ thống chiến lược:Dành cho các nhà quản lý chính để giúp

giải quyết và vạch ra các chiến lược và các xu hướng lâu dài; so

sánh khả năng của tổ chức với những thay đổi của môi trường

bên ngoài và cơ hội xảy ra trong khoảng thời gian dài Ví dụ, hệ

hỗ trợ thực thi cho dự đoán ngân sách, xu hướng bán hàng trong

năm năm, kế hoạch hoạt động trong năm năm, kế hoạch về lợi

nhuận, nhân lực.

15

Trang 16

Ví dụ các hệ thống thông tin

16

Trang 17

Biểu diễn hệ thống thông tin

Dữ liệu Bộ xử lý CPU Con người Cơ sở

Trang 18

 Từ quan đi ểm ba trục toạ độ, người ta cũng nhận thấy rằng, có hai yếu tố tham gia vào quá trình phân tích

thiết kế HTTT là chất lượng và giá thành Hai yếu tố này không tương thích với nhau.

 Rõ ràng để gi ảm giá thành, cần xem xét hai trục thành phần và giai đoạn, để nâng cao chất lượng, cần chú ý trục mức là độ sâu sắc của sản phẩm Trên thực tế, người ta phải ước tính giá thành (cost estimation).

Trang 19

STT Nội dung công việc Tỷ lệ % Nhân lực

giá thành

Đặc tả bên ngoài của hệ thống.

24 % 240 ngày/người Phân tích tổng quan các xử lý

Đặc tả bên trong của hệ thống.

Trang 20

Vòng đời phát triển hệ thống

 Vòng đời phát triển hệ thống SDLC (System Development Life Cycle)

bao gồm nhiều giai đoạn, kể từ khi bắt đầu phát triển hệ thống cho đến khi kết thúc khai thác hệ thống.

 Các bước chính phát triển hệ thống trong thực tiễn:

Trang 21

Lập kế hoạch

Người ta thường cấu trúc hoá việc lập kế hoạch bằng cách :

- Tách riêng các phân bố nhân lực, thời gian và kinh phí

- Lập dự án tổng thể, kế hoạch cho một giai đoạn và các kế hoạch chi tiết

Song song với việc lập kế hoạch là việc kiểm tra, báo cáo định kỳ

Trang 22

Khảo sát

 Khảo sát hiện trạng là giai đoạn trong quá trình phát triển một hệ thống thông tin Nhiệm vụ chính trong giai đoạn này là tìm hiểu, thu thập thông tin cần thiết để chuẩn bị cho việc giải quyết các yêu cầu được đặt ra của dự án Giai đoạn khảo sát được chia làm hai bước:

Trang 23

Bước 1:

nghiệp

bản, nghiệp vụ) phục vụ cho việc phân tích và thiết kế

Bước 2: Đặt ra các vấn đề trọng tâm cần phải giải quyết, như:

nào?

Trang 24

Ví dụ

đã có (hoặc chưa có) =>

liệu dạng văn bản, các công văn, giấy tờ thể hiện quy trình nghiệp vụ của X.

người đứng đầu của X.

dự kiến của hệ thống Biên bản này sẽ là kết quả cho sự hợp tác thành công hay thất bại

Trang 25

Phân tích, thiết kế

Phân tích hệ thống

thống, cụ thể như sau:

phải xử lý đảm bảo tính chính xác, tuân thủ đúng các văn bản luật và quyđịnh hiện hành; đảm bảo tốc độ xử lý và khả năng nâng cấp trong tương lai

bảng dữ liệu (relationship) và ràng buộc (constraint) dữ liệu cần thiết

Trang 26

Thiết kế

Bước 1: Thiết kế tổng thể

 Trên cơ sở các bảng dữ liệu đã phân tích và đặc tả trên giấy sẽ được thiết kế dưới dạng mô hình tổng quát

Bước 2: Thiết kế chi tiết

• Thiết kế cơ sở dữ liệu (Database):

• Thiết kế truy vấn, thủ tục, hàm: thu thập, xử lý thông tin nhập và đưa ra thông tin chuẩn xác theo đúng nghiệp vụ.

• Thiết kế giao diện chương trình đảm bảo phù hợp với môi trường, văn hóa và yêu cầu của doanh nghiệp thực hiện dự án.

• Thiết kế chức năng chương trình đảm bảo tính logic trong quá trình nhập liệu và xử lý cho người dùng.

• Thiết kế báo cáo Dựa trên các yêu cầu của mỗi doanh nghiệp và quy định hiện hành sẽ thiết kế các mẫu báo cáo phù hợp hoặc cho phép doanh nghiệp tư tạo mẫu báo cáo ngay trên hệ thống.

• Thiết kế các kiểm soát bằng hình thức đưa ra các thông báo, cảnh báo hoặc lỗi cụ thể tạo tiện lợi và kiểm soát chặt chẽ quá trình nhập liệu với mục tiêu tăng độ chính xác cho dữ liệu.

Trang 27

Kiểm thử

• Trước hết phải lựa chọn công cụ kiểm thử.

các thiết kế thành các chương trình (phần mềm).

• Thử nghiệm hệ thống thông tin.

• Cuối cùng là khắc phục các lỗi (nếu có).

• Viết test case theo yêu cầu.

Trang 28

Triển khai, bảo trì

chuyển đổi dữ liệu; bố trí, sắp xếp người làm việc trong hệ thống; tổ chức hệ thống quản lý và bảo trì.

• Phát hiện các sai sót, khuyết điểm của hệ thống thông tin.

• Cải tiến và chỉnh sửa hệ thống thông tin.

Trang 29

Phương pháp luận phát triển các HTTT

29

Cách tiếp cận định hướng tiến trình:

• Thay đổi một tiến trình xử lý, kéo theo phải thay đổi các file dữ liệu tương ứng

• Tồn tại nhiều file dữ liệu riêng biệt trong những ứng dụng khác nhau nhưng lại

chứa nhiều phần tử dữ liệu giống nhau

• Tạo ra sự dư thừa dữ liệu.

• Tốn công sức thu thập và tổ chức lại dữ liệu.

• Không thể chia sẻ dữ liệu giữa các ứng dụng với nhau

Hệ thống quản lý tiền lương

Trang 30

Phương pháp luận phát triển các HTTT (tt.)

30

Cách tiếp cận định hướng dữ liệu :

• Tổ chức dữ liệu một cách tập trung, nhất quán

• Tách dữ liệu ra khỏi các tiến trình xử lý.

• Tổ chức cơ sở dữ liệu chung cho các ứng dụng.

• => cách tiếp cận này thì tối ưu về phương tiện lưu trữ và sử dụng tuy nhiện

do việc tập trung vào dữ liệu, nên khá xa rời với các hoạt động nghiệp vụ của doanh nghiệp

Trang 31

Phương pháp luận phát triển các HTTT (tt.)

31

Cách tiếp cận định hướng cấu trúc :

• Phân rã bài toán thành các bài toán nhỏ hơn

• Quá trình làm mịn dần (phân rã) sẽ dừng lại khi các bài toán con có

thể cài đặt được ngay với giải thuật đủ đơn giản

• Chương trình sáng sủa, dễ hiểu, dễ theo dõi.

• Tư duy giải thuật rõ ràng.

• Không hỗ trợ việc sử dụng lại.

• Không phù hợp cho việc phát triển các hệ thống thông tin lớn, phức tạp.

Trang 32

Phương pháp luận phát triển các HTTT (tt.)

32

thực

• Hệ thống được chia thành các đối tượng chứa dữ liệu và hành động

• Phần mềm được xây dựng bằng cách kết hợp các đối tượng trên lại với

nhau thông qua các mối quan hệ và các tương tác giữa chúng

• Các đối tượng chỉ thực hiện hành động khi nhận được yêu cầu

Trang 33

So sánh phương pháp hướng cấu trúc và hướng đối tượng

33

 Phương pháp hướng cấu trúc là phương pháp chia chương trình

chính thành các chương trình con, mỗi chương trình con thực hiện 1

công việc xác định

 – Phần mềm được thiết kế theo 2 hướng: hướng dữ liệu và

hướng hàng động

• Tiếp cận hướng dữ liệu: dựa vào yêu cầu lưu trữ dữ liệu của phần

mềm mà xây dựng các chức năng của hệ thống

• Tiếp cận theo hướng hành động: dựa vào các hành động của phần

mềm để tạo ra cơ sở dữ liệu

 – Cách thức thực hiện là thiết kế từ trên xuống( top-down),

phương pháp này tiến hành phân rã bài toán lớn thành các bài toán

con, phân chia đến các hàm và thủ tục

Trang 34

 Ưu nhược điểm của phương pháp hướng cấu trúc?

• tư duy phân tích thiết kế rõ ràng: tập trung vào mục đích của

chương trình, dễ chia ra các hành động hoặc cơ sở dữ liệu cho

chương trình

• chương trình sáng sủa, dễ hiểu: mô tả đúng các chức năng của

hệ thống.

• Không thể sử dụng lại: do 1 chương trình có 1 cấu trúc riêng, bài

toán cụ thể nên không thể dùng lại các modul nào trong phần

mềm

• Không phù hợp với phần mềm lớn: theo phân tích hướng cấu

trúc, các modul có quan hệ với nhau nên không thể chia ra để

34

Trang 35

Phương pháp HƯỚNG ĐỐI TƯỢNG

 Tập trung 2 khía cạnh dữ liệu và hành động

 Một hệ thống được chia ứng dụng thành các thành phần nhỏ, gọi là các đối tượng, 1 đối tượng bao gồm: dữ liệu và hành động, chúng tương đối độc lập với nhau Sau đó ta có thể xây dựng ứng dụng bằng cách chắp các đối tượng đó lại với nhau.

 – Chức năng của hệ thống được biểu diễn thông qua cộng tác của đối tượng, việc thay đổi chức năng, tiến hóa chức năng không làm

thay đổi đến cấu trúc tĩnh của phần mềm

35

Trang 36

Ưu điểm của phương pháp hướng đối tượng?

 – Tính tái sử dụng: có thể tạo các thành phần (đối tượng) một lần

và dùng chúng nhiều lần sau đó.

 – Đóng gói, che dấu thông tin làm cho hệ thống tin cậy hơn

 – Thừa kế giảm chi phí, hệ thống có tính mở cao

 – Phù hợp với hệ thống lớn và phức tạp

Trang 37

Mô hình hoá trực quan

37

 Mô hình hóa là cách xem xét một bài toán thông qua việc sử dụng các mô hình Mô

hình dùng để hiểu rõ bài toán, trao đổi thông tin giữa những người liên quan như

khách hàng, chuyên gia, người phân tích, người thiết kế…

vật trong một lĩnh vực ứng dụng nào đó theo một quan điểm nhất định

sự vật mà mình quan tâm và biểu diễn theo một tập ký hiệu hoặc quy

tắc nào đó

 Ví dụ, khi xây dựng Hệ quản lý bán hàng thì ta chỉ cần quan tâm đến các thuộc tính

như họ tên, địa chỉ, phone, email…của đối tượng khách hàng Trong khi xây dựng hệ

Quản lý Học tập theo tín chỉ ngoài các thông tin liên quan đến đối tượng sinh viên

như họ tên, địa chỉ, email, phone…ta còn phải quan tâm đến các thuộc tính như

điểm, lớp học, môn học, khoa mà sinh viên đăng ký.

Trang 38

Mô hình hoá trực quan

38

Trang 39

Mục đích mô hình

 Nắm bắt chính xác yêu cầu và tri thức miền mà hệ thống cần phát

triển

 Thể hịên tư duy về thiết kế hệ thống

 Trợ giúp ra quyết định thiết kế dựa trên việc phân tích yêu cầu

 Tổ chức, tìm kiếm, lọc, kiểm tra và sửa đổi thông tin về các hệ thống

lớn.

 Làm chủ được các hệ thống phức tạp

39

Trang 41

Mô hình phát triển thác nước

(Waterfall Development Model)

41

Trang 43

 Phải kết thúc giai đoạn rồi mới qua giai đoạn kế tiếp

Trang 44

Mô hình thác nước cải tiến

44

Trang 45

 Có thể quay lại các bước trước đó để sửa lỗi rồi mới

tiếp tục

 Ưu điểm;

 tất cả các pha trong vòng đời phần mềm theo mô hình thác nước

đều được viết tài liệu cẩn thận và được kiểm tra bởi nhóm SQA

trước khi chuyển sang pha tiếp theo Do vậy, hệ thống sẽ dễ dàng

bảo trì khi có những thay đổiNhanh, gọn

 Hạn chế;

45

Trang 46

 Mô hình thác nước cũng có nhược điểm là sản phẩm phần mềm

cuối cùng có thể không thỏa mãn nhu cầu thực sự của khách

hàng Lý do là khách hàng chỉ được trao đổi một lần duy nhất và

chưa được hình dung sản phẩm nên rất có thể các pha tiếp theo

sẽ không thực hiện đúng những gì khách hàng cần

46

Trang 47

Mô hình prototype

47

Trang 48

 Có một vòng lặp để tạo ra sản phẩm mẫu để đánh giá và xác định rõ

yêu cầu Khi xác định rõ yêu cầu thì bước vào phát triển phần mềm

 Ưu điểm

Có sản phẩm mẫu để đánh giá và xác định yêu cầu

Sản phẩm làm tốt => tăng tốc để phát triển sản phẩm chính

 Hạn chế:

Chưa tối ưu hệ thống lớn, cân vừa triển khai vừa nghiên cứu

Tốn chi phí tạo ra sản phẩm mẫu

48

Trang 49

Mô hình xoắn ốc

49

Trang 50

 Bản chất tương tự mô hình prototype Nhiều lần tạo ra các prototype

và sản phẩm Mỗi lần như vậy sẽ được đánh giá hoàn thiện hay không và tiếp tục dựa trên sản phẩm để đánh giá hoàn thiện hay không và dựa trên sản phẩm để hoàn thiện prototype tiếp

50

Trang 51

Các đội dự án xây dựng ứng dụng thường

không mô hình hoá

51

 Bắt đầu lập trình ngay khi có được yêu cầu.

 Mất rất nhiều thời gian và công sức.

 Tạo ra rất nhiều mã nguồn.

 Không có bất kỳ một kiến trúc nào.

 Gặp khó khăn với những lỗi phát sinh.

-> Mô hình hoá là một con đường dẫn đến thành công của

các dự án phát triển phần mềm.

Trang 52

Tại sao phải mô hình hoá?

52

 Hình dung về hệ thống như mong đợi.

 Chỉ định cấu trúc hoặc hành vi cho hệ thống.

 Đưa ra một khuôn mẫu hướng dẫn xây dựng hệ thống.

 Tài liệu hoá hệ thống.

 Hiểu rõ hơn về hệ thống cần phát triển.

Trang 53

 Phân rã một chức năng tổng hợp thành những chức năng chi tiết hơn.

Quản lý xuất hàng

Quản lý hàng tồn Bán lẻ

Quản lý đơn hàng

Quản lý công nợ

Quan hệ bao hàm

Trang 54

 Quá trình xử lý đơn đặt hàng:

Mô hình luân chuyển (hệ thống)

54

Trang 55

Thông báo từ chối ĐĐH

Đơn đặt hàng

ĐĐH không hợp lệ

Lưu ĐĐH

ĐĐH hợp lệ

Tính tồn kho

Lập hóa đơn giao hàng

Hoá đơn giao hàng

ĐĐH bị từ chối

Băng đĩa giao + hóa đơn

ĐĐH đủ hàng giao

ĐĐH

Tồn kho băng đĩa

Thông tin tồn kho

ĐĐH mới

Đơn đặt hàng

Hóa đơn giao hàng

Xử lý Dòng dữ liệu Đầu cuối Kho dữ liệu

Trang 56

 Các trạng thái của một đơn đặt hàng:

Mô hình động (mô hình trạng thái)

56

Trang 57

Mô hình dữ liệu (mô hình quan hệ)

57

 BANGDIA(MA_BD, TEN_BD, LOAI, DVTINH, DON_GIA)

 ĐĐHANG_NGK(SO_DDH, NGAY_DAT, KHACH_HANG,

NGAYGIAO, TRANG THAI)

 CHITIET_DDH(MA_BD, SO_DDH, SL_DAT, DONGIA_DAT)

Trang 58

Mô hình dữ liệu (mô hình thực thể kết hợp)

58

Trang 59

 Mô hình đối tượng theo OOA:

Mô hình đối tượng

59

Lớp & đối tượng

Kết hợp

Tổng quát hoá (IS – A)

Thành phần (Is – Part - Of)

Thông điệp (Message)

Đối tác

Mã số Tên Địa chỉ

BANGDIA

Mã số Tên Đơn giá

ĐĐ Hàng

Mã số Tổng trị giá Tính trị gia ĐĐ hàng()

BD đặt

Số lượng đặt Trị giá()

Trang 60

4 nguyên tắc cơ bản khi mô hình hoá

60

Việc lựa chọn mô hình đóng vai trò rất quan trọng:

• Trong phát triển phần mềm, các mô hình được chọn bị ảnh hưởng từ

thế giới quan

• Mỗi thế giới quan dẫn đến một loại hệ thống riêng biệt.

Mỗi mô hình mô tả hệ thống với mức độ chính xác khác nhau:

• Việc lựa chọn mức độ chi tiết phụ thuộc:

• Ai đang xem mô hình?

• Tại sao cần phải xem mô hình?

Trang 61

4 nguyên tắc cơ bản khi mô hình hoá (tt.)

61

 Các mô hình tốt nhất là các mô hình liên kết với thế giới thực:

• Tất cả các mô hình đều là quá trình đơn giản hoá thế giới thực

• Một mô hình tốt sẽ phản chiếu các đặc tính bất thường tiềm ẩn

 Không mô hình đơn lẻ nào là đầy đủ:

• Cách tiếp cận tốt nhất để xây dựng một hệ thống phần mềm là thông qua một tập các mô hình gần như độc lập với nhau

Ngày đăng: 05/09/2023, 12:40

HÌNH ẢNH LIÊN QUAN

Hình dùng để hiểu rõ bài toán, trao đổi thông tin giữa những người liên quan như - Bài Giảng Phân Tích, Thiết Kế Hệ Thống Thông Tin ( Combo Full Slide 6 Module  Bài Giảng)
Hình d ùng để hiểu rõ bài toán, trao đổi thông tin giữa những người liên quan như (Trang 37)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

🧩 Sản phẩm bạn có thể quan tâm

w