Phân tích thiết kế Hệ thống quản lý thiết bị và sự cố tin học theo hướng đối tượng

Mục đích nghiên cứu: Thực hiện luận văn với đề tài “Phân tích thiết kế Hệ thống Quản lý thiết bị và sự cố tin học theo hướng đối tượng” nhằm giúp tôi tìm hiểu sâu về phương pháp mô hình

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

TRẦN THỊ LAN PHƯƠNG

PHÂN TÍCH THIẾT KẾ "HỆ THỐNG QUẢN LÝ THIẾT BỊ VÀ SỰ CỐ TIN HỌC”

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

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội – 2013

ĐẠI HỌC QUỐC GIA HÀ NỘI

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: Tiến sỹ Lê Văn Phùng

Hà Nội - 2013

MỞ ĐẦU 1

CHƯƠNG 1 HIỆN TRẠNG CÔNG TÁC QUẢN LÝ THIẾT BỊ VÀ SỰ CỐ TIN HỌC TẠI TRUNG TÂM TIN HỌC - BỘ KẾ HOẠCH VÀ ĐẦU TƯ 3

1.1 Giới thiệu khái quát về Bộ Kế hoạch và Đầu tư 3

1.2 Giới thiệu khái quát về Trung tâm Tin học - Bộ Kế hoạch và Đầu tư 3

1.3 Sự cần thiết phải xây dựng Hệ thống Quản lý thiết bị và sự cố tin học 6

CHƯƠNG 2 CƠ SỞ LÝ LUẬN XÂY DỰNG HỆ THỐNG QUẢN LÝ THIẾT BỊ VÀ SỰ CỐ TIN HỌC THEO HƯỚNG ĐỐI TƯỢNG 8

2.1 Tổng quan về cách tiếp cận hướng đối tượng 8

2.2 Ngôn ngữ mô hình hóa thống nhất (UML) 11

2.2.1 Giới thiệu tổng quát về UML 11

2.2.2 Các khối xây dựng (building blocks) cơ bản của UML 13

2.2.2.1 Các sự vật (things) 14

2.2.2.2 Các mối quan hệ (relationships) 17

2.2.2.3 Các sơ đồ 17

2.2.3 Một số khái niệm cơ bản trong UML 18

2.2.3.1 Các đối tượng 19

2.2.3.2 Lớp các đối tượng 19

2.2.3.3 Các giá trị và thuộc tính của đối tượng 19

2.2.3.4 Các thao tác và phương thức 20

2.2.3.5 Các gói 20

2.2.4 Các quy tắc ngữ nghĩa của UML 20

2.2.5 Các cơ chế chung trong UML 21

2.2.5.1 Các đặc tả (Specification) 21

2.2.5.2 Các bài trí (Adornments) 21

2.2.5.3 Sự phân hoạch chung (Common divisions) 21

2.2.5.4 Các cơ chế mở rộng (Extensibility mechanisms) 21

2.2.6 Các quy tắc ràng buộc và suy diễn 21

2.3 Quá trình phát triển phần mềm hướng đối tượng 22

2.3.1 Xác định các yêu cầu của hệ thống 22

2.3.1.1 Xây dựng mô hình nghiệp vụ 22

2.3.2 Phân tích hệ thống 27

2.3.2.1 Phân tích kiến trúc 28

2.3.2.2 Phân tích một ca sử dụng 29

2.3.2.3 Phân tích một lớp 30

2.3.2.4 Phân tích một gói 30

2.3.3 Thiết kế hệ thống 30

2.3.3.2 Thiết kế một ca sử dụng 32

2.3.3.3 Thiết kế một lớp 34

2.3.3.4 Thiết kế một hệ thống con 35

2.3.4 Lập trình và kiểm tra chương trình 36

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

2.4 Tổng quan về mẫu thiết kế trong kỹ nghệ hướng đối tượng 37

2.4.1 Mẫu thiết kế 37

2.4.1.1 Khái niệm mẫu thiết kế 37

2.4.1.2 Các thành phần của mẫu thiết kế 37

2.4.2 Phân tích và thiết kế hướng mẫu trong công nghệ hướng đối tượng 38

2.4.2.1 Vai trò của mẫu trong phát triển phần mềm 38

2.4.2.2 Mục đích của việc phân tích thiết kế hướng mẫu 39

2.4.2.3 Những vấn đề thiết kế hướng mẫu 39

2.4.3 Phân loại mẫu thiết kế 40

2.4.3.1 Phân loại theo mục đích sử dụng 40

2.4.3.2 Phân loại theo phạm vi sử dụng 40

CHƯƠNG 3 ỨNG DỤNG CÁCH TIẾP CẬN HƯỚNG ĐỐI TƯỢNG ĐỂ PHÂN TÍCH THIẾT KẾ HỆ THỐNG QUẢN LÝ THIẾT BỊ VÀ SỰ CỐ TIN HỌC 41

3.1 Bài toán Quản lý thiết bị và sự cố tin học tại Trung tâm tin học - Bộ Kế hoạch và Đầu tư 41

3.1.1 Mục tiêu và yêu cầu khi xây dựng Hệ thống Quản lý thiết bị và sự cố tin học 41

3.1.1.1 Mục tiêu tổng quát 41

3.1.1.2 Mục tiêu và yêu cầu cụ thể 41

3.1.2 Mô tả nghiệp vụ quản lý thiết bị và sự cố tin học 42

3.2 Các mô hình phân tích 45

3.2.1 Phân tích các chức năng của hệ thống 45

3.2.2 Phân tích các ca sử dụng 46

3.2.2.1 Các tác nhân của hệ thống 46

3.2.2.2 Danh sách các ca sử dụng 46

3.2.2.3 Mô hình các ca sử dụng và mô tả các ca sử dụng mô hình miền 47

3.2.3 Mô hình lớp 62

3.2.3.1 Vấn đề xác định lớp 62

3.2.3.2 Xây dựng biểu đồ lớp trong pha phân tích 63

3.3 Các mô hình thiết kế 66

3.3.1 Biểu đồ cộng tác của các ca sử dụng 66

3.3.2 Biểu đồ trình tự thực thi các ca sử dụng 68

3.3.3 Biểu đồ hoạt động 70

3.3.4 Biểu đồ lớp chi tiết 72

3.3.5 Biểu đồ thành phần 73

3.3.6 Biểu đồ triển khai 73

3.4 Cài đặt chương trình quản lý thiết bị và sự cố tin học 74

3.4.1 Môi trường cài đặt 74

3.4.1.1 Ngôn ngữ lập trình 74

3.4.1.2 Hệ quản trị cơ sở dữ liệu SQL 75

3.4.2 Hướng dẫn cài đặt và sử dụng phần mềm 76

3.4.3 Các module chương trình 76

3.4.4 Thiết kế các Form 76

KẾT LUẬN 80

TÀI LIỆU THAM KHẢO 81

Bảng 3.1 Bảng các chức năng của hệ thống 45

Bảng 3.2 Bảng các bước trong ca sử dụng Tạo mới người sử dụng 48

Bảng 3.3 Bảng các bước trong ca sử dụng Tạo dữ liệu phân quyền người sử dụng 49

Bảng 3.4 Bảng các bước trong ca sử dụng Sửa thông tin người sử dụng 49

Bảng 3.5 Bảng các bước trong ca sử dụng Xóa thông tin người sử dụng 50

Bảng 3.6 Bảng các bước trong ca sử dụng Tìm kiếm thông tin người sử dụng 51 Bảng 3.7 Bảng các bước trong ca sử dụng Nhập thêm danh mục 51

Bảng 3.8 Bảng các bước trong ca sử dụng Sửa thông tin danh mục 52

Bảng 3.9 Bảng các bước trong ca sử dụng Xóa thông tin danh mục 53

Bảng 3.10 Bảng các bước trong ca sử dụng Thêm thiết bị 53

Bảng 3.11 Bảng các bước trong ca sử dụng Sửa thông tin thiết bị 54

Bảng 3.12 Bảng các bước trong ca sử dụng Xóa thông tin thiết bị 55

Bảng 3.13 Bảng các bước trong ca sử dụng Thêm thông tin nhập/xuất linh kiện 55

Bảng 3.14 Bảng các bước trong ca sử dụng Sửa thông tin nhập/xuất 56

Bảng 3.15 Bảng các bước trong ca sử dụng Xóa thông tin nhập/xuất 57

Bảng 3.16 Bảng các bước trong ca sử dụng Thêm thông tin sự cố tin học 57

Bảng 3.17 Bảng các bước trong ca sử dụng Sửa thông tin sự cố tin học 58

Bảng 3.18 Bảng các bước trong ca sử dụng Xóa thông tin sự cố tin học 59

Bảng 3.19 Bảng các bước trong ca sử dụng Tra cứu hồ sơ thiết bị 59

Bảng 3.20 Bảng các bước trong ca sử dụng Tra cứu hồ sơ sự cố 60

Bảng 3.21 Bảng các bước trong ca sử dụng Kết xuất báo cáo thống kê tài sản 61 Bảng 3.22 Bảng các bước trong ca sử dụng Kết xuất báo cáo thống kê sự cố 61

Bảng 3.23 Bảng các bước trong ca sử dụng Kết xuất báo cáo thống kê chi tiết thiết bị 62

Hình 2.1: Tập các lớp đối tượng của hệ thống 9

Hình 2.2 Sự phát triển của UML 11

Hình 2.3 Mô hình hóa kiến trúc hệ thống 12

Hình 2.4 Các thành phần cơ sở của UML 13

Hình 2.5 Lớp 14

Hình 2.6 Giao diện 14

Hình 2.7 Sự cộng tác 14

Hình 2.8 Ca sử dụng 15

Hình 2.9 Lớp 15

Hình 2.10 Thành phần 15

Hình 2.11 Nút 15

Hình 2.12 Thông điệp/thông báo 16

Hình 2.13 Trạng thái 16

Hình 2.14 Gói 16

Hình 2.15 Chú thích 16

Hình 2.16 Quan hệ phụ thuộc 17

Hình 2.17 Kết hợp 17

Hình 2.18 Tổng quát hóa 17

Hình 2.19 Thực hiện hóa 17

Hình 3.1 Mô hình ca sử dụng toàn hệ thống 47

Hình 3.2 Mô hình ca sử dụng gói Quản lý người dùng 48

Hình 3.3 Mô hình ca sử dụng gói Quản lý danh mu ̣c 51

Hình 3.4 Mô hình ca sử dụng gói Quản lý thiết bị 53

Hình 3.5 Mô hình ca sử dụng gói Qua ̉n lý nhâ ̣p xuất 55

Hình 3.6 Mô hình ca sử dụng gói Qua ̉n lý sự cố tin ho ̣c 57

Hình 3.7 Mô hình ca sử dụng gói Tra cư ́ u hồ sơ 59

Hình 3.8 Mô hình ca sử dụng gói Kết xuất ba ́o cáo thống kê 60

Hình 3.9 Biểu đồ lớp của hệ thống quản lý thiết bi ̣ và sự cố tin ho ̣c 64

Hình 3.10 Biểu đồ cộng tác thực thi ca sử dụng Nhập mới người sử dụng 67

Hình 3.11 Biểu đồ cộng tác thực thi ca sử dụng Thêm thông tin sự cố 67

Hình 3.12 Biểu đồ cộng tác thực thi ca sử dụng Sửa thông tin sự cố 68

Hình 3.13 Biểu đồ cộng tác thực thi ca sử dụng Xóa thông tin sự cố 68

Hình 3.14 Biểu đồ trình tự thực thi ca sử dụng Thêm người sử dụng 69

Hình 3.15 Biểu đồ trình tự thực thi ca sử dụng Tiếp nhâ ̣n sự cố 69

Hình 3.16 Biểu đồ trình tự thực thi ca sử dụng Phân bổ xư ̉ lý sự cố 70

Hình 3.17 Biểu đồ trình tự thực thi ca sử dụng Xử lý sự cố 70

Hình 3.18 Biểu đồ hoạt động thực thi ca sử dụng Đăng nhâ ̣p 71

Hình 3.19 Biểu đồ hoạt động thực thi ca sử dụng Nhâ ̣p thông tin sự cố tin ho ̣c 72 Hình 3.20 Biểu đồ lớp chi tiết của chương trình 72

Hình 3.21 Biểu đồ thành phần của chương trình 73

Hình 3.22 Biểu đồ triển khai của chương trình 74

MỞ ĐẦU

Nhiệm vụ của các ngành khoa học là nghiên cứu các quá trình, các qui luật tự nhiên, tính chất và hành vi của các hệ thống để mô hình hoá, đề xuất những phương pháp để giải quyết những vấn đề xảy ra trong các hoạt động của con người sao cho hiệu quả nhất, sao cho phù hợp với các qui luật xã hội và tự nhiên nhất Đóng góp vào

sứ mệnh chung của các ngành khoa học, ngành công nghệ phần mềm thực hiện nhiệm

vụ nghiên cứu các mô hình, phương pháp và công cụ để tạo ra những hệ thống phần mềm chất lượng cao trong phạm vi hạn chế về tài nguyên nhằm đáp ứng được những nhu cầu thường xuyên thay đổi của khách hàng, giải quyết được những vấn đề phức tạp đặt ra trong thực tế

Trong công nghệ phần mềm, nhiều mô hình, phương pháp phát triển phần mềm

đã lần lượt ra đời với những ưu, nhược điểm riêng, có thể được ưa chuộng ở nơi này, ở lĩnh vực nào đó nhưng lại không được ưa chuộng ở những nơi khác Trải qua thời gian, một số phương pháp như các phương pháp có cấu trúc vẫn có sức sống dẻo dai, vẫn đang được áp dụng rộng rãi trong thực tế Tuy vẫn chưa lạc hậu và còn phát huy tác dụng trong những hệ thống có cấu trúc dữ liệu tương đối thuần nhất, nhưng do sự phong phú về phương pháp luận và sự đa dạng về sự biểu diễn các khái niệm (các ký hiệu rất khác nhau, không thống nhất) dẫn tới khó có thể đưa ra được một qui trình thống nhất cho quá trình phát triển phần mềm Mặt khác, nhiều vấn đề phức tạp mới xuất hiện, không chỉ yêu cầu tính toán lớn, xử lý phân tán, thường xuyên thay đổi các yêu cầu mà còn đòi hỏi phải quản lý với nhiều loại dữ liệu khác nhau, dữ liệu đa phương tiện, dữ liệu âm thanh, hình ảnh, v.v

Tới những năm 90 của thế kỷ 20, sự ra đời của phương pháp hướng đối tượng

đã đáp ứng được các tiêu chuẩn phần mềm theo yêu cầu của nền công nghệ thông tin hiện đại, giải quyết được những vấn đề phức tạp của thực tế đặt ra trong thế kỷ 21 Cách tiếp cận hướng đối tượng đặt trọng tâm vào việc xây dựng lý thuyết cho các hệ thống tổng quát như là mô hình khái niệm cơ sở Hệ thống được xem như là tập các đối tượng tác động với nhau trên cơ sở truyền thông điệp để thực thi các nhiệm vụ đặt

ra trong hệ thống đó Cách tiếp cận này rất phù hợp với cách quan sát và quan niệm của chúng ta về thế giới xung quanh và tạo ra những công cụ mới, hữu hiệu để phát triển các hệ thống có tính mở, dễ thay đổi theo yêu cầu của người sử dụng

Có thể nói, hiện nay, giải pháp hướng đối tượng là một giải pháp tốt đang được

sự quan tâm đặc biệt và nhiều công ty đã triển khai mặc dù giải pháp này vẫn còn tiếp tục được cải tiến cùng với mô hình phát triển phần mềm Cùng với phương pháp luận, phương pháp phát triển phần mềm hướng đối tượng, công cụ UML (Unified Modeling Language) đã cung cấp một phương tiện mạnh cho phép triển khai phương pháp trên trong môi trường công nghiệp UML là một ngôn ngữ mô hình hoá dùng để đặc tả, mô hình hoá, xây dựng và làm tài liệu cho một hệ thống phần mềm hướng đối tượng Ngôn ngữ này thể hiện trực quan được những quyết định và sự hiểu biết của chúng ta

về hệ thống cần xây dựng Nó là một công cụ mạnh và đầy đủ được dùng để phân tích, thiết kế, cài đặt, bảo trì và kiểm soát thông tin của hệ thống phần mềm lớn và phức tạp

Không chỉ vậy, các thay đổi yêu cầu từ phía khách hàng, các điều kiện phát sinh hay việc thiết kế một cách cứng nhắc trong quá trình thiết kế thường làm cho hệ thống trở nên rối rắm, các mô đun càng ngày càng bị phụ thuộc vào nhau Việc tìm cách áp dụng những mô hình đã thành công trong thực tế đối với một số bài toán tương tự đã từng gặp vào thiết kế của mình mà không cần phải xem xét lại từ đầu, đảm bảo tiết kiệm chi phí, thời gian xây dựng và phát triển, nâng cao độ tin cậy và chất lượng phần mềm cũng là giải pháp thể hiện ưu thế trong phát triển phần mềm Vì vậy việc nghiên cứu phương pháp phân tích, thiết kế hướng đối tượng, sử dụng UML và các mẫu thiết

kế để phát triển phần mềm đang là một xu hướng trong kỹ nghệ phần mềm Luận văn được thực hiện cũng không nằm ngoài xu hướng này

Mục đích nghiên cứu: Thực hiện luận văn với đề tài “Phân tích thiết kế Hệ

thống Quản lý thiết bị và sự cố tin học theo hướng đối tượng” nhằm giúp tôi tìm hiểu sâu về phương pháp mô hình hoá hệ thống phần mềm hướng đối tượng, các mẫu thiết

kế và các bước để phân tích, thiết kế một ứng dụng Đồng thời, luận văn thực hiện phân tích thiết kế "hệ thống quản lý thiết bị và sự cố tin học" góp phần vào việc tin học hóa công tác quản lý, mang lại sự hiệu quả, chính xác và tiết kiệm thời gian, công sức của cán bộ chuyên trách của Trung tâm tin học – đơn vị đầu mối chuyên trách về công nghệ thông tin của Bộ Kế hoạch và Đầu tư

Nội dung chính của luận văn:

 Tổng quan phương pháp phát triển phần mềm theo hướng đối tượng: Giới thiệu về hệ công cụ UML; Tìm hiểu quá trình phân tích, thiết kế hướng đối tượng; Tìm hiểu về mẫu thiết kế trong kỹ nghệ hướng đối tượng

 Vận dụng phương pháp và công cụ nêu trên tiến hành phân tích, thiết kế "hệ thống quản lý thiết bị và sự cố tin học" tại Trung tâm Tin học – Bộ Kế hoạch và Đầu tư

Cấu trúc luận văn: gồm 3 chương:

 Chương 1: Khảo sát hiện trạng quản lý thiết bị và sự cố tin học tại Trung tâm tin học – Bộ Kế hoạch và Đầu tư

 Chương 2: Giới thiệu tổng quan về phương pháp hướng đối tượng, quá trình phân tích thiết kế hướng đối tượng và mẫu thiết kế

 Chương 3: Ứng dụng cách tiếp cận hướng đối tượng để phân tích thiết kế

"hệ thống quản lý thiết bị và sự cố tin học”

Luận văn là kết quả bước đầu nghiên cứu khoa học, chắc chắn còn nhiều hạn chế, rất mong được sự đóng góp ý kiến của các thầy cô và các bạn Em cũng xin chân thành cảm ơn TS Lê Văn Phùng, người đã giúp đỡ em rất nhiều trong việc hoàn thành luận văn này

Hà Nội, tháng 9 năm 2013

Học viên thực hiện

Trần Thị Lan Phương

CHƯƠNG 1 HIỆN TRẠNG CÔNG TÁC QUẢN LÝ THIẾT BỊ VÀ SỰ CỐ TIN HỌC TẠI TRUNG TÂM TIN HỌC - BỘ KẾ HOẠCH VÀ ĐẦU TƯ

1.1 Giới thiệu khái quát về Bộ Kế hoạch và Đầu tư

Bộ Kế hoạch và Đầu tư là cơ quan của Chính phủ có chức năng tham mưu tổng hợp về xây dựng chiến lược, quy hoạch, kế hoạch phát triển kinh tế - xã hội của cả nước, về cơ chế, chính sách quản lý kinh tế, quản lý nhà nước về lĩnh vực đầu tư trong

và ngoài nước; giúp Chính phủ phối hợp điều hành thực hiện các mục tiêu và cân đối chủ yếu của nền kinh tế quốc dân

Về cơ cấu tổ chức, Bộ Kế hoạch và Đầu tư có 33 Cục, Vụ, Viện, Trung tâm, bao gồm:

- 6 Vụ, Văn phòng, Trung tâm đảm nhận chức năng quản lý và hỗ trợ cơ quan mà

Bộ nào cũng có (Văn phòng Bộ, Vụ Tổ chức cán bộ, Vụ Pháp chế, Thanh tra Bộ, Vụ Thi đua - Khen thưởng và Trung tâm Tin học);

- 8 Vụ tập trung vào các lĩnh vực kinh tế theo ngành và có liên quan đến các Bộ tương ứng (Vụ Tài chính tiền tệ, Vụ Kinh tế công nghiệp, Vụ Kinh tế nông nghiệp, Vụ Kinh tế dịch vụ, Vụ Kết cấu hạ tầng và đô thị, Vụ Quốc phòng - An ninh, Vụ Khoa học, Giáo dục, Tài nguyên và Môi trường, Vụ Lao động, Văn hóa và Xã hội);

- 11 Vụ, Cục tập trung vào các lĩnh vực liên quan đến nhiều ngành (Vụ Giám sát

và Thẩm định đầu tư, Vụ Quản lý quy hoạch, Cục Quản lý đấu thầu, Cục Đầu tư nước ngoài, Vụ Kinh tế địa phương và lãnh thổ, Vụ Tổng hợp kinh tế quốc dân, Vụ Kinh tế đối ngoại, Cục Phát triển doanh nghiệp, Cục Quản lý đăng ký kinh doanh, Vụ Hợp tác

xã, Vụ Quản lý các khu kinh tế);

- 6 Viện, Trung tâm, đơn vị thuộc Bộ thực hiện công tác nghiên cứu và phổ biến thông tin (Trung tâm Thông tin và dự báo kinh tế - xã hội quốc gia, Viện Chiến lược phát triển, Viện Quản lý kinh tế trung ương, Báo Đầu tư, Tạp chí Kinh tế và Dự báo, Học viện Chính sách và Phát triển, Trường Cao đẳng Kinh tế - Kế hoạch Đà Nẵng)

- Tổng cục Thống kê, chịu trách nhiệm thu thập, xử lý và phổ biến các dữ liệu thống kê và thực hiện quản lý nhà nước về công tác thống kê

Bộ Kế hoạch và Đầu tư có khoảng 1.470 cán bộ Tổng cục Thống kê có trên 5.000 cán bộ, trong đó khoảng 600 cán bộ tại Trung ương và số cán bộ còn lại tại các tỉnh thành hoặc quận huyện

1.2 Giới thiệu khái quát về Trung tâm Tin học - Bộ Kế hoạch và Đầu tư

Chức năng và nhiệm vụ của Trung tâm Tin học được quy định rõ Quyết định số 522/QĐ-BKH của Bộ trưởng Bộ Kế hoạch và Đầu tư ngày 16/04/2009

Trung tâm Tin học thuộc Bộ Kế hoạch và Đầu tư có chức năng tham mưu, giúp

Bộ trưởng thống nhất quản lý hoạt động ứng dụng công nghệ thông tin; nghiên cứu,

phát triển và ứng dụng công nghệ thông tin phục vụ các lĩnh vực công tác của Bộ Kế hoạch và Đầu tư và toàn ngành kế hoạch và đầu tư

Trung tâm Tin học là đơn vị sự nghiệp có thu, có con dấu và tài khoản riêng, được hoạt động tự chủ theo quy định của pháp luật và phân cấp quản lý của Bộ trưởng

Bộ Kế hoạch và Đầu tư

Trung tâm Tin học có 9 nhiệm vụ chuyên môn chính:

(1) Tổ chức xây dựng chiến lược, quy hoạch, kế hoạch tổng thể ứng dụng công nghệ thông tin trong Ngành, trình Bộ trưởng phê duyệt và quản lý thực hiện sau khi được phê duyệt; hướng dẫn các đơn vị thuộc Bộ xây dựng các kế hoạch và các dự án ứng dụng công nghệ thông tin phù hợp với kế hoạch tổng thể đã được phê duyệt; tổ chức theo dõi, giám sát việc thực hiện các kế hoạch, dự án ứng dụng công nghệ thông tin theo quy định của pháp luật; tổ chức thực hiện các dự án được Bộ trưởng giao làm chủ đầu tư

(2) Quản lý thống nhất các hoạt động ứng dụng công nghệ thông tin, bao gồm: Chủ trì xây dựng, trình Bộ trưởng ban hành các chế độ, chính sách, quy định về quản

lý hoạt động ứng dụng công nghệ thông tin trong toàn ngành Kế hoạch và Đầu tư; quy định về ứng dụng công nghệ thông tin áp dụng thống nhất trong toàn cơ quan Bộ và trong toàn ngành Kế hoạch và Đầu tư; tham gia góp ý kiến và đề xuất phương án phân

bổ các nguồn lực cho hoạt động ứng dụng công nghệ thông tin hàng năm của Bộ, bảo đảm phù hợp với kế hoạch tổng thể ứng dụng công nghệ thông tin đã được phê duyệt;

có ý kiến thẩm định về mặt kỹ thuật và công nghệ đối với các dự án ứng dụng công nghệ thông tin, các dự án có nội dung ứng dụng công nghệ thông tin của các đơn vị thuộc Bộ

(3) Kiểm tra việc thực hiện các quy định của Nhà nước, của Bộ trong hoạt động ứng dụng công nghệ thông tin, bao gồm: kiểm tra việc thực hiện các quy định về ứng dụng công nghệ thông tin áp dụng thống nhất trong cơ quan Bộ và toàn ngành Kế hoạch và Đầu tư; các quy định của nhà nước trong hoạt động ứng dụng công nghệ thông tin; các kế hoạch, dự án ứng dụng công nghệ thông tin theo quy định; kiến nghị với Bộ trưởng xử lý những sai phạm của các đơn vị và cá nhân thuộc Bộ trong hoạt động ứng dụng công nghệ thông tin

(4) Tổ chức xây dựng, quản lý và vận hành hệ thống kết cấu hạ tầng kỹ thuật công nghệ thông tin dùng chung của Bộ, bao gồm: Mạng diện rộng (WAN); mạng cục

bộ (LAN); Trung tâm dữ liệu và Trung tâm dữ liệu dự phòng; hệ thống mạng máy tính của Bộ; việc sử dụng Internet từ mạng máy tính của Bộ; chủ trì, phối hợp với các đơn

vị thuộc Bộ, các tổ chức liên quan thực hiện công tác bảo đảm an toàn và bảo mật hệ thống thông tin, cơ sở dữ liệu điện tử của Bộ;…

(5) Tổ chức xây dựng, quản lý và vận hành các hệ thống ứng dụng công nghệ thông tin dùng chung của Bộ, bao gồm: Cổng thông tin điện tử Bộ Kế hoạch và Đầu tư; Hệ thống thông tin điều hành nội bộ; Hệ thống thư điện tử; Hệ thống quản lý văn bản và hồ sơ công việc; Hệ thống hội nghị truyền hình và các hệ thống ứng dụng khác;

chủ trì, phối hợp với các đơn vị thuộc Bộ và các cơ quan liên quan xây dựng, tích hợp các cơ sở dữ liệu về các lĩnh vực thuộc phạm vi quản lý nhà nước của Bộ;…

(6) Chủ trì, phối hợp với Văn phòng Bộ, Người phát ngôn của Bộ và các tổ chức, đơn vị liên quan thu thập, lưu trữ, biên tập và cung cấp thông tin điện tử phục vụ công tác điều hành và quản lý nhà nước của Bộ

(7) Phối hợp với Vụ Tổ chức cán bộ xây dựng kế hoạch bồi dưỡng và nâng cao kiến thức về ứng dụng công nghệ thông tin cho các cán bộ, công chức, viên chức của Bộ; chủ trì và phối hợp với các đơn vị liên quan tổ chức thực hiện kế hoạch đã được phê duyệt Đào tạo, bồi dưỡng và cấp chứng chỉ công nghệ thông tin theo quy định của pháp luật và của Bộ

(8) Phối hợp với các đơn vị trong Bộ và các cơ quan liên quan hợp tác nghiên cứu, phát triển ứng dụng công nghệ thông tin theo sự phân công của Bộ

(9) Thực hiện cung cấp sản phẩm, dịch vụ công nghệ thông tin và thông tin theo quy định của pháp luật và của Bộ

Trong 9 nhiệm vụ nêu trên: 3 nhiệm vụ đầu tiên là hoạt động quản lý nhà nước

về mặt ứng dụng công nghệ thông tin trong phạm vi toàn ngành Kế hoạch và Đầu tư; nhiệm vụ thứ 4 đến thứ 7 là hoạt động kết hợp giữa quản lý và vận hành các hệ thống

kỹ thuật phục vụ các hoạt động nghiệp vụ của Bộ Kế hoạch và Đầu tư; Công tác quản

lý thiết bị và sự cố tin học cũng chính là một trong những công việc thường xuyên nhằm thực hiện nhiệm vụ thứ 4; nhiệm vụ thứ 8 là hoạt động nghiên cứu phát triển ứng dụng công nghệ thông tin phục vụ các hoạt động nghiệp vụ của Bộ Kế hoạch và Đầu tư; nhiệm vụ thứ 9 là hoạt động cung cấp các dịch vụ ứng dụng công nghệ thông tin và thông tin có thu để tạo điều kiện củng cố, phát triển nguồn lực về ứng dụng về công nghệ thông tin của Bộ Kế hoạch và Đầu tư

Trong những năm qua, Trung tâm Tin học đã động viên được tinh thần nỗ lực cao trong đơn vị, phấn đấu hoàn thành một khối lượng công việc chuyên môn rất lớn

so với nguồn nhân lực và kinh phí có hạn Tuy nhiên, với tư cách là đơn vị sự nghiệp, Trung tâm Tin học mới thực hiện được chức năng và nhiệm vụ phục vụ các đơn vị thuộc Bộ là chính, chưa mở rộng phục vụ cho toàn ngành Kế hoạch và Đầu tư; chưa thực hiện được chức năng và các nhiệm vụ về tham mưu, giúp Bộ trưởng quản lý thống nhất các hoạt động ứng dụng công nghệ thông tin trong phạm vi của Bộ cũng như toàn ngành Kế hoạch và Đầu tư

Về cơ cấu tổ chức, Trung tâm Tin học thuộc Bộ Kế hoạch và Đầu tư có 01 Văn phòng và 04 Phòng chuyên môn, gồm: Phòng Quản lý chất lượng thông tin và dữ liệu; Phòng Quản lý và vận hành mạng; Phòng Công nghệ phần mềm; Phòng Nội dung thông tin

Về tình hình ứng dụng công nghệ thông tin tại Trung tâm Tin hoc – Bộ Kế hoạch và Đầu tư: Thực hiện Nghị định số 64/2007/NĐ-CP, Trung tâm Tin học chủ trì

và phối hợp với các đơn vị trong Bộ xây dựng Kế hoạch tổng thể ứng dụng công nghệ thông tin trong hoạt động của Bộ Kế hoạch và Đầu tư giai đoạn 2011-2015 và định

hướng đến năm 2020 và được Lãnh đạo Bộ phê duyệt tại Quyết định số BKH ngày 01/12/2010

2094/QĐ-Trung tâm Tin học là đơn vị đầu mối chuyên trách về công nghệ thông tin của

Bộ Kế hoạch và Đầu tư Đây cũng là đơn vị tiên phong trong việc ứng dụng công nghệ thông tin trong các hoạt động chuyên môn Hiện nay Trung tâm Tin học trao đổi công việc hầu hết qua môi trường mạng (thông qua Hệ thống Quản lý văn bản và hồ sơ công việc tại website https://portal.mpi.gov.vn, Hệ thống mail tại website https://mail.mpi.gov.vn) Song song với việc trao đổi văn bản điện tử qua môi trường mạng, Trung tâm Tin học đã triển khai áp dụng chữ ký số nhằm đảm bảo an toàn trong trao đổi thông tin Bên cạnh đó, Trung tâm Tin học đã xây dựng và đưa vào sử dụng phần mềm Quản lý cán bộ, phần mềm Quản lý thi đua – khen thưởng Ngoài ra, Trung tâm Tin học còn sử dụng phần mềm Quản lý tài sản, phần mềm Kế toán,…

Trung tâm Tin học cũng triển khai các giải pháp đảm bảo an toàn, an ninh thông tin cho toàn Bộ Kế hoạch và Đầu tư nói chung và Trung tâm Tin học nói riêng:

+ Hệ thống tường lửa;

+ Hệ thống mail sercurity;

+ Hệ thống antivirus tập trung;

+ Hệ thống vá lỗi tập trung (WSUS);

+ Hệ thống ghi nhật ký tập trung (Logcentre);

+ Hệ thống phát hiện xâm nhập;

+ Hệ thống sao lưu và phục hồi dữ liệu tập trung;

+ Triển khai Port Sercurity;

+ Hệ thống PKI chuyên dùng của Bộ Kế hoạch và Đầu tư;

+ Hệ thống danh bạ điện tử dùng chung cho toàn bộ các ứng dụng;

+ Hệ thống quản lý wi-fi tập trung

Việc ứng dụng công nghệ thông tin trong hoạt động của Trung tâm Tin học nói riêng và Bộ Kế hoạch và Đầu tư nói chung đã góp phần nâng cao hiệu quả hoạt động chuyên môn nghiệp vụ của các đơn vị thuộc Bộ cũng như của Trung tâm Tin học

1.3 Sự cần thiết phải xây dựng Hệ thống Quản lý thiết bị và sự cố tin học

Theo quy định tại Điều 45 và Điều 46 của Nghị định số 64/2007/NĐ-CP, Trung tâm Tin học là đơn vị đầu mối chuyên trách về công nghệ thông tin của Bộ Kế hoạch

và Đầu tư Riêng công tác quản lý hoạt động ứng dụng công nghệ thông tin của Tổng cục Thống kê do Vụ Phương pháp chế độ thống kê và công nghệ thông tin thuộc Tổng cục thực hiện Trụ sở chính của Bộ Kế hoạch và Đầu tư đặt tại địa chỉ 6B Hoàng Diệu,

Ba Đình, Hà Nội, ngoài ra trên địa bàn Hà Nội Bộ Kế hoạch và Đầu tư còn 02 trụ sở đặt tại 68 Phan Đình Phùng và 65 Văn Miếu

Các hệ thống thiết bị thuộc hệ thống mạng của Bộ bao gồm các hệ thống: Hệ thống thiết bị thuộc Trung tâm dữ liệu, 69 thiết bị chuyển mạch ngoài trung tâm dữ liệu, 21 thiết bị wifi và khoảng 1500 thiết bị đầu cuối, bao gồm máy tính, máy in, máy scan

Hiện tại Trung tâm Tin học – Bộ Kế hoạch và Đầu tư có 30 cán bộ trong đó chỉ

có 07 cán bộ trực tiếp quản lý thiết bị và hỗ trợ xử lý sự cố tin học trong toàn Bộ Với lượng nhân lực này thì việc quản lý thiết bị và sự cố tin học thực sự rất khó khăn Hơn nữa các thiết bị tin học có được do nhiều nguồn khác nhau, có thể được đầu tư từ ngân sách, cũng có thể được đầu tư từ các dự án Để biết được thiết bị này được đầu tư từ nguồn nào, đã được thay thế linh kiện nào, đã xảy ra bao nhiêu sự cố và thiết bị này do

ai quản lý là rất khó nếu như chỉ lưu trên giấy tờ

Sự cố tin học: là sự cố xảy ra được ghi nhận trên máy tính của cán bộ, hệ thống

cơ sở hạ tầng công nghệ thông tin tại Bộ Kế hoạch và Đầu tư liên quan đến các chi tiết trong máy tính, mạng máy tính, các phần mềm ứng dụng, hệ thống thư điện tử, dịch vụ online, các thiết bị chuyển mạch, thiết bị wifi trong và ngoài trung tâm dữ liệu

Hàng năm Trung tâm Tin học khắc phục trên 1000 sự cố thường xuyên, gần

100 sự cố máy tính phát sinh và sự cố máy tính cần thay thế thiết bị cho các máy tính của các cán bộ công chức, viên chức thuộc Bộ (trong khu vực Hà Nội) Cụ thể, năm

2012 tính đến ngày 05/12 Trung tâm đã khắc phục tổng cộng 1620 sự cố thường xuyên; 52 sự cố máy tính phát sinh và 37 sự cố máy tính cần thay thế thiết bị cho các máy tính của các cán bộ công chức, viên chức thuộc Bộ (trong khu vực Hà Nội)

Với lượng nhân lực hiện tại, để quản lý tốt các thiết bị và sự cố tin học cần thiết phải xây dựng hệ thống quản lý thiết bị và sự cố tin học Hệ thống sẽ giúp các cán bộ

kỹ thuật dễ dàng trả lời được các câu hỏi: thiết bị này được đầu tư từ nguồn nào? do ai quản lý? đặt tại vị trí nào? đã thay thế những linh kiện gì? đã xảy ra những sự cố nào?

CHƯƠNG 2

CƠ SỞ LÝ LUẬN XÂY DỰNG HỆ THỐNG QUẢN LÝ THIẾT BỊ

VÀ SỰ CỐ TIN HỌC THEO HƯỚNG ĐỐI TƯỢNG 2.1 Tổng quan về cách tiếp cận hướng đối tượng

Vào đầu những năm 90 của thế kỷ 20, người ta đã nghiên cứu một mô hình mới thích hợp với việc phát triển phần mềm lớn và phức tạp Đó là mô hình hướng đối tượng Theo cách tiếp cận hướng đối tượng, hệ thống được nhìn nhận như một bộ các đối tượng Trong đó, đối tượng là sự kết hợp giữa chức năng và dữ liệu – đó là một sự kết hợp có lý vì mỗi chức năng chỉ thao tác trên một số dữ liệu nhất định và ngược lại, mỗi dữ liệu cũng chỉ được xử lý bởi một số chức năng nào đó Điều này không những hợp lý mà còn rất tự nhiên và dễ hiểu: các đối tượng tin học thường dùng để phản ánh hay mô phỏng các đối tượng trong thế giới thực Phương pháp hướng đối tượng sẽ dẫn đến việc cài đặt các hệ thống bằng ngôn ngữ lập trình hướng đối tượng

Cách tiếp cận hướng đối tượng dựa trên ý tưởng che dấu thông tin Thiết kế hướng đối tượng gần đây được phát triển nhiều đã tạo ra các hệ thống cấu tạo bởi nhiều thành phần độc lập và có tương tác với nhau Che dấu thông tin là chiến lược thiết kế dấu càng nhiều thông tin trong các thành phần càng hay Liên lạc thông qua các thông tin trạng thái dùng chung (các biến tổng thể) là ít nhất, nhờ vậy khả năng hiểu được nâng lên Thiết kế là tương đối dễ thay đổi vì sự thay đổi một thành phần không thể không dự kiến các hiệu ứng phụ trên các thành phần khác

Thực tế, các hệ phần mềm lớn đều phức tạp đến mức mà người ta đã dùng các phương pháp tiếp cận khác nhau trong việc thiết kế các thành phần khác nhau của một

hệ thống Chẳng có một chiến lược tốt nhất nào cho các dự án lớn Các cách tiếp cận hướng chức năng và hướng đối tượng là bổ sung hỗ trợ cho nhau chứ không đối kháng nhau Kỹ sư phần mềm sẽ chọn cách tiếp cận thích hợp nhất cho từng giai đoạn thiết

kế Nhìn ở mức tổng thể thì hệ thống như một bộ các đối tượng (chứ không phải là bộ các chức năng), cho nên ở mức trừu tượng thì cách tiếp cận hướng đối tượng là thích hợp hơn Đến mức chi tiết thì tự nhiên hơn là nên xem chúng là các chức năng tương tác giữa các đối tượng Sau đó mỗi đối tượng lại được phân giải thành các thành phần, tức là lại có thể xem nó như là một hệ (con)

Rất nhiều hệ thống, đặc biệt là hệ thống thời gian thực được nhúng (vào một hệ thiết bị vật chất có thực), được cấu tạo như là một hệ gồm một bộ các quá trình hoạt động song song và có liên lạc với nhau Các hệ này thường phải tuân theo các ràng buộc nghiêm ngặt về thời gian, mà các phần cứng thường hoạt động tương đối chậm, chỉ có cách tiếp cận nhiều bộ xử lý hoạt động song song mới có thể hoàn thành được yêu cầu về thời gian [3], [4]

Một vấn đề cơ bản đặt ra cho phương pháp hướng đối tượng là từ một bài toán ban đầu, làm sao để thu được một tập các đối tượng, với các chức năng được phối hợp với nhau, đáp ứng được yêu cầu của bài toán đặt ra?

Phương pháp phân tích thiết kế hướng đối tượng ra đời nhằm trả lời cho câu hỏi này Mục đích là xây dựng một tập các lớp đối tượng tương ứng với mỗi bài toán, phương pháp này tiến hành theo hai pha chính:

Pha phân tích: Chuyển đổi yêu cầu bài toán từ ngôn ngữ tự nhiên sang ngôn

ngữ mô hình

Pha thiết kế: Chuyển đổi đặc tả bài toán dưới dạng ngôn ngữ mô hình sang

một mô hình cụ thể có thể cài đặt được

* Cách tiếp cận hướng đối tượng có những đặc trưng sau:

1 Đặt trọng tâm vào dữ liệu (thực thể) Khi khảo sát, phân tích một hệ thống chúng ta không tập trung vào các nhiệm vụ như trước đây mà tìm hiểu xem nó gồm những thực thể nào Thực thể hay còn gọi là đối tượng, là những gì như người, vật, sự kiện mà chúng ta đang quan tâm, hay cần phải xử lý

2 Xem hệ thống như là tập các thực thể, các đối tượng Để hiểu rõ về hệ thống, chúng ta phân tách hệ thống thành các đơn thể đơn giản hơn Quá trình này được lặp lại cho đến khi thu được những đơn thể tương đối đơn giản, dễ hiểu và thực hiện cài đặt chúng mà không làm tăng thêm độ phức tạp khi liên kết chúng trong hệ thống Xét “Hệ thống quản lý thiết bị”, chúng ta có các lớp đối tượng sau:

Hình 2.1: Tập các lớp đối tượng của hệ thống

3 Các lớp đối tượng trao đổi với nhau bằng các thông điệp Theo nghĩa thông thường thì lớp là nhóm một số người, vật có những đặc tính tương tự nhau hoặc có những hành vi ứng xử giống nhau Trong mô hình đối tượng, khái niệm lớp là cấu trúc

mô tả hợp nhất các thuộc tính, hay dữ liệu thành phần thể hiện các đặc tính của mỗi đối tượng và các phương thức, hay hàm thành phần thao tác trên các dữ liệu riêng và là giao diện trao đổi với các đối tượng khác để xác định hành vi của chúng trong hệ thống Khi có yêu cầu dữ liệu để thực hiện một nhiệm vụ nào đó, một đối tượng sẽ gửi một thông điệp (gọi một phương thức) cho đối tượng khác Đối tượng nhận được thông điệp yêu cầu sẽ phải thực hiện một số công việc trên các dữ liệu mà nó sẵn có hoặc lại tiếp tục yêu cầu những đối tượng khác hỗ trợ để có những thông tin trả lời cho đối tượng yêu cầu Với phương thức xử lý như thế thì một chương trình hướng đối tượng thực sự có thể không cần sử dụng biến toàn cục nữa

4 Tính mở và thích nghi của hệ thống cao hơn vì: Hệ thống được xây dựng dựa vào các lớp đối tượng nên khi có yêu cầu thay đổi thì chỉ thay đổi những lớp đối tượng có liên quan hoặc bổ sung thêm một số lớp đối tượng mới (có thể kế thừa từ những lớp có trước) để thực thi những nhiệm vụ mới mà hệ thống cần thực hiện

Nhà_Cung_Cấp

Hãng_Sản_Xuất

5 Hỗ trợ sử dụng lại và cơ chế kế thừa: Các lớp đối tượng được tổ chức theo

nguyên lý bao gói và che giấu thông tin, điều này làm tăng thêm hiệu quả của kế thừa

và độ tin cậy của hệ thống

* Ưu điểm của cách tiếp cận hướng đối tượng

- Đối tượng là cơ sở để kết hợp các đơn thể có thể sử dụng lại thành hệ thống lớn hơn, tạo ra những sản phẩm có chất lượng cao Đây cũng là cơ sở để thực hiện theo công nghệ thành phần

- Qui ước truyền thông điệp giữa các đối tượng đảm bảo cho việc mô tả các giao diện giữa các đối tượng thành phần bên trong hệ thống và những hệ thống bên ngoài trở nên dễ dàng hơn Điều đó giúp cho việc phân chia những dự án lớn, phức tạp

để phân tích, thiết kế theo cách chia nhỏ bài toán thành các lớp đối tượng hoàn toàn tương ứng với quan điểm hướng tới lời giải phù hợp với thế giới thực một cách tự nhiên

- Nguyên lý bao gói, che giấu thông tin hỗ trợ cho việc xây dựng những hệ thống thông tin an toàn và tin cậy

- Không những có thể giảm thiểu được thời gian thực hiện mà còn làm cho hệ thống có tính mở, tin cậy hơn do nguyên lý kế thừa dựa chính vào dữ liệu rất phù hợp với ngữ nghĩa của mô hình trong cài đặt

- Nguyên lý kế thừa cho phép dễ dàng xác định những bộ phận cơ bản, xây dựng các lớp như là các đơn vị cơ sở của hệ thống và sử dụng ngay khi chúng mà không cần phải hoàn thiện, không đòi hỏi phải thực hiện đầy đủ tất cả các chức năng (đơn thể mở) và sau đó có thể mở rộng dần và không làm ảnh hưởng tới các đơn thể khác, không đòi hỏi phải thiết kế lại

- Định hướng đối tượng cung cấp những công cụ, môi trường mới, hiệu quả để phát triển phần mềm theo hướng công nghiệp và hỗ trợ để tận dụng được những khả năng kế thừa, sử dụng lại ở phạm vi diện rộng để xây dựng được những hệ thống phức tạp, nhạy cảm

- Xoá bỏ được hố ngăn cách giữa các pha phân tích, thiết kế, cài đặt và kiểm định trong quá trình xây dựng phần mềm Nhiều kết quả (sản phẩm) của các giai đoạn trước có thể sử dụng ngay ở những giai đoạn sau

* Hạn chế của cách tiếp cận hướng đối tượng

- Sự tường minh các đối tượng hệ thống thích hợp là khó khăn Cách nhìn tự nhiên nhiều hệ thống là cách nhìn chức năng và việc thích nghi với cách nhìn hướng đối tượng đôi khi là khó khăn, nhất là đối tượng trừu tượng, không phải đối tượng cụ thể

- Phương pháp thiết kế hướng đối tượng vẫn còn tương đối chưa chín muồi, vẫn còn đang thay đổi nhanh chóng Phương pháp hiện đang được sử dụng rộng rãi nhất vẫn là phương pháp dựa trên sự phân rã chức năng (hướng cấu trúc)

2.2 Ngôn ngữ mô hình hóa thống nhất (UML)

2.2.1 Giới thiệu tổng quát về UML

Tiến trình phát triển phần mềm thống nhất (Unified Software Development Proccess: USDP) và ngôn ngữ mô hình hóa thống nhất (Unified Modeling Language: UML) là phương pháp luận và công cụ điển hình cho công nghệ phát triển phần mềm hướng đối tượng

UML là ngôn ngữ mô hình hóa chuẩn, ngôn ngữ mô hình đồ họa, trực quan, vừa đặc tả vừa có cấu trúc, đồng thời lại là ngôn ngữ làm tài liệu Vì vậy đối với việc phát triển phần mềm hướng đối tượng, UML đặc biệt có khả năng sau:

- Cho phép mô tả toàn bộ các sản phẩm phân tích và thiết kế

- Trợ giúp việc tự động hóa quá trình thiết kế trên máy tính

- Trợ giúp việc dịch xuôi và dịch ngược các thiết kế sang mã nguồn của ngôn ngữ lập trình và cơ sở dữ liệu

UML là một ngôn ngữ mô hình hoá thống nhất có phần chính bao gồm những

ký hiệu hình học, được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu

tả các thiết kế của một hệ thống Nó là một ngôn ngữ để đặc tả, trực quan hoá, xây dựng và làm sưu liệu cho nhiều khía cạnh khác nhau của một hệ thống có nồng độ phần mềm cao UML có thể được sử dụng làm công cụ giao tiếp giữa người dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm UML được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tới thực hiện và bảo trì Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối tượng để mô tả hệ thống nên miền ứng dụng của UML bao gồm nhiều loại hệ thống khác nhau

Hình 2.2 Sự phát triển của UML

Quá trình hình thành UML bắt đầu từ ngôn ngữ Ada (Booch) trước năm 1990 UML được hợp nhất từ nhiều thành tựu, kinh nghiệm nghiên cứu và triển khai nhờ:

- Cách tiếp cận của Grady Booch (Booch Approach),

- Kỹ thuật mô hình đối tượng (OMT: Object Modeling Technique) của James Rumbaugh

- Kỹ nghệ phần mềm hướng đối tượng (OOSE: Object-Oriented Software Engineering) của Ivar Jacobson

- Thống nhất được nhiều ký pháp, khái niệm của nhiều phương pháp khác nhau Trong UML, kiến trúc của hệ thống phần mềm chuyên sâu (cho ta một cách nhìn khái quát nhất về hệ thống phần mềm ở các góc độ khác nhau) được mô tả theo 5 loại khung nhìn (views) khác nhau Mỗi khung nhìn phản ánh về một khía cạnh của tổ chức và cấu trúc của hệ thống, tập trung vào từng mặt cụ thể giúp cho ta hiểu và sử dụng hệ thống tốt nhất Mỗi khung nhìn thường được thể hiện trong một số sơ đồ nhất định [16] – [19]

Hình 2.3 Mô hình hóa kiến trúc hệ thống

- Khung nhìn ca sử dụng (Use case view) chứa các tác nhân, ca sử dụng, sơ

đồ ca sử dụng (khía cạnh tĩnh của khung nhìn) trong hệ thống Chúng cũng có thể bao gồm vài sơ đồ trình tự, sơ đồ cộng tác (khía cạnh động của khung nhìn) và gói Khung nhìn ca sử dụng tập trung vào mức cao của cái hệ thống sẽ làm, không quan tâm đến

hệ thống làm như thế nào

- Khung nhìn thiết kế (design view) tập trung vào hệ thống cài đặt hành vi trong ca sử dụng như thế nào Nó bao gồm các lớp, sơ đồ lớp, sơ đồ đối tượng (khía cạnh tĩnh của khung hình), sơ đồ tương tác, sơ đồ hoạt động, sơ đồ biển đổi trạng thái (khía cạnh động của khung hình) và các gói Trong khung nhìn, người ta quan tâm đến hai lớp quan trọng là lớp phân tích (lớp biên, lớp điều khiển, lớp dữ liệu) và lớp thiết

kế (lớp phụ thuộc vào ngôn ngữ) Khung nhìn này tập trung vào cấu trúc logic của hệ thống nên còn được gọi là khung nhìn logic (logical view) Khung nhìn này tập trung vào cấu trúc của hệ thống Nhờ nó, người ta nhận ra các bộ phận cơ bản cấu thành hệ thống thể hiện mọi quá trình trao đổi, xử lý thông tin cơ bản trong hệ thống

- Khung nhìn tiến trình/tương tranh (process view) biểu diễn sự phân chia các luồng thực hiện công việc, các lớp đối tượng cho các tiến trình và sự đồng bộ giữa các luồng (thread) trong hệ thống Khung nhìn này tập trung vào các nhiệm vụ tương

Khung nhìn cài đặt /thành phần

Khung nhìn triển khai/bố trí

tranh, tương tác với nhau trong hệ thống đa nhiệm Nó chủ yếu diễn đạt hiệu năng, quy

mô và năng lực thông qua của hệ thống

- Khung nhìn thành phần/cài đặt (component/implementation view) bao gồm các thành phần (là mô-đun vật lý hay các file) để lắp ráp thành hệ thống vật lý Khung nhìn này hướng đến việc quản lý cấu hình của hệ thống Khung nhìn này bao gồm thành phần, sơ đồ thành phần và gói

- Khung nhìn bố trí/triển khai (Deployment view) bao gồm các nút tạo nên kết cấu phần cứng mà trên đó hệ thống vận hành Khung nhìn này chủ yếu hướng đến sự phân tán và cài đặt cụ thể của hệ thống, tức là liên quan đến triển khai vật lý của hệ thống Khung nhìn triển khai chỉ ra các tiến trình và thiết bị trên mạng và các kết nối vật lý giữa chúng Sơ đồ triển khai cũng hiển thị tiến trình và chỉ ra tiến trình nào chạy trên máy nào Khung nhìn này được thể hiện trong các sơ đồ triển khai/bố trí các nút của hệ thống.[6]

2.2.2 Các khối xây dựng (building blocks) cơ bản của UML

Các sự vật (things) là các trừu tượng hóa và là những phần tử lớp đầu tiên (những viên gạch) để xây dựng lên các mô hình trong UML Các quan hệ (relationships) gắn kết các sự vật với nhau, các sơ đồ (diagrams) nhóm các sự vật được quan tâm lại tạo nên ngữ nghĩa của nó (cho một mô hình)

Hình 2.4 Các thành phần cơ sở của UML

CÁC KHỐI XÂY DỰNG

Cấu trúc Hành vi Nhóm gộp Chú thích Phụ thuộc

Kết hợp Tổng quát hoá (kế thừa) Hiện thực hóa

Ca sử dụng Lớp Đối tượng Tuần tự Cộng tác Trạng thái Hoạt động Thành phần Triển khai

Gói

Mô hình

Hệ thống con Khung làm việc

2.2.2.1 Các sự vật (things)

UML có bốn loại sự vật, đó là sự vật cấu trúc, hành vi, nhóm và chú thích

a Sự vật cấu trúc (structural things): là các danh từ trong mô hình UML, biểu

diễn cho các thành phần khái niệm hay vật lý của hệ thống UML có bảy sự vật cấu trúc:

+ Lớp (class) Lớp là tập các đối tượng cùng chia sẻ các thuộc tính, thao tác, quan hệ và ngữ nghĩa Một lớp có trách nhiệm thực hiện một hay nhiều giao diện Một lớp được biểu diễn bằng một hình chữ nhật bên trong có tên, các thuộc tính và các tác

vụ Một lớp có ba thành phần như sau: tên lớp, các thuộc tính, các phương thức (ứng xử) của lớp

Hình 2.5 Lớp

+ Giao diện (interface) Giao diện là tập các thao tác làm dịch vụ cho lớp hay thành phần (mô-đun vật lý hoặc mã chương trình) Giao diện mô tả hành vi quan sát được từ bên ngoài thành phần Giao diện chỉ khai báo các phương thức xử lý không định nghĩa nội dung thực hiện Nó thường không đứng một mình mà thường nó được gắn với lớp hay một thành phần thực hiện giao diện

Hình 2.6 Giao diện

+ Cộng tác (collaboration) Sự cộng tác xác định các hoạt động bên trong hệ thống và là một bộ các nguyên tắc và các phần tử khác nhau cùng làm việc để cung cấp một hành vi hợp tác lớn hơn tổng hành vi của tất cả các phần tử Nó được ký hiệu bằng hình elip với đường đứt nét và thường chỉ gồm có tên

Hình 2.7 Sự cộng tác

+ Ca sử dụng (use case) Ca sử dụng mô tả một tập các hành động mà hệ thống

sẽ thực hiện để phục vụ cho các tác nhân ngoài Tác nhân ngoài là những gì bên ngoài

Window Size Origin Open() Close() Move() Display()

Tên lớp Thuộc tính Tác vụ/ phương thức

Interface

Dãy các trách nhiệm

có tương tác, trao đổi với hệ thống Nó được ký hiệu bằng hình elip nét liền, thường chỉ bao gồm có tên

Hình 2.8 Ca sử dụng

+ Lớp tích cực/hoạt động (active class) Lớp tích cực được xem như là lớp có đối tượng làm chủ một hay nhiều tiến trình, luồng hành động Bởi vậy nó có thể khởi động hoạt động điều khiển Nó được ký hiệu như một lớp nhưng có đường viền đậm

Hình 2.9 Lớp

+ Thành phần (component) Thành phần biểu diễn vật lý mã nguồn, các tệp nhị phân trong quá trình phát triển hệ thống Một thành phần được ký hiệu bằng một hình chữ nhật với các bảng và thường bao gồm chỉ có tên của nó

Hình 2.10 Thành phần

+ Nút (node) Nút thể hiện thành phần vật lý, tồn tại khi chương trình chạy và biểu diễn cho các tài nguyên được sử dụng trong hệ thống, thường có ít nhất bộ nhớ và khả năng xử lý Nó được ký hiệu bằng một hình hộp thường bao gồm tên của nó

Hình 2.11 Nút

b Sự vật hành vi (behavioral things): biểu diễn hành vi trong tương tác của

các thành phần và sự biến đổi trạng thái của hệ thống Như vậy nó mô tả hành vi của hành vi của hệ thống theo thời gian và không gian Có hai loại chính là sự tương tác và máy biển đổi trạng thái

+ Sự tương tác (interaction) Sự tương tác là hành vi bao gồm một tập các thông điệp trao đổi giữa các đối tượng trong một ngữ cảnh cụ thể để thực hiện một ca sử

Sửa danh mục thiết bị

Orderform.java

Máy dịch vụ

Window

Size Origin Open() Close() Move()

dụng Một thông điệp được ký hiệu bằng một đường thẳng có hướng gồm tên tác vụ

Hình 2.12 Thông điệp/thông báo

+ Máy biến đổi trạng thái (state machine) Máy biến đổi trạng thái (otomat hữu hạn trạng thái) chỉ ra trật tự thay đổi trạng thái khi các đối tượng hay sự tương tác sẽ phải đi qua để đáp ứng các sự kiện xảy ra Nó gồm một số phần tử biểu diễn trạng thái, các dịch chuyển (từ trạng thái này sang trạng thái khác) và các sự kiện (kích hoạt dịch chuyển) Một trạng thái được ký hiệu bằng hình chữ nhật tròn góc trong đó có tên trạng thái

Hình 2.13 Trạng thái

c Các sự vật nhóm gộp (grouping things): là bộ phận tổ chức của mô hình

UML Nó là công cụ để tổ chức các thành phần của một mô hình các nhóm Mô hình

có thể được phân chia vào trong các gói Một gói đơn thuần là một khái niệm Trong

ký hiệu một gói thường có tên, đôi khi có nội dung của nó Các sự vật nhóm có gói (package), mô hình và khung công việc

+ Gói (package) Gói là phần tử đa năng được sử dụng để tổ chức các lớp, hay một số nhóm khác trong một nhóm Không giống với thành phần (component), phần

tử gói hoàn toàn là khái niệm, có nghĩa chúng chỉ tồn tại trong mô hình vào thời điểm phát triển hệ thống chứ không tồn tại vào thời điểm chạy chương trình Gói giúp ta quan sát hệ thống ở mức tổng quát

d Chú thích: là bộ phận chú giải của mô hình, giải thích về các phần tử, khái

niệm và cách sử dụng chúng trong mô hình

Hình 2.15 Chú thích

Các quy tắc nghiệp vụ

Hướng thông điệp Trả lại bản sao Hiển thị

2.2.2.2 Các mối quan hệ (relationships)

UML cho phép biểu diễn cả bốn mối quan hệ giữa các đối tượng trong các hệ thống Đó là các quan hệ: phụ thuộc, kết hợp, tổng quát hóa và hiện thực hóa

+ Quan hệ phụ thuộc (dependency) Đây là quan hệ ngữ nghĩa giữa hai sự vật, trong đó có sự thay đổi một sự vật sẽ tác động đến ngữ nghĩa của sự vật phụ thuộc

Hình 2.16 Quan hệ phụ thuộc

+ Quan hệ kết hợp (association) Kết hợp là quan hệ cấu trúc xác định mối liên kết giữa các lớp đối tượng Khi có một đối tượng của lớp này gửi/nhận thông điệp đến/từ chỗ đối tượng của lớp kia thì hai lớp đó có quan hệ kết hợp Một dạng đặc biệt của quan hệ kết hợp là quan hệ tụ hợp (aggregation), biểu diễn mối quan hệ giữa toàn thể và bộ phận Trong ký hiệu thường có nhãn và thường có chứa các bài trí khác nhau giải thích vai trò của đối tượng tham gia vào liên kết và các bản số của chúng

Hình 2.17 Kết hợp

+ Quan hệ tổng quát hóa (generalization): Đây là quan hệ mô tả sự khái quát hóa mà trong đó một số đối tượng cụ thể (con) sẽ được thừa kế các thuộc tính, các phương thức của các đối tượng tổng quát (cha) Nó được ký hiệu bằng đường nét liền với mũi tên rỗng chỉ về phía cha

Hình 2.18 Tổng quát hóa

+ Thực hiện hóa (realization) Thực hiện hóa là quan hệ ngữ nghĩa giữa giao diện và lớp (hay thành phần) để thực hiện cài đặt các dịch vụ đã được khai báo trong các giao diện Mối quan hệ này dựa vào 2 vị trí: giữa các giao diện và các lớp hoặc các thành phần thực hiện nó Một mối quan hệ thực hiện được xem như một mối quan hệ nằm giữa mối quan hệ tổng quát hóa và mối quan hệ phụ thuộc, vì thế nó được ký hiệu bằng đường nét đứt có mũi tên rỗng

Hình 2.19 Thực hiện hóa

2.2.2.3 Các sơ đồ

Sơ đồ (diagram) là đồ thị biểu diễn đồ họa về tập các phần tử (các từ vựng) trong mô hình và mối quan hệ của chúng (một số tác giả ghi là biểu đồ) Sơ đồ thường được thể hiện như một đồ thị liên thông với các đỉnh (là các sự vật) và các cung (là các mối quan hệ) Sơ đồ chứa đựng các nội dung của các khung nhìn dưới các góc độ khác

Chủ sở hữu

Ô tô

nhau và một thành phần của hệ thống có thể xuất hiện trong một hay nhiều sơ đồ UML cung cấp những sơ đồ trực quan để biểu diễn các khía cạnh khác nhau của hệ thống, bao gồm:

- Sơ đồ ca sử dụng (use case diagram) mô tả sự tương tác giữa các tác nhân ngoài và hệ thống thông qua các ca sử dụng Các ca sử dụng là những nhiệm vụ chính, các dịch vụ, những trường hợp sử dụng cụ thể mà hệ thống cung cấp cho người sử dụng và ngược lại

- Sơ đồ lớp (class diagram) mô tả cấu trúc tĩnh, mô tả mô hình khái niệm bao gồm các lớp đối tượng và các mối quan hệ của chúng trong hệ thống hướng đối tượng Người ta sử dụng sơ đồ lớp để mô hình hóa khung nhìn thiết kế tĩnh của hệ thống và thường sử dụng sơ đồ này để mô hình hóa bảng từ vựng của hệ thống, mô hình hóa các cộng tác đơn giản, mô hình hóa cơ sở dữ liệu logic Người ta còn sử dụng sơ đồ đối tượng để mô hình hóa khung nhìn thiết kế tĩnh của hệ thống cũng như mô hình hóa cấu trúc của đối tượng Sơ đồ đối tượng mô hình hóa các thể hiện của các sự vật trong một

sơ đồ lớp Nó đưa ra một tập các đối tượng và các mối quan hệ giữa chúng tại một thời điểm

- Sơ đồ trình tự (sequence diagram) là một loại sơ đồ tương tác (interaction diagram) thể hiện sự tương tác của các đối tượng với nhau, chủ yếu là trình tự gửi và nhận thông điệp để thực thi các yêu cầu, các công việc theo thời gian

- Sơ đồ cộng tác (collaboration diagram) cũng là một loại sơ đồ tương tác, tương tự như sơ đồ trình tự nhưng nhấn mạnh vào sự tương tác của các đối tượng trên

cơ sở cộng tác với nhau bằng cách trao đổi các thông điệp để thực hiện các yêu cầu theo ngữ cảnh công việc

- Sơ đồ trạng thái (statechart diagram) cũng là một loại sơ đồ tương tác, biểu diễn một máy trạng thái Nó biểu diễn dòng điều khiển từ trạng thái này tới trạng thái khác Nó nhấn mạnh dòng điều khiển từ hoạt động này đến hoạt động khác đang xảy

ra bên trong một máy trạng thái

- Sơ đồ hành động (activity diagram) cũng là một loại sơ đồ tương tác, chỉ ra dòng hoạt động của hệ thống, bao gồm các trạng thái hoạt động, trong đó từ một trạng thái hoạt động sẽ chuyển sang trạng thái khác sau khi một hoạt động tương ứng được thực hiện Nó chỉ ra trình tự các bước, tiến trình thực hiện cũng như các điểm quyết định và sự rẽ nhánh theo luồng sự kiện

- Sơ đồ triển khai (deployment diagram) chỉ ra cách bố trí vật lý các thành phần theo kiến trúc được thiết kế của hệ thống [7]

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

Cách tiếp cận hướng đối tượng để phát triển phần mềm dựa trên mô hình dữ liệu trừu tượng và khái niệm lớp nhằm chỉ ra những đặc tính chung các cấu trúc dữ liệu được sử dụng trong quá trình mô hình hóa hệ thống Để làm tốt được điều đó, trước hết chúng ta cần tìm hiểu sâu hơn một số khái niệm cơ bản: Các đối tượng, Lớp

các đối tượng; Các giá trị và thuộc tính của đối tượng; Các thao tác và phương thức; Các gói

2.2.3.1 Các đối tượng

Đối tượng là khái niệm cơ sở quan trọng nhất của cách tiếp cận hướng đối tượng Đối tượng là một sự trừu tượng hóa hay một sự vật có nghĩa trong bài toán đang khảo sát Đối tượng là thực thể của hệ thống, của cơ sở dữ liệu và được xác định thông qua định danh của chúng Thông thường các đối tượng được mô tả bởi các danh

từ riêng (tên gọi) hoặc được tham chiếu tới trong các mô tả của bài toán hay trong các thảo luận với người sử dụng Có những đối tượng là những thực thể có trong thế giới thực như người, sự vật cụ thể, hoặc là những khái niệm như một công thức, hay khái niệm trừu tượng Có một số đối tượng được bổ sung vào hệ thống với lý do phục vụ cho việc cài đặt và có thể không có trong thực tế

2.2.3.2 Lớp các đối tượng

Đối tượng là thể hiện, là một đại biểu của một lớp Lớp là một mô tả về một nhóm các đối tượng có những tính chất (thuộc tính) giống nhau, có chung các hành vi ứng xử (thao tác gần như nhau), có cùng mối liên quan với các đối tượng của các lớp khác và có chung ngữ nghĩa trong hệ thống Lớp chính là cơ chế được sử dụng để phân loại các đối tượng của một hệ thống Lớp thường xuất hiện dưới dạng những danh từ chung trong các tài liệu mô tả bài toán hay trong các thảo luận với người sử dụng Cũng như các đối tượng, lớp có thể là những nhóm thực thể có trong thế giới thực, cũng có những lớp là khái niệm trừu tượng và có những lớp được đưa vào trong thiết

kế để phục vụ cho cài đặt hệ thống

Lớp và mối quan hệ của chúng có thể mô tả trong các sơ đồ lớp, sơ đồ đối tượng và một số sơ đồ khác của UML Trong sơ đồ lớp, lớp được mô tả bằng một hình hộp chữ nhật, trong đó có tên của lớp, có thể có các thuộc tính và các hàm (phương thức)

Người ta thường đặt tên theo một quy tắc thống nhất như sau:

+ Tên của lớp thì chữ cái đầu của tất cả các từ đều viết hoa, ví dụ: LinhKien + Tên của đối tượng, tên của thuộc tính thì viết hoa chữ cài đầu của các từ trừ

từ đầu tiên, ví dụ: danhSachThietBi,…

+ Tên của hàm (phương thức) viết giống như tên của đối tượng nhưng có thêm cặp ngoặc đơn „(„ và „)‟, ví dụ hienThi(), nhapDanhMuc(),…

Trong sơ đồ ở giai đoạn phân tích, một lớp có thể chỉ cần có tên lớp, tên và thuộc tính, hoặc có cả tên gọi, thuộc tính và các phương thức

2.2.3.3 Các giá trị và thuộc tính của đối tượng

Giá trị (value) là một phần của dữ liệu Các giá trị thường là các số hoặc là các

ký tự Thuộc tính của đối tượng là thuộc tính của lớp được mô tả bởi giá trị của mỗi đối tượng trong lớp đó

Không nên nhầm lẫn giá trị với đối tượng Các đối tượng có định danh chứ không phải là các giá trị Giá trị có thể là các giá trị của các kiểu dữ liệu nguyên thủy như các kiểu số hoặc các kiểu xâu ký tự, hoặc là tập hợp của các giá trị nguyên thủy

Các dữ liệu thành phần của một lớp có thể được bao gói thông qua các thuộc tính quản lý sự truy nhập để phục vụ việc che dấu thông tin của phương pháp hướng đối tượng Trong UML ta có thể sử dụng các ký hiệu để đặc tả các thuộc tính đó

Ký hiệu:

„+‟ đứng trước tên thuộc tính, hàm xác định tính công khai (public), mọi đối tượng trong hệ thống đều nhìn thấy được Nghĩa là mọi đối tượng đều có thể truy nhập được vào dữ liệu công khai

„#‟ đứng trước tên thuộc tính, hàm xác định tính được bảo vệ (protected), chỉ những đối tượng có quan hệ kế thừa với nhau nhìn thấy được

„_‟ đứng trước tên thuộc tính, hàm xác định tính sở hữu riêng (private), chỉ các đối tượng trong cùng lớp mới nhìn thấy được

hệ thống thành các gói (hệ thống con) chính là cách phân hoạch mô hình thành các đơn

vị nhỏ hơn để trị, dễ hiểu và dễ quản lý hơn Gói được mô tả trong UML gồm tên của gói, có thể có các lớp, gói nhỏ khác bên trong

Khi phân chia các lớp thành các gói, chúng ta có thể dựa vào: các lớp chính (thống trị), các mối quan hệ chính, các chức năng chính Theo cách phân chia đó chúng ta có thể chia hệ thống thành các phân hệ phù hợp với cách phân chia trong hệ thống thực

2.2.4 Các quy tắc ngữ nghĩa của UML

Mô hình hóa của một hệ thống không đơn giản là lắp ghép các khối được xây dựng của UML một cách ngẫu nhiên Cũng như mọi ngôn ngữ, UML có một số quy tắc chỉ ra rằng, một mô hình được xây dựng tốt là mô hình có ngữ nghĩa chắc chắn và đồng bộ với tất cả mô hình có quan hệ với nó UML đưa ra các quy tắc ngữ nghĩa:

- Tên gọi: là cái mà ta gọi là các sự vật, các mối quan hệ và các sơ đồ

- Phạm vi: là khuôn khổ cho ý nghĩa cụ thể đối với một tên gọi

- Tính trực quan: các tên gọi có thể nhìn thấy và được các phần tử khác sử dụng

- Tính tích hợp: các sự vật có thể liên kết với các sự vật khác như thế nào

- Tính thực hiện được: nó có ý nghĩa gì để vận hành và mô phỏng mô hình động Những nguyên tắc khác cần biết để xây dựng tốt các mô hình:

- Sự lược đi: một số phần tử được dấu đi làm đơn giản sự nhìn nhận của mô hình

- Sự không đầy đủ: một số phần tử có thể tạm bỏ qua

- Sự không chắc chắn: sự tích hợp của mô hình là chưa đảm bảo

2.2.5 Các cơ chế chung trong UML

UML cung cấp 4 cơ chế chung để áp dụng trong khi mô hình hóa: Các đặc tả; Các bài trí; Sự phân hoạch chung; Các cơ chế mở rộng

2.2.5.3 Sự phân hoạch chung (Common divisions)

+ Phân hoạch lớp và đối tượng Một lớp là một trừu tượng, một đối tượng là một biểu hiện cụ thể của lớp đó UML thường phân biệt lớp và đối tượng của lớp đó bằng cách gạch chân tên của đối tượng

+ Phân hoạch giao diện và triển khai một giao diện, như khai báo một hợp đồng

và triển khai một hợp đồng Trong UML có thể mô hình hóa cả giao diện và triển khai

2.2.5.4 Các cơ chế mở rộng (Extensibility mechanisms)

UML cung cấp ngôn ngữ chuẩn để viết bản thiết kế phần mềm, nhưng nó vẫn chưa đủ để diễn đạt mọi sắc thái có thể của các mô hình trong mọi lĩnh vực và trong mọi thời điểm Các cơ chế dùng để mở rộng gồm có:

- Các khuôn mẫu (stereotypes)

- Các giá trị thẻ (tagged values)

- Các ràng buộc (constraints)

Sự mở rộng từ vựng của ngôn ngữ UML cho phép tạo ra các khối xây dựng mới

từ các khối có sẵn để cụ thể cho vấn đề của ta bằng cách thêm vào ký hiệu khuôn mẫu, giá trị thẻ hay ràng buộc

2.2.6 Các quy tắc ràng buộc và suy diễn

Trong mô hình hóa hệ thống với UML, ta có thể sử dụng ngôn ngữ ràng buộc đối tượng (OCL) để đặc tả chính xác các phần tử của hệ thống và các ràng buộc chặt

chẽ giữa các mối quan hệ, giới hạn phạm vi của mô hình hệ thống cho phù hợp với điều kiện ràng buộc thực tế

Trong UML có hai quy tắc chính:

- Quy tắc ràng buộc được sử dụng để giới hạn phạm vi của mô hình, ví dụ các qui tắc hạn chế, quy định rõ phạm trù của các mối quan hệ như kết hợp, kế thừa hay khả năng nạp chồng trong các lớp

- Quy tắc suy dẫn chỉ ra cách các sự vật có thể suy dẫn được, ví dụ tuổi của một người có thể suy ra được từ ngày/tháng/năm hiện thời trừ đi ngày/tháng/năm sinh

2.3 Quá trình phát triển phần mềm hướng đối tượng

Để xây dựng được những hệ thống phần mềm đáp ứng những yêu cầu chất lượng, chúng ta cần phải:

- Có một qui trình phát triển phần mềm thống nhất gồm các bước thực hiện rõ ràng, mà sau mỗi bước đều phải có các sản phẩm cụ thể;

- Có các phương pháp và kỹ nghệ phù hợp với từng pha thực hiện phát triển phần mềm;

- Có công cụ để làm ra sản phẩm phần mềm theo yêu cầu

Quá trình phát triển một sản phẩm là quá trình định nghĩa ai làm cái gì, làm khi nào và như thế nào 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

Quá trình phát triển phần mềm được xác định thông qua tập các hoạt động cần thực hiện để chuyển đổi các yêu cầu của khách hàng (người sử dụng) thành hệ thống phần mềm

Có năm bước chính cần thực hiện trong quá trình phát triển phần mềm:

2.3.1 Xác định các yêu cầu của hệ thống

Trong bước xác định các yêu cầu của hệ thống, ta chia thành 2 giai đoạn:

+ Xây dựng mô hình nghiệp vụ + Xác định yêu cầu

2.3.1.1 Xây dựng mô hình nghiệp vụ

Để nắm bắt được yêu cầu của một hệ thống tin học hóa, ta cần tìm hiểu hệ thống thực Công việc này được tiến hành bằng cách tìm hiểu hoạt động nghiệp vụ và

xây dựng các mô hình miền và mô hình nghiệp vụ để nắm bắt toàn bộ các vấn đề thuần nghiệp vụ của hệ thống

Việc tìm hiểu hoạt động nghiệp vụ được tiến hành qua các bước sau

mô hình nào cả

- Xây dựng mô hình miền: Mục đích của mô hình hóa miền là để hiểu và mô tả các lớp quan trọng nhất bối cảnh của miền Ta có thể lập một từ điển giải thích để định nghĩa về các lớp miền Từ điển thuật ngữ và mô hình miền giúp khách hàng và người phát triển chia sẻ những thuật ngữ khái niệm chung Đối với những miền nghiệp vụ rất nhỏ, không cần thiết phát triển một mô hình miền mà chỉ cần sử dụng từ điển thuật ngữ là đủ

Mô hình miền (domain model) mô tả các khái niệm quan trọng của hệ thống qua các đối tượng của miền nghiệp vụ và liên kết giữa chúng với nhau Các đối tượng miền là những vật hay khái niệm trong thực tế hoặc các sự kiện diễn ra trong môi trường mà hệ thống làm việc Mô hình miền có thể mô tả bằng nhiều biểu đồ lớp của UML Có 3 dạng lớp đối tượng miền điển hình

+ Các đối tượng nghiệp vụ thể hiện những vật được quản lý trong hoạt động nghiệp vụ như: đơn đặt hàng, tài khoản, hợp đồng…

+ Các đối tượng thế giới thực và các khái niệm mà một hệ thống cần theo dõi, ví dụ như giao dịch thanh toán, mua hàng, rút tiền…

+ Các sự kiện sẽ hoặc đã xuất hiện: đưa thẻ vào máy, nhấn phím, trả tiền…

- Xây dựng mô hình nghiệp vụ: Mô hình nghiệp vụ (Bussiness model) được thể hiện ra bằng một mô hình ca sử dụng nghiệp vụ Nó có thể bao gồm các chế tác (thành phần) sau:

+ Đối tượng miền;

+ Đối tượng nghiệp vụ;

+ Người tham gia nghiệp vụ và các trách nhiệm, thao tác tương ứng;

+ Mô hình ca sử dụng nghiệp vụ mô tả các quá trình nghiệp vụ của một tổ chức dưới dạng các ca sử dụng nghiệp vụ và các tác nhân nghiệp vụ tương ứng Nó xem xét một hệ thống nghiệp vụ từ quan điểm người sử dụng và chỉ ra làm thế nào để

hệ thống cung cấp một giá trị gia tăng cho tác nhân nghiệp vụ hệ thống đó Mô hình ca

sử dụng nghiệp vụ được miêu tả bằng sơ đồ ca sử dụng [3]

Mô hình miền là một trường hợp riêng của mô hình nghiệp vụ mà ở đó ta chỉ tập trung vào các vật, các lớp miền hoặc các thực thể nghiệp vụ mà người tham gia nghiệp vụ sẽ phải làm với chúng

Một mô hình nghiệp vụ được phát triển qua hai bước:

+ Xây dựng một mô hình ca sử dụng nghiệp vụ bao gồm việc xác định các tác nhân nghiệp vụ mà các tác nhân sử dụng Mô hình cho phép người phát triển hiểu

rõ hơn về giá trị mà nghiệp vụ đem lại cho tác nhân sử dụng nó

+ Phát triển một mô hình đối tượng nghiệp vụ bao chứa những người tham gia nghiệp vụ, các thực thể nghiệp vụ và các đơn vị công việc cùng nhau thực hiện các

ca sử dụng nghiệp vụ Các quy tắc nghiệp vụ và các điều chỉnh khác trong nghiệp vụ được liên kết với các đối tượng khác

b Nắm bắt các yêu cầu bổ sung

Các yêu cầu bổ sung là các yêu cầu phi chức năng mà không thể liên kết với các

ca sử dụng nghiệp vụ cụ thể nào Chúng có ảnh hưởng đến nhiều ca sử dụng hoặc chỉ đến một ca sử dụng nghiệp vụ nào đó Ví dụ như tính thể hiện, các giao diện, các yêu cầu thiết kế vật lý và kiến trúc, các ràng buộc về thiết kế và cài đặt

2.3.1.2 Xác định yêu cầu

Mục tiêu của việc xác định yêu cầu là phát triển một mô hình ca sử dụng của hệ thống cần xây dựng bằng cách dùng các ca sử dụng Các ca sử dụng cung cấp một cách có hệ thống và trực quan để nắm bắt các yêu cầu có tính chức năng mà tập trung đặc biệt vào giá trị gia tăng đem lại cho mỗi cá nhân người dùng hoặc mỗi hệ thống bên ngoài tương tác với hệ thống Kết quả của luồng công việc này là một phiên bản đầu tiên của mô hình ca sử dụng, các ca sử dụng và các bản mẫu giao diện – người sử dụng đã được tổng hợp lại Các kết quả của các lần lặp tiếp theo sẽ gồm các phiên bản mới của các thành phần này nhưng chúng sẽ được hoàn thiện, được cải tiến và làm mịn dần trong quá trình các bước lặp

Để mô tả yêu cầu nghiệp vụ của hệ thống dưới góc độ phát triển phần mềm cần:

a Tìm các tác nhân và các ca sử dụng

Việc xác định các ca sử dụng và các tác nhân gồm bốn bước dưới đây Các bước này không bắt buộc phải thực hiện theo thứ tự mà thường được thực hiện đồng thời Kết quả của hoạt động này là một phiên bản của mô hình ca sử dụng với các tác nhân và các ca sử dụng

Bước 1: Tìm các tác nhân

Tác nhân (actor) thể hiện cho những phần ngoài hệ thống mà tương tác với hệ thống Tác nhân có thể là các kiểu người dùng hoặc các kiểu hệ thống ngoài của hệ thống Một tác nhân đóng một vai trò nào đó đối với mỗi ca sử dụng mà nó tương tác Mỗi khi một người dùng (hoặc hệ thống ngoài cụ thể) tương tác với hệ thống, thể hiện của tác nhân tương ứng đóng một vai trò mà người dùng thực hiện

Có hai tiêu chuẩn để xác định các tác nhân:

- Phải có ít nhất một người dùng mà có thể thực hiện vai trò của tác nhân dự kiến

- Sự trùng lặp giữa các vai trò của những tác nhân khác nhau đóng vai trong mối quan hệ với hệ thống là tối thiểu nhất

Sau khi tìm được tác nhân cần mô tả ngắn gọn các vai trò của mỗi tác nhân tương tác với hệ thống và mục tiêu sử dụng hệ thống Việc mô tả ngắn gọn mỗi tác nhân phải nêu bật được các yêu cầu và các trách nhiệm của tác nhân đó Các tác nhân nhận được ở đây có thể dùng làm điểm xuất phát để tìm các ca sử dụng

Bước 2: Tìm các ca sử dụng

Mỗi cách thức mà tác nhân sử dụng hệ thống được gọi là một ca sử dụng Từ danh sách các tác nhân, ta xác định các ca sử dụng mà mỗi tác nhân này thực hiện Mỗi ca sử dụng đặc tả một chuỗi các hành động (kể cả các chuỗi hành động thay thế)

mà hệ thống có thể thực hiện khi tương tác với các tác nhân của nó Một thể hiện ca sử dụng là sự thực hiện (hoặc xử lý) của ca sử dụng đó

Bước 3: Mô tả ngắn gọn mỗi ca sử dụng

Sau khi tìm được các ca sử dụng, trước hết mô tả nó một cách ngắn gọn để tóm tắt các hành động của ca sử dụng

Bước 4: Mô tả Mô hình ca sử dụng tổng thể

Một mô hình ca sử dụng là một mô hình của một hệ thống Nó bao gồm các tác nhân, các ca sử dụng và các mối quan hệ giữa chúng Chúng ta sử dụng các biểu đồ và các mô tả để diễn đạt mô hình ca sử dụng tổng thể, đặc biệt là các ca sử dụng có liên quan đến nhau Các ca sử dụng trong mô hình ca sử dụng có thể được tổ chức thành các cụm ca sử dụng được gọi là các gói ca sử dụng

Kết quả của bước này cũng là một mô tả tổng quan của mô hình ca sử dụng Nó

mô tả các tác nhân và các ca sử dụng tương tác với nhau như thế nào, và các ca sử dụng liên kết với nhau như thế nào

b Sắp xếp thứ tự ưu tiên các ca sử dụng

Mục đích hoạt động này là nhằm lập thứ tự ưu tiên các ca sử dụng để quyết định những ca sử dụng nào cần được triển khai ngay trong những lần lặp đầu và chúng đóng vai trò như kiến trúc của hệ thống

Mô tả kiến trúc là một cái nhìn về mặt kiến trúc của mô hình ca sử dụng Nó gồm những ca sử dụng mang ý nghĩa về mặt kiến trúc Một mô tả kiến trúc của một

mô hình ca sử dụng thường bao gồm các ca sử dụng mô tả một vài chức năng cốt yếu

và quan trọng hoặc liên quan đến một vài yêu cầu quan trọng mà cần được phát triển

Mô tả kiến trúc này thường được sử dụng như là đầu vào để phân loại các ca sử dụng cho việc phát triển trong một vài bước lặp đầu

c Mô tả chi tiết một ca sử dụng

Mục đích chính ở đây là mô tả luồng các sự kiện của ca sử dụng một cách chi tiết khi khởi đông, tương tác với các tác nhân như thế nào đến kết thúc Để mô tả chi tiết ca sử dụng ta có thể mô tả bằng văn bản (hay bảng) và các biểu đồ ca sử dụng kèm theo

Luồng các sự kiện của một ca sử dụng là luồng các sự kiện đặc tả chuỗi công việc mà hệ thống làm khi một ca sử dụng cụ thể được thực hiện Luồng các sự kiện cũng đặc tả cách thức mà hệ thống tương tác với các tác nhân khi ca sử dụng được thực hiện Nó có thể được mô tả dưới dạng văn bản (hay bảng) chuỗi các hoạt động của một ca sử dụng

- Cấu trúc của một mô tả ca sử dụng thường được tổ chức sao cho cả người phát triển, khách hàng, và người dùng đều có thể hiểu được Mô tả ca sử dụng cần có cấu trúc như sau:

 Trạng thái xuất phát (tiền điều kiện)

 Làm thế nào và khi nào thì ca sử dụng khởi động (tức là hành động thứ nhất được thực hiện như thế nào)

 Các chuỗi hành động phải được thực hiện theo thứ tự Ở đây thứ tự được xác định bởi chuỗi hành động đã đánh số

 Ca sử dụng kết thúc như thế nào và khi nào

 Trạng thái khi kết thúc (hậu điều kiện)

 Các con đường không được phép thực hiện

 Mô tả các con đường cơ bản (phương án) mà dãy hành động xảy ra

 Mô tả các phương án ngoại lệ

Có thể mô tả mỗi phương án thực hiện ca sử dụng bằng văn bản (hay một bảng với cột tác nhân và cột phản ứng của hệ thống)

Một nhiệm vụ quan trọng nữa là đặc tả là những yêu cầu phi chức năng Đa số các yêu cầu phi chức năng đều có liên quan tới một ca sử dụng cụ thể nào đó Chẳng hạn các yêu cầu về tốc độ thực hiện, tính khả dụng, độ chính xác, thời gian phúc đáp, thời gian phục hồi Các yêu cầu như vậy được gọi là các yêu cầu đặc biệt của ca sử dụng đang xét Ta có thể chuẩn bị chúng như một phần tài liệu của Mô tả ca sử dụng

- Hình thức hóa các mô tả ca sử dụng: Đối với các ca sử dụng phức tạp, có nhiều trạng thái và sự chuyển tiếp, các mô tả ca sử dụng bằng văn bản thường không đảm bảo tính chất nhất quán và làm cho người phát triển khó hình dung Do vậy, có thể mô tả cấu trúc đó bằng cách sử dụng các biểu đồ có tính trực quan hơn

d Tạo bản mẫu Giao diện người dùng

Bây giờ ta cần phác thảo các giao diện người dùng để giúp cho người thực hiện các ca sử dụng một cách hiệu quả Với mỗi ca sử dụng, ta cố gắng để nhận biết xem cái gì là cần đối với các giao diện người dùng để tạo ra khả năng cho mỗi tác nhân

dùng các ca sử dụng Công việc này gọi là thiết kế giao diện người dùng logic Sau đó

ta tạo thiết kế giao diện người dùng thực và phát triển các bản mẫu để minh họa cách thức mà các người dùng có thể dùng hệ thống để thực hiện các ca sử dụng

- Tạo một thiết kế Giao diện người dùng Logic: Khi các tác nhân tương tác với

hệ thống, tác nhân sẽ dùng và thao tác qua yếu tố giao diện người dùng thể hiện cho các thuộc tính của các ca sử dụng Ta sẽ xác định và đặc tả các yếu tố này cho một tác nhân tại một thời điểm xác định bằng cách duyệt qua mọi ca sử dụng mà tác nhân

có thể truy nhập và xác định các yếu tố giao diện người dùng tương ứng cho mỗi

ca sử dụng

- Tạo một thiết kế giao diện người dùng thực và làm bản mẫu: Trước tiên, ta chuẩn bị các phác thảo thô của chùm các yếu tố giao diện - người dùng hình thành các giao diện người dùng có ích cho các tác nhân Sau đó bổ sung các yếu tố cần thiết để

tổ hợp hàng yếu tố của giao diện – người dùng thành các giao diện người dùng đầy đủ Các yếu tố bổ sung này có thể bao gồm các bộ chứa (container) các yếu tố giao diện người dùng, các cửa sổ, các công cụ và các điều khiển

e Tái cấu trúc mô hình ca sử dụng

Mục đích của việc tái cấu trúc mô hình ca sử dụng là

- Tìm ra các mô tả chức năng có đặc tính chung hay được chia sẻ trong nhiều

sử dụng ngôn ngữ của nhà phát triển để mô tả các kết quả nhận được và ta sẽ nhận được một mô hình phân tích

Mô hình phân tích là một mô hình đối tượng khái niệm Nó xác định các yêu cầu và lập luận về cấu trúc nội tại của hệ thống Mô hình phân tích được thể hiện ở mức cao bằng một hệ thống các gói phân tích Trong mô hình phân tích, các ca sử dụng được thực thi bởi các lớp và các đối tượng phân tích Để tạo ra mô hình phân tích cần tiến hành:

- Phân tích kiến trúc

- Phân tích một ca sử dụng

- Phân tích một lớp

- Phân tích một gói

Trong quá trình phân tích, ta sẽ liên tục tìm các gói, các lớp phân tích mới và các yêu cầu chung khi mô hình phân tích được tiếp tục làm mịn bằng cách phân rã các gói phân tích và duy trì các gói đó

2.3.2.1 Phân tích kiến trúc

Mục đích của phân tích kiến trúc là phác họa những nét lớn của mô hình phân tích thông qua việc xác định các gói phân tích, các lớp phân tích hiển nhiên, và các yêu cầu chuyên biệt chung

a Xác định các gói phân tích

Việc xác định các gói phân tích có thể được tiến hành một cách tự nhiên dựa trên các yêu cầu chức năng và nghiệp vụ của bài toán được xét Một cách trực tiếp để xác định các gói phân tích là bố trí phần lớn các ca sử dụng vào một gói riêng rồi sau

đó tiến hành thực thi chức năng tương ứng bên trong gói đó Gom các ca sử dụng vào một gói riêng thích hợp có thể dựa trên các tiêu chí sau:

- Các ca sử dụng cần có để hỗ trợ một quá trình nghiệp vụ riêng

- Các ca sử dụng cần có để hỗ trợ một tác nhân riêng của hệ thống

- Các ca sử dụng có quan hệ với nhau thông qua các quan hệ tổng quát hóa và

mở rộng

Các gói phân tích cung cấp một phương tiện để tổ chức các chế tác của mô hình phân tích thành các “cụm” nhỏ hơn và dễ quản lý Một gói phân tích có thể chứa đựng các lớp phân tích, các thực thi ca sử dụng và các gói phân tích khác

b Xử lý phần chung của các gói phân tích

Trong nhiều trường hợp ta có thể tìm thấy các phần chung giữa các gói phân tích, chẳng hạn: một lớp phân tích Một cách thích hợp để xử lý vấn đề này là đặt phần chung đó vào trong gói riêng nằm ngoài các gói chứa nó, rồi sau đó để các gói khác có liên quan phụ thuộc vào gói chứa lớp chung này

Những lớp được chia sẻ có các phần chung như vậy thường là các lớp thực thể Chúng có thể được lần vết tới các lớp thực thể miền hoặc nghiệp vụ Do vậy, ta nên nghiên cứu các lớp thực thể miền hoặc lớp thực thể nghiệp vụ để tìm ra phần chung và tạo nên các gói phân tích tổng quát ngay từ đầu

c Xác định các gói dịch vụ

Mỗi hệ thống cung cấp một tập hợp các dịch vụ cho khách hàng Ta sử dụng khái niệm gói dịch vụ để mô tả các gói được sử dụng ở một mức thấp hơn trong sơ đồ phân cấp phân tích để cấu trúc hệ thống các dịch vụ mà nó cung cấp

d Xác định các mối quan hệ phụ thuộc giữa các gói phân tích

Mục tiêu ở đây là tìm ra các gói phân tích tương đối độc lập với các gói khác, tự chúng được ghép nối lỏng lẻo với nhau nhưng có kết quả kết dính cao bên trọng Với mục tiêu trên ta cố gắng giảm số lượng các mối quan hệ giữa các lớp thuộc tính các gói khác nhau Cách tốt nhất để thực hiện công việc này là tổ chức mô hình phân tích thành các tầng bằng cách ghép các gói ứng dụng cụ thể ở một tầng đỉnh và các gói tổng quát hơn ở một tầng thấp hơn

e Xác định các lớp thực thể hiển nhiên

Ta có thể xác định các lớp thực thể quan trọng nhất dựa trên các lớp miền hoặc các thực thể nghiệp vụ đã được xác định trong quá trình nắm bắt các yêu cầu Ở bước này không nên xác định quá nhiều lớp và đi quá sâu vào chi tiết Một phác thảo ban đầu bao gồm các lớp có ý nghĩa về mặt kiến trúc là đủ

f Xác định các yêu cầu đặc biệt chung

Một yêu cầu đặc biệt là một yêu cầu nảy sinh ra trong quá trình phân tích và việc nắm bắt nó là quan trọng Các yêu cầu kiểu này có thể là:

- Tính lâu bền

- Sự phân bố và tính tương tranh

- Các điểm đặc trưng về an toàn

- Dung sai về lỗi

Lớp phân tích thể hiện cho một sự trừu tượng của một hoặc nhiều lớp và/hoặc

hệ thống con trong thiết kế hệ thống Có ba kiểu lớp cơ bản sau: lớp biên, lớp điều khiển, và lớp thực thể

Một lớp biên thường được sử dụng để mô hình hóa tương tác giữa hệ thống và các tác nhân của nó Tương tác này bao gồm có việc nhận và hiển thị thông tin từ các yêu cầu của người dùng và của các hệ thống ngoài Mỗi lớp biên liên quan đến ít nhất một tác nhân và ngược lại

Các lớp biên thường thể hiện như các trừu tượng hóa của các cửa sổ (window), các biểu mẫu (form), các bảng hiển thị (pane), các giao diện truyền thông (communication interface), giao diện máy in (printer interface), các bộ cảm biến (sensor), các đầu cuối (terminal)…, nhưng ở một mức độ tương đối cao và mang tính khái niệm chứ không đi quá sâu vào chi tiết giao diện người dùng

Một lớp thực thể được dùng để mô hình hóa các thông tin tồn tại lâu dài và có thể được lưu trữ Các lớp thực thể thường thể hiện các cấu trúc dữ liệu logic và góp phần làm rõ về các thông tin nào mà hệ thống phải dựa vào

Chúng ta sẽ xác định các lớp điều khiển, lớp thực thể, và lớp biên cần thiết để thực thi ca sử dụng và phác thảo các tên gọi, các trách nhiệm, các thuộc tính và các mối quan hệ của chúng

Một thực thi ca sử dụng phân tích là một sự cộng tác trong mô hình phân tích

mô tả làm thế nào một ca sử dụng cụ thể được thực hiện và thể hiện dưới dạng các lớp phân tích và các đối tượng phân tích tương tác với nhau

b Mô tả các tương tác giữa các đối tượng phân tích

Khi đã có một phác thảo về các lớp phân tích cần thiết để thực thi các ca sử dụng chúng ta cần phải mô tả cách thức mà các đối tượng phân tích tương tác với nhau như thế nào Việc này được tiến hành bằng cách sử dụng các biểu đồ cộng tác, chúng chứa các thể hiện của tác nhân tham gia, các đối tượng phân tích, và các mối liên kết giữa chúng Nếu ca sử dụng có các luồng hoặc luồng con khác nhau và tách biệt thì nên tạo một biểu đồ cộng tác riêng cho mỗi luồng

Một biểu đồ cộng tác xuất phát từ một điểm khởi đầu của luồng sự kiện ca sử dụng sau đó đi theo luồng từng bước và xác định xem đối tượng phân tích nào và các tương tác của các thể hiện tác nhân nào là cần thiết để thực thi ca sử dụng đó Trong một số trường hợp, có thể bổ sung các mô tả bằng văn bản cho các biểu đồ cộng tác, đặc biệt nếu có nhiều biểu đồ thực thi cùng một ca sử dụng hoặc nếu có các biểu đồ trình bày các luồng phức tạp

b Nắm bắt các yêu cầu đặc biệt

Ta cần nắm bắt các yêu cầu (phi chức năng) cần cho việc thực thi một ca sử dụng mà đã được xác định trong phân tích nhưng phải được xử lý trong thiết kế và thực thi

2.3.2.3 Phân tích một lớp

Mục đích của việc phân tích một lớp là:

- Xác định và duy trì các trách nhiệm của một lớp phân tích dựa trên vai trò của nó trong các thực thi ca sử dụng

- Xác định và duy trì các thuộc tính và các mối quan hệ của lớp phân tích

- Nắm bắt các yêu cầu đặc biệt về việc thực thi của lớp phân tích

2.3.2.4 Phân tích một gói

Mục đích của việc phân tích một gói nhằm:

- Đảm bảo rằng gói phân tích càng độc lập đối với các gói khác càng tốt

- Đảm bảo rằng gói phân tích hoàn thành mục đích của nó là thực thi những lớp miền hoặc các ca sử dụng nào đó

- Mô tả các mối quan hệ phụ thuộc sao cho hiệu ứng của các thay đổi sau này

có thể ước tính được

2.3.3 Thiết kế hệ thống

Trong thiết kế, chúng ta định hình hệ thống và tìm hình thức biểu diễn nó để thực hiện được mọi yêu cầu kể cả các yêu cầu phi chức năng và các ràng buộc khác được đặt ra cho hệ thống đó Một đầu vào cho thiết kế là mô hình phân tích Khi thiết

kế sẽ cố gắng bảo tồn được càng nhiều càng tốt cấu trúc của hệ thống được định hình

từ mô hình phân tích Kết quả của thiết kế là mô hình thiết kế Nó là một bản vẽ thiết

kế của việc thực thi mô hình phân tích

Mô hình thiết kế là một mô hình đối tượng mô tả sự thực thi các ca sử dụng bằng cách tập trung vào việc xác định các yêu cầu chức năng và phi chức năng, cũng như các ràng buộc khác liên quan đến môi trường triển khai và ảnh hưởng của chúng lên hệ thống

Để nhận được mô hình thiết kế ta cần thực hiện các công việc sau:

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

Mục đích của thiết kế kiến trúc là phác họa các mô hình thiết kế và sự bố trí của chúng bằng cách xác định:

- Các nút và các cấu hình mạng của hệ thống

- Các hệ thống con và các giao diện của chúng

- Các lớp thiết kế quan trọng về mặt kiến trúc

- Các cơ chế thiết kế chung để xử lý các yêu cầu chung

Các hệ thống con, các giao diện, hoặc các yếu tố thiết kế khác nhận được sẽ được tích hợp vào trong mô hình thiết kế Sau đó ta cần bảo trì, thẩm định lại và cập nhật mô tả kiến trúc của các mô hình thiết kế và mô hình bố trí

Mô hình bố trí là một mô hình đối tượng mô tả sự phân bố về mặt vật lý của hệ thống dưới dạng phân tán các chức năng trên các nút như thế nào Mô hình

bố trí bao gồm:

- Các nút, các đặc trưng, và các kết nối của chúng

- Một sự sắp xếp ban đầu các lớp hoạt động trên các nút

Mỗi nút thể hiện cho một nguồn tài nguyên tính toán Các nút có các mối quan

hệ với nhau thể hiện các phương tiện truyền thống giữa chúng

Mô hình bố trí có thể mô tả rất nhiều cấu hình mạng khác nhau Chức năng của một nút được xác định bởi các thành phần được triển khai trên các nút đó Mô hình bố trí thể hiện một ánh xạ giữa kiến trúc phần mềm và kiến trúc hệ thống

b Xác định các hệ thống con và các giao diện của chúng

Các hệ thống con thiết kế cung cấp một cách thức để tổ chức mô hình thiết kế thành các cụm có thể quản lý được Chúng có thể được xác minh ngay từ đầu như là một cách để phân chia công việc thiết kế hoặc được xác định khi mô hình thiết kế tiến hóa và một cấu trúc lớn cần được phân rã ra Việc đưa các hệ thống con như thế vào trong mô hình thiết kế cho phép có thể lập luận và đánh giá các cơ hội tái sử dụng của chúng

Một hệ thống con có thể bao gồm các lớp thiết kế, các thực thi ca sử dụng, các giao diện và các hệ thống con Ngoài ra, một hệ thống con có thể còn cung cấp các giao diện thể hiện cho các chức năng xuất ra dưới dạng các tác vụ

Các giao diện được sử dụng để đặc tả các tác vụ mà các lớp thiết kế và các hệ thống con cung cấp Phần lớn các giao diện giữa các hệ thống con đều mang ý nghĩa

về mặt kiến trúc, xác định phạm vi và cách thức mà các hệ thống con được phép tương tác với nhau

Một lớp thiết kế cung cấp một giao diện thì cũng phải cung cấp các phương thức thực thi các tác vụ của giao diện đó Một hệ thống con cung cấp một giao diện thì phải chứa đựng các lớp thiết kế hoặc các hệ thống con khác cung cấp phương thức thực thi giao diện đó

c Xác định các lớp thiết kế quan trọng về mặt kiến trúc

Mô tả kiến trúc cho một mô hình thiết kế thường gồm:

- Các hệ thống con, các giao diện và các phụ thuộc giữa chúng

- Các lớp thiết kế cốt lõi, chẳng hạn như các lớp thiết kế mà lần vết tới các lớp phân tích mang ý nghĩa kiến trúc, các lớp động, và các lớp thiết kế có tính chất tổng quát và trung tâm, thể hiện cho các cơ chế thiết kế chung và có nhiều mối quan hệ với các lớp thiết kế khác

- Các thực thi ca sử dụng thiết kế để thực thi những chức năng cốt lõi và quan trọng nhất cần được phát triển trong vòng đời phát triển, liên quan rất nhiều các lớp thiết kế và có mức độ bao trùm lớn, qua nhiều hệ thống con khác nhau, hoặc liên quan đến những lớp thiết kế cốt lõi

d Xác định các cơ chế thiết kế chung

Ta cần đưa ra một bộ các cơ chế thiết kế chung Các cơ chế này có thể biểu thị

là các lớp thiết kế, các cộng tác, hoặc ngay cả các hệ thống con Các yêu cầu cần phải

xử lý thường có liên quan tới các vấn đề như: tính lâu bền, phân bố đối tượng trong suốt, các đặc trưng an toàn, phát hiện lỗi và phục hồi, quản lý giao dịch Trong một số trường hợp, không thể tìm thấy cơ chế ngay nhưng thay vào đó lại tìm được khi các thực thi ca sử dụng và các lớp thiết kế được khảo sát Người phát triển cũng phải xác định các cộng tác chung mà chúng có thể làm việc như là các dạng mẫu (pattern) và được sử dụng bởi nhiều thực thi ca sử dụng bên trong mô hình thiết kế

2.3.3.2 Thiết kế một ca sử dụng

Mục tiêu của việc thiết kế một ca sử dụng là:

a Xác định các lớp thiết kế tham gia

Các lớp thiết kế cần thiết được xác định để thực thi ca sử dụng thiết kế như sau:

- Nghiên cứu các lớp phân tích tham gia vào việc thực thi ca sử dụng phân tích Xác định các lớp thiết kế bằng cách lần vết tới các lớp phân tích đó

- Nghiên cứu các yêu cầu đặc biệt của việc thực thi ca sử dụng phân tích tương ứng Xác định các lớp thiết kế cần để thực thi các yêu cầu đặc biệt đó