1. Trang chủ
  2. » Luận Văn - Báo Cáo

framework và ứng dụng cho một lớp bài toán quản lý (2)

62 488 0

Đ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

Định dạng
Số trang 62
Dung lượng 2,3 MB

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

Nội dung

Đối tượng và phạm vi nghiên cứu Trong luận văn, sau khi đã cứu tổng quan về “khung làm việc” hướng đối tượng, dựa trên ý tưởng chung của một số phương pháp phát triển một khung làm việc

Trang 1

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

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

Trần Hoài Nam

FRAMEWORK VÀ ỨNG DỤNG CHO MỘT LỚP

BÀI TOÁN QUẢN LÝ

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

Hà Nội - 2012

Trang 2

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

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

Trần Hoài Nam

FRAMEWORK VÀ ỨNG DỤNG CHO MỘT LỚP

BÀI TOÁN QUẢN LÝ

Ngành: Công Nghệ Thông Tin

Chuyên ngành: Công Nghệ Phần Mềm

Mã số: 60.48.10

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

NGƯỜI HƯỚNG DẪN KHOA HOC: PGS TS Nguyễn Văn Vỵ

Hà Nội - 2012

HÀ NỘI - 2012

Trang 3

MỤC LỤC

LỜI CAM ĐOAN 1

LỜI CẢM ƠN 2

MỤC LỤC 3

BẢNG CHỮ VIẾT TẮT 5

DANH MỤC CÁC HÌNH VẼ VÀ ĐỒ THỊ 5

MỞ ĐẦU 7

1 Cơ sở khoa học và thực tiễn của đề tài 7

2 Đối tượng và phạm vi nghiên cứu 7

3 Cấu trúc của luận văn 7

Chương 1: TỔNG QUAN VỀ KHUNG LÀM VIỆC 9

1.1 Khái niệm về khung làm viêc 9

1.1.1 Định nghĩa về khung làm việc 9

1.1.2 Cấu trúc của một khung làm việc 10

1.1.3 Phân biệt khung làm việc với các khái niệm khác 11

1.1.4 Các đặc điểm của khung làm việc 13

1.2 Phân loại khung làm việc 14

1.2.1 Phân loại khung làm việc theo vùng vấn đề 14

1.2.2 Phân loại khung làm việc theo cấu trúc nội bộ 15

1.3 Các qui trình phát triển khung làm việc 16

1.3.1 Quy trình phát triển dựa trên các ứng dụng kinh nghiệm 16

1.3.2 Quy trình phát triển dựa trên phân tích vấn đề miền 17

1.3.3 Quy trình phát triển sử dụng các mẫu thiết kế 17

1.3.4 Quy trình phát triển khung làm việc chung 18

1.4 Phương pháp phát triển khung làm việc 19

1.4.1 Chuẩn bị cho việc phát triển khung làm việc 20

1.4.2 Thu thập yêu cầu và phân tích 21

1.4.3 Thiết kế khung làm việc 26

1.4.4 Triển khai khung làm việc 31

1.4.5 Xác minh và thẩm định tính hợp lệ 32

1.4.6 Các vấn đề trong việc phát triển khung làm việc 32

-Chương 2: KHUNG LÀM VIỆC CỦA BÀI TOÁN ĐẦU TƯ CHO SẢN XUẤT NÔNG NGHIỆP 34

2.1 Vấn đề đặt ra trong sản xuất nông nghiệp và bài toán đầu tư 34

Trang 4

2.2 Bài toán đầu tư cho sản xuất mía đường 36

2.2.1 Mô tả bài toán 36

2.2.2 Biểu đồ hoạt động của quy trình đầu tư 37

2.2.3 Xác định mô hình miền lĩnh vực đầu tư trồng mía 38

2.3 Bài toán đầu tư cho chăn nuôi bò sữa 40

2.3.1 Mô tả bài toán 40

2.3.2 Biểu đồ hoạt động của quy trình đầu tư 41

2.3.3 Xác định mô hình miền lĩnh vực đầu tư chăn nuôi 42

2.4 Tổng quát hóa mô hình miền lĩnh vực của đầu tư trong nông nghiệp 44

2.4.1 Những vấn đề cần khái quát hóa 44

2.4.2 Các đối tượng nghiệp vụ cần bổ sung 45

2.4.3 Mô hình miền lĩnh vực cho lớp bài toán đầu tư trong nông nghiệp 45

2.5 Chuyển mô hình nghiệp vụ sang mô hình lớp thiết kế 45

2.5.1 Biểu đồ lớp cho khối lập dự án và ký kết hợp đồng 48

2.5.2 Biểu đồ lớp cho khối triển khai thực hiện đầu tư 49

2.5.3 Biểu đồ lớp thiết kế cho khối thu hoạch sản phẩm 49

2.5.4 Biểu đồ lớp thiết kế cho khối kết toán và thanh lý hợp đồng 50

2.6 Áp dụng mẫu cho thiết kế 50

2.6.1 Áp dụng mẫu chiến lược cho khối lựa chọn chiến lược 51

2.6.2 Áp dụng mẫu chiến lược cho khối thực hiện đầu tư 52

2.6.3 Áp dụng mẫu chiến lược cho khối thu hoạch sản phẩm 53

-Chương 3: TRIỂN KHAI ỨNG DỤNG VÀ CÀI ĐẶT CHO BÀI TOÁN ĐẦU TƯ TRỒNG MÍA 54

3.1 Mô tả bài toán quản lý đầu tư vùng nguyên liệu 54

3.2 Làm thích nghi khung làm việc đối với bài toán đầu tư trồng mía 54

3.2.1 Sửa đổi tên gọi và thuộc tính của các lớp cho phù hợp với nghiệp vụ 54 3.2.2 Bổ sung các lớp giao diện cho thiết kế 55

3.3 Cài đặt và sử dụng khung làm việc 57

3.4 Giới thiệu chương trình thử nghiệm 57

3.4.1 Kiến trúc của hệ thống chương trình 57

3.4.2 Một số giao diện của chương trình 58

3.5 Hiệu quả chương trình đạt được 60

KẾT LUẬN 61

TÀI LIỆU THAM KHẢO 62

Trang 5

-BẢNG CHỮ VIẾT TẮT

Ajax Asynchronous JavaScript and XML

API Application Programming Interface

ROI Return On Investement

DANH MỤC CÁC HÌNH VẼ VÀ ĐỒ THỊ

Hình 1.1 Mối quan hệ giữa các thành phần trong một khung làm việc[3] 10

Hình 1.2 Quy trình phát triển khung dựa trên kinh nghiệm về ứng dụng [8] 16

Hình 1.3 Quy trình phát triển khung làm việc dựa trên phân tích miền vấn đề [8] 17

Hình 1.4 Quy trình phát triển khung làm việc sử dụng các mẫu thiết kế [8] 18

Hình 1.5 Quy trình phát triển khung làm việc chung [8] 19

Hình 1.6 Quá trình phát triển khung làm việc [1] 20

Hình 1.7 Các quá trình con và sản phẩm của pha Thu thập yêu cầu và Phân tích [1] 22

Hình 1.8 Sự phân chia các yêu cầu [1] 23

Hình 1.9 Mối quan hệ giữa mô hình Ca sử dụng và các mô hình khác [1] 24

Hình 1.10 Khung làm việc là phần chung của các ứng dụng trong một miền [1] 27

Hình 1.11 Các hoạt động trong pha thiết kế khung làm việc [7] 28

Hình 1.12 Các hoạt động trong pha thiết kế kiến trúc [1] 29

Hình 1.13 Nguyên tắc định nghĩa sự công tác giữa các lớp trừu tượng [1] 30

Hình 2.1 Mô hình đầu tư cho sản xuất nông nghiệp để nhận sản phẩm 35

Hình 2.2 Biểu đồ hoạt động quá trình đầu tư cho sản xuất mía đường 37

Hình 2.3 Biểu đồ miền lĩnh vực đầu tư trồng mía 39

Hình 2.4 Biểu đồ hoạt động quá trình đầu tư cho chăn nuôi bò sữa 41

Hình 2.5 Biểu đồ miền lĩnh vực của bài toán đầu tư chăn nuôi bò 43

Trang 6

Hình 2.6 Mô hình miền lĩnh vực cho lớp các bài toán đầu tƣ trong nông nghiệp 47

Hình 2.7 Biểu đồ lớp thiết kế khối lập dự án và ký hợp đồng 48

Hình 2.8 Biểu đồ lớp thiết kế khối thực hiện đầu tƣ 49

Hình 2.9 Biểu đồ lớp thiết kế khối thu hoạch sản phẩm 49

Hình 2.10 Biểu đồ lớp thiết kế khối thanh lý hợp đồng 50

Hình 2.11 Biểu đồ lớp thiết kế khối lựa chọn chiến lƣợc ban đầu 51

Hình 2.12 Biểu đồ lớp thiết kế khối lựa chọn chiến lƣợc sau áp dụng mẫu 52

Hình 2.13 Biểu đồ lớp thiết kế khối thực hiên đầu tƣ sau áp dụng mẫu 52

Hình 2.14 Biểu đồ lớp thiết kế khối thu hoạch tƣ sau áp dụng mẫu 53

Hình 3.1 Biểu đồ lớp thiết kế khối lập dự án ký kết hợp đồng của bài toán trồng mía 55

Hình 3.2 Biểu đồ lớp thiết kế khối lập triển khai thực hiện đầu tƣ bài toán trồng mía 56

Hình 3.3 Biểu đồ lớp thiết kế khối thu hoạch sản phẩm bài toán trồng mía 56

Hình 3.4 Giao diện quản lý chính của phần mềm 58

Hình 3.5 Quản lý hợp đồng trồng mía 59

Hình 3.6 Chi tiết hợp đồng đầu tƣ trồng mía 59

Hình 3.7 Quản lý thông tin thửa ruộng 60

Trang 7

MỞ ĐẦU

1 Cơ sở khoa học và thực tiễn của đề tài

Phần lớn chi phí và các hoạt động liên tục trong phát triển phần mềm là tái tìm kiếm và tái tạo tạo lại các thành phần cốt lõi Đặc biệt tính không đồng nhất của các phần cứng, cùng với sự đa dạng của hệ điều hành và nền tảng truyền thông làm cho khó khăn để xây dựng chính xác các ứng dụng sao cho dễ dàng thích nghi, thay đổi, hiệu quả và ít tốn kém từ các khoản ban đầu

Mô hình khung làm việc (Framework) hướng đối tượng là một công nghệ đầy hứa hẹn cho thiết kế và triển khai phần mềm, hướng đến làm giảm chi phí, thời gian và nâng cao chất lượng của phần mềm bằng cách sử dụng lại Sử dụng khung làm việc là tái sử dụng “phần cốt lõi” của một lớp bài toán đã được xây dựng sẵn, sau đó sửa đổi, làm thích nghi nó và bổ sung những thành phần còn thiếu để được một ứng dụng đầy

đủ cho bài toán cụ thể thuộc về lớp bài toán của khung làm việc

Khung làm việc hướng đối tượng ngày nay đã và đang phát triển một cách mạnh

mẽ, nó là hướng phát triển khuôn mẫu dùng chung cho một lớp bài toán có những đặc thù riêng Cơ sở của nó là phân tích thiết kế hướng đối tượng và việc sử dụng các mẫu

có khả năng thích nghi cao khi tính đến các tình huống có thể xẩy ra của các bài toán

cụ thể sẽ gặp Ngày nay có nhiều khung làm việc đã được phát triển để phục vụ cho tin học hóa các lớp bài toán khác nhau Nhờ vậy mà tacó thể giải quyết được nhiều bài

toán thực tế một cách nhanh chóng và hiệu quả Đề tài “Framework và ứng dụng cho một lớp bài toán quản lý” đã được tôi chọn làm đề tài luận văn của mình

2 Đối tượng và phạm vi nghiên cứu

Trong luận văn, sau khi đã cứu tổng quan về “khung làm việc” hướng đối tượng, dựa trên ý tưởng chung của một số phương pháp phát triển một khung làm việc, xây dựng một khung làm việc cho một lớp bài toán “đầu tư trong sản xuất nông nghiệp”và

sử dụng khung làm việc này để triển khai một ứng dụng cụ thể Vì thời gian và khuôn khổ hạn chế của luận văn, luận văn sẽ không đi sâu trình bày một cách chi tiết về mặt

kỹ thuật các bước xây dựng khung làm việc, vì như vậy sẽ rất dài và không đủ thời gian, mà chỉ mô tả khái quát cách làm và đưa ra kết quả thực hiện của mỗi bước và kết quả cuối cùng hướng đến

3 Cấu trúc của luận văn

Cấu trúc của luận văn bao gồm các phần sau:

Mở đầu: Giới thiệu cơ sở khoa học và thực tiễn của đề tài

Trang 8

Chương 1: Giới thiệu tổng quan về khung làm việc hướng đối tượng, bao gồm

các khái niệm, đặc điểm và phân loại khung làm việc hướng đối tượng Chương cũng nêu ra các phương pháp để phát triển một khung làm việc

Chương 2: Phát triển khung làm việc cho lớp bài toán đầu tư trong nông nghiệp: chương này đưa ra mô tả khái quát về bài toán đầu tư cho nông

nghiệp, cho phép ta nhận biết cấu trúc tổng thể của lớp bài toán đầu tư Nó là

cơ sở để có thể triển khai khung làm việc cho lớp bài toán có cùng cấu trúc chung này Tiếp theo nghiên cứu hai bài toán đầu tư cụ thể điển hình trong sản xuất nông nghiệp, từ đó khái quát hóa để được phần chung cốt lõi của hai bài toán Với phần chung này, sử dụng các mẫu thiết kế cấu trúc lại phần cốt lỗi thành một khung để có khả năng làm thích nghi nó cho những bài toán cụ

thể khác nhau của lớp

Chương 3: Triển khai ứng dụng và cài đặt khung làm việc cho bài toán đầu

tư trồng mía: Xác định các đối tượng, yêu cầu cụ thể của bài toán, tìm ra các

lớp của khung cần sửa đổi để phù hợp với bài toán này Đồng thời bổ sung thêm vào khung các lớp giao diện vào-ra, để cập nhật dữ liệu vào và đưa các

dữ liệu ra cho bài toán mía đường và đưa ra được một thiết kế đầy đủ Lựa

chọn môi trường và ngôn ngữ cài đặt, chuyển thiết kế thành chương trình và chạy thử nghiệm với các dữ liệu thực

Kết luận: Nêu ra những kết quả đã thực hiện trong luận văn và hướng phát

triển tiếp tục

Trang 9

Chương 1: TỔNG QUAN VỀ KHUNG LÀM VIỆC

1.1 Khái niệm về khung làm viêc

Thiết kế phần mềm là công việc khó và việc thiết kế của phần mềm để có thể sử dụng lại còn khó hơn rất nhiều Một khung làm việc định hướng đối tượng là một loại cấu trúc phần mềm có thể sử dụng lại bao gồm cả thiết kế và code Khái niệm khung làm việc được mong đợi sẽ làm tăng tính hiệu quả trong quá trình phát triển phần mềm của các kỹ sư phần mềm

Khung làm việc định hướng đối tượng là gì? Tồn tại rất nhiều định nghĩa khác nhau và giống nhau về khung làm việc trong đó định nghĩa bởi Johnson và Foote là định nghĩa được biết đến nhiều nhất

“Một khung làm việc là một bộ các lớp mà nó là biểu hiện của một thiết kế trừu tượng cho các giải pháp cho loạt các vấn đề liên quan” [8]

Một định nghĩa tương tự cũng đã được Johnson đưa ra năm 1991

“Một khung làm việc là một bộ nổi bật các lớp cộng tác bao gồm cả các mẫu tỷ

lệ nhỏ và cơ chế lớn mà nó thực hiện các yêu cầu chung và thiết kế trong phạm vi một miền ứng dụng cụ thể” [8]

Ngoài ra còn một số các định nghĩa khác như

“Một khung làm việc ràng buộc các lựa chọn chính xác về sự phân chia trạng thái

và luồng điều khiển, người dùng hoàn thiện hoặc mở rộng khung làm việc để tạo ra một ứng dụng cụ thể” [1]

“Một khung làm việc hướng đối tượng là một loại kiến trúc phần mềm có thể sử dụng lại được cả thiết kế và mã nguồn” [2]

“Một khung làm việc là một tập các đối tượng mà cộng tác với nhau để tạo ra một tập các đáp ứng cho một ứng dụng hoặc một vùng hệ thống con” [1]

“Một khung làm việc là một tập các ký hiệu của các lớp cộng tác mà đạt được cả các mẫu phạm vi nhỏ và các cơ chế chủ yếu để thực hiện các yêu cầu chung và thiết kế trong một phạm vi ứng dụng cụ thể” [8]

Dựa trên các định nghĩa, chúng ta có thể định nghĩa lại khung làm việc định hướng đối tượng như sau

1.1.1 Định nghĩa về khung làm việc

Một khung làm việc bao gồm một tập các lớp mà các thể hiện của chúng cộng tác với nhau, được dự định để mở rộng, sử dụng lại cho các ứng dụng cụ thể của một lĩnh vực Một họ các vấn đề liên quan, cho phép tổng hợp trong một khung làm việc Hơn

Trang 10

nữa, các khung làm việc được biểu diễn thành một ngôn ngữ lập trình, như vậy nó cung cấp cho việc sử dụng lại cả mã thực hiện và thiết kế.[8]

1.1.2 Cấu trúc của một khung làm việc

Một khung làm việc hướng đối tượng bao gồm 5 thành phần sau [3]:

Các tài liệu thiết kế

Hình 1.1 Mối quan hệ giữa các thành phần trong một khung làm việc [3]

Các thành phần của một khung làm việc được mô tả như sau:

Các tài liệu thiết kế: các tài liệu thiết kế của một khung làm việc có thể bao gồm các

lược đồ lớp được mô tả bằng văn bản, hoặc có thể chi là một vài ghi chú về ý tưởng nảy sinh trong đầu tác giả

Các giao diện: các giao diện mô tả đáp ứng bên ngoài của các lớp Các giao diện có

thể được sử dụng để mô hình hóa các vai trò khác nhau trong một hệ thống, ví dụ nhu

Trang 11

các vai trò trong một mẫu thiết kế Một vai trò đại diện cho một nhóm nhỏ của các phương pháp trong giao diện mà liên quan tới phương pháp khác

Các lớp trừu tượng: một lớp trừu tượng là một sự thực hiện chưa đầy đủ của một hoặc

nhiều giao diện Nó có thể được sử dụng để định nghĩa cách đối xử mà sẽ là chung cho một nhóm các thành phần thực hiện một nhóm các giao diện

Các thành phần: Giống như các lớp, các thành phần có thể được tích hợp với các lớp

khác Trong hình vẽ, có một mũi tên “là thành phần của” giữa các lớp và các thành phần Nếu bản thân các lớp có một API (Application Programming Interface – giao diện lập trình ứng dụng) được định nghĩa đầy đủ thì tập kết quả của các lớp sẽ được biểu hiện như là một tổ hợp các thành phần Một thành phần được định nghĩa như sau:

“Một thành phần phần mềm là một đơn vị kết cấu với các giao diện được ghi rõ theo hợp đồng và các phụ thuộc ngữ cảnh rõ ràng Một thành phần phần mềm có thể được triển khai không phụ thuộc và được tổ hợp bằng các hãng thứ ba”

Các lớp: Mức thấp nhất của một framework là các lớp Các lớp chỉ khác với các thành

phần là trong thực tế, các giao diện lập trình ứng dụng (API) được công khai của nó không được đưa ra trong các giao diện của một khung làm việc Một cách điển hình là các lớp được sử dụng bởi các thành phần để đại diện cho chức năng, ví dụ một người phát triển ứng dụng sử dụng khung làm việc thường không nhìn thấy các lớp này trừ khi anh ta làm việc với các thành phần

Cách thức làm việc của một khung làm việc: Một khung làm việc hướng đối tượng làm việc bằng cách cung cấp một đặc tả rõ ràng của các tương tác được mong đợi giữa các thành phần Ví dụ, một thành phần có thể trông chờ những gì từ các thành phần khác và cái gì nên được cung cấp tới chúng? Một khung làm việc định nghia các dịch vụ lựa chọn, và cung cấp một giải thích cho việc định nghĩa thành phần nào là một thành phần cung cấp Như thế, một thành phần sẽ có khả năng được mở rộng rất lớn và các thành phần mới có thể tương tác mạnh mẽ với những cái đã có Chúng cộng tác với các chi tiết, khía cạnh cụ thể của các vấn đề được cân nhắc bởi khung làm việc Các thành phần ứng dụng có thể vẫn còn chứng minh tính tương thích với các vấn đề khác, như ngữ nghĩa của dữ liệu mà chúng chuyển qua Các bộ phận phụ thuộc có thể được giới thiệu như là các thành phần của khung làm việc Sự thi hành các thành phần này có thể cùng khung làm việc xác định một dịch vụ và cung cấp các dịch vụ này cho các thành phần khác

1.1.3 Phân biệt khung làm việc với các khái niệm khác

Một mẫu thiết kế khác với một khung làm việc ở ba điểm [1]:

Thứ nhất, một mẫu thiết kế là trừu tượng hơn một khung làm việc, bởi vì một

khung làm việc được bao gồm cả mã, trong khi đó chỉ có các ví dụ của các mẫu thiết

Trang 12

kế mới được mã hóa Các mẫu thiết kế thậm chí mô tả mục đích, việc cân bằng các yếu tố khác để đạt được sự kết hợp tốt nhất và các kết quả của một thiết kế Điều này không là một trường hợp cho các khung làm việc

Thứ hai, các mẫu thiết kế là những kiến trúc nhỏ hơn so với các khung làm

việc Do vậy, một khung làm việc có thể chứa một số các mẫu thiết kế, nhưng điều ngược lại là không thể Do vậy, các mẫu thiết kế không có ảnh hưởng lớn tới kiến trúc của ứng dụng

Cuối cùng, các khung làm việc được chuyên môn hóa hơn so với các mẫu thiết

kế Các khung làm việc luôn luôn liên quan đến một miền ứng dụng cụ thể, trong khi

đó các mẫu thiết kế là chung và có thể được ứng dụng trong bất kỳ miền ứng dụng nào

Các ngôn ngữ mẫu khác với khung làm việc theo cách mà một ngôn ngữ mẫu miêu tả: làm như thế nào để tạo ra một thiết kế Trong khi đó, một khung làm việc hướng đối tượng là một thiết kế Các ngôn ngữ mẫu bổ sung cho một khung làm việc,

do chúng có thể hướng dẫn các kỹ sư phần mềm sử dụng khung làm việc như thế nào,

và mô tả tại sao nó lại được thiết kế như vậy

Một ứng dụng hướng đối tượng khác với một khung làm việc ở chỗ, một ứng dụng mô tả một chương trình thực hiện phức tạp mà thỏa mãn một yêu cầu cụ thể Khung làm việc đạt được các tính năng của một ứng dụng nhưng nó không thể thi hành bởi vì nó không bao gồm các tương tác trong trường hợp ứng dụng cụ thể

Các khung làm việc khác với các thư viện lớp ở chỗ: chúng nhắm tới các miền ứng dụng cụ thể Trong khi đó, các thư viện lớp cung cấp cho người sử dụng các sự thực hiện trước của thuật toán Các thư viện lớp là thụ động, người sử dụng gọi các phương pháp trong thư viện lớp để thực hiện một số hoạt động Trong khi đó các khung làm việc định nghĩa khung cho một ứng dụng thực tế và điều khiển luồng điều khiển trong ứng dụng Các khung làm việc có thể khác so với thư viện lớp, nhưng chúng có thể sử dụng các thư viện lớp đã có sẵn để thực hiện các thuật toán chung và các cấu trúc dữ liệu

Các thành phần phần mềm ban đầu đã được dự định là các thành phần chức năng riêng lẻ mà có thể được đầu tư từ nhà cung cấp và tích hợp vào trong các ứng dụng Các khung làm việc dường như là những thành phần mà có thể được đầu tư từ nhà cung cấp và nhiều hơn một khung làm việc có thể được sử dụng trong một ứng dụng Tuy nhiên, một điểm khác dễ nhận thấy giữa chúng là các khung làm việc cung cấp một bộ rộng hơn các dịch vụ so với các thành phần phần mềm Chúng có khả năng tùy biến nhiều hơn, có các giao diện phức tạp hơn và điều quan trọng hơn là chúng thực sự

Trang 13

định nghĩa cho một họ ứng dụng hoặc một diện rộng của các ứng dụng Do vậy, các khung làm việc là khó học hơn đối với các nhà phát triển, nhưng một khi đã hiểu được hết khung làm việc thì sẽ có được sự linh động cao hơn và với một khung làm việc được thiết kế tốt thì có thể giảm được các nỗ lực cần bỏ ra để xây dựng một ứng dụng

đã được tùy biến rõ rệt hơn

1.1.4 Các đặc điểm của khung làm việc

Một khung làm việc hướng đối tượng có bốn đặc điểm chính [1] sau :

Khả năng môđun hóa

Khả năng sử dụng lại

Khả năng mở rộng

Sự đổi chiều của điều khiển

Về đặc điểm thứ nhất, các khung làm việc tăng cường khả năng môđun hóa bằng cách đóng gói các chi tiết thực hiện không chắc chắn đằng sau các giao diện chắc chắn Khả năng này giúp cho việc tăng cường chất lượng của phần mềm bằng cách cục

bộ hóa các tác động của những thay đổi về kiến trúc và sự thực hiện Sự cục bộ hóa này giảm các nỗ lực được yêu cầu để hiểu và duy trì phần mềm hiện có

Mặt khác, các giao diện chắc chắn được cung cấp bởi các khung làm việc còn tăng cường khả năng sử dụng lại bằng cách định nghĩa các thành phần chung mà có thể được áp dụng để tạo ra các ứng dụng mới Khả năng sử dụng lại của khung làm việc thúc đẩy kiến thức của miền ứng dụng và ưu tiên nỗ lực của các nhà phát triển kinh nghiệm để tránh việc tạo và làm hợp lệ lại các giải pháp chung cho các yêu cầu của ứng dụng lặp lại và các thách thức trong thiết kế phần mềm Việc sử dụng lại các thành phần thiết kế có thể là một sự cải tiến đáng kể trong sản xuất chương trình, cũng như tốt cho việc nâng cao chất lượng, tính hiệu quả, độ tin cậy và tính sẵn sàng của phần mềm

Về khả năng mở rộng, một khung làm việc tăng cường khả năng mở rộng bằng cách cung cấp các điểm nóng tường minh mà cho phép các ứng dụng mở rộng các giao diện chắc chắn và cách ứng xử của vùng ứng dụng với các sự thay đổi được yêu cầu bởi các trường hợp của ứng dụng trong một ngữ cảnh cụ thể Khả năng mở rộng của khung làm việc là cần thiết để đảm bảo các sự điều chỉnh có tính thời gian của các dịch

vụ và tính năng ứng dụng mới

Cuối cùng, đặc điểm của kiến trúc thời gian chạy của một khung làm việc là sự đổi chiều của điều khiển, thường được gọi là “Nguyên tắc Hollywood”- Đừng gọi cho chúng tôi, chúng tôi sẽ gọi cho bạn Kiến trúc này cho phép ứng dụng hợp với các quy tắc tiêu chuẩn bằng cách điều chỉnh từng bước xử lý, bằng các đối tượng quản lý sự kiện mà được viện dẫn thông qua cơ chế gửi kích họat lại của khung làm việc Khi các

Trang 14

sự kiện xảy ra, khung làm việc gửi lại kích hoạt bằng cách viện dẫn phương pháp móc nối trên các đối tượng quản lý sự kiện đã được đăng ký trước, cái mà thực hiện việc xử

lý ứng dụng cụ thể trên các sự kiện Đổi chiều điều khiển cho phép khung làm việc định nghĩa một tập các phương pháp ứng dụng cụ thể để đáp ứng với các sự kiện ở bên ngoài

1.2 Phân loại khung làm việc

Khung làm việc hướng đối tượng có thể được phân loại theo nhiều chiều khác nhau, trong đó những chiều quan trọng nhất là vùng vấn đề mà khung làm việc trỏ tới, cấu trúc bên trong của khung làm việc và việc nó dự định sử dụng như thế nào

Với cách phân loại thứ nhất, người ta chia các khung làm việc thành các khung

làm việc ứng dụng, các khung làm việc miền ứng dụng và các khung làm việc trợ giúp

Với phân loại theo cách thức dự định sử dụng, các khung làm việc chia thành các khung làm việc hộp đen, các khung làm việc hộp trắng [6] và các khung làm việc hộp xám

1.2.1 Phân loại khung làm việc theo vùng vấn đề

Việc phân loại theo vùng vấn đề chia các khung làm việc thành ba loại [4] là các khung làm việc ứng dụng, các khung làm việc miền ứng dụng và các khung làm việc hỗ trợ

Một khung làm việc ứng dụng là một tập của các thành phần với một thiết kế ứng dụng có thể được sử dụng lại Điều này có nghĩa rằng, người dùng không những nhận được một tập con mã chức năng mà còn bắt đầu với cả một thiết kế về cách mà chúng làm việc như thế nào Điều này cũng có nghĩa là, một khung làm việc ứng dụng

có thể cung cấp nhiều tính năng hơn các thư viện hàm, vì về cơ bản các thư viện hàm

là không phụ thuộc vào nhau

Loại thứ hai là phân loại khung làm việc theo vùng vấn đề của một miền ứng dụng Các khung làm việc này đạt được kiến thức và sự tinh thông trong một vùng vấn

đề cụ thể

Loại cuối cùng theo cách phân loại này là các khung làm việc hỗ trợ Các khung làm việc hỗ trợ là các khung làm việc mà phục vụ cho các dịch vụ mức thấp của hệ thống như các trình điều khiển cho các thiết bị và bộ điều khiển truy nhập tệp tin Nhà phát triển ứng dụng sử dụng các khung làm việc hỗ trợ trực tiếp hoặc sử dụng các sự điều chỉnh được tạo ra bởi các trình cung cấp của hệ thống Các khung làm việc hỗ trợ

có thể được tùy biến, ví dụ khi phát triển một hệ thống mới hoặc trình điều khiển thiết

bị mới

Trang 15

1.2.2 Phân loại khung làm việc theo cấu trúc nội bộ

Nếu như cấu trúc nội tại của khung làm việc được miêu tả thì nó có thể làm cho việc hiểu cách ứng xử của khung làm việc dễ dàng hơn Cấu trúc nội tại của một khung làm việc liên quan tới các khái niệm về các kiến trúc phần mềm Những kiến trúc này được gọi là “các khung làm việc kiến trúc”, do chúng được thiết kế theo cách

để đạt được cấu trúc chính của một kiến trúc phần mềm hướng đối tượng Nguyên tắc tổng thể cho cấu trúc nội tại của một khung làm việc được mô tả bởi khung làm việc

có tính kiến trúc của nó Các khung làm việc có tính kiến trúc đã được mô tả [1] là:

Layered (Phân tầng), giúp cho cấu trúc các ứng dụng có thể được phân rã thành

các nhóm của các công việc con với mức trừu tượng khác nhau định vị ở tầng khác nhau

Pipes and Filters (Ống và bộ lọc), có thể được dùng để cấu trúc các ứng dụng

mà có thể được chia thành một vài các công việc con hoàn toàn độc lập, được thực hiện theo trình tự nối tiếp hoặc song song đã được xác định một cách rõ ràng

Model-View-Controller (MVC), định nghĩa một kiến trúc cho các ứng dụng có

tính tương tác, chia tách giữa giao diện của ứng dụng với các chức năng chủ yếu của

Presentation-Abstraction-Controller (Trình diễn-Trừu tượng-Điều khiển), kiến

trúc này là thích hợp để cấu trúc các hệ thống phần mềm mà có tính tương tác cao với người sử dụng, cho phép những điều khiển và trình bầy của các mô hình trừu tượng của hệ thống có thể được tạo bên ngoài các chức năng con và độc lập với mỗi cái khác

Reflective (Phản ánh), có khả năng áp dụng cho các ứng dụng mà cần phải cân

nhắc về một sự thích nghi trong tương lai do sự thay đổi môi trường, công nghệ và các yêu cầu, mà không cần có phải thay đổi về kiến trúc và cách thực hiện của nó

Microkernel, là phù hợp cho các hệ thống phần mềm cần cung cấp các khung

nhìn khác nhau dựa trên các chức năng của chúng và phải thích nghi với các yêu cầu của hệ thống Ví dụ của microkernel là các hệ điều hành

Blackboard (bảng đen), giúp để cấu trúc các ứng dụng phức tạp mà liên quan

tới một vài hệ thống con chuyên biệt cho các lĩnh vực khác nhau Các hệ thống con này phải hợp tác để xây dựng các giải pháp cho việc giải quyết các vấn đề

Broker (môi giới), cấu trúc các hệ thống phần mềm phân tán, trong đó các thành

phần tương tác khác nhau giao tiếp với nhau khi vận hành thông qua truyền thông như trong một mô hình chủ khách

Việc sử dụng các kiến trúc này như là một nguyên tắc thiết kế chủ yếu cho một khung làm việc Điều đó có nghĩa là, các kiến trúc này là các ứng cử viên tốt cho việc

Trang 16

ứng dụng các mẫu thiết kế hướng đối tượng cũng như cho việc phát triển khung làm việc

1.3 Các qui trình phát triển khung làm việc

Quá trình phát triển một khung làm việc phụ thuộc vào kinh nghiệm của việc tổ chức trong miền vấn đề mà khung làm việc chỉ ra Tổ chức có nhiều kinh nghiệm hơn

có thể lựa chọn quy trình phát triển hiện đại hơn vì họ sẽ có ít vấn đề hơn với miền vấn

đề Một số quy trình khả thi cho việc phát triển khung làm việc đã được đưa ra:

1.3.1 Quy trình phát triển dựa trên các ứng dụng kinh nghiệm

Hướng phát triển khung làm việc mang tính thực dụng được miêu tả: Trước hết phát triển n ứng dụng, ít nhất từ hai ứng dụng trong tên miền vấn đề Khi chúng làm việc đúng thì việc lắp lại đầu tiên trong quy trình bắt đầu như hình 1.2 Phân loại các đặc điểm chung trong cả hai ứng dụng và kiết xuất chúng thành một khung làm việc

Để đánh giá liệu các đặc điểm được kiết xuất ra có đúng không, phát triển lại các ứng dụng (n) dựa trên khung làm việc đó Điều này có lẽ khá dễ dàng nếu các đặc tính chung được phân loại đúng Nếu việc phát triển lại các ứng dụng không dễ dàng thì việc viết lại khung làm việc là cần thiết và sử dụng kinh nghiệm đã có để phát triển bản tiếp theo của khung làm việc Đây là lần lặp thứ hai và tất cả các lần lặp tiếp theo cho ở trong hình 1.2 Dựa trên phiên bản mới của khung làm việc, các ứng dụng mới

có thể được phát triển Các kinh nghiệm đạt được thông qua các ứng dụng mới cũng

được sử dụng như là đầu vào cho việc bảo trì khung làm việc theo tiến độ Toàn bộ quy trình được thể hiện trong hình 1.2

Hình 1.2 Quy trình phát triển khung dựa trên kinh nghiệm về ứng dụng [8]

Phát triển ứng dụng

Sự phát triển đầu tiên của n ứng dụng

1 Tái phát triển n ứng dụng sử dụng khung làm việc 2.Phát triển n+1, n+2, … ứng dụng sử dụng khung làm việc

1 Các thành phần chung

2 Kinh nghiệm

Phát triển khung làm việc

Bảo trì các hoạt động dựa trên kinh nghiệm

1 Tái phát triển n ứng dụng sử dụng khung làm việc 2 Phát triển n+1, n+2, … ứng dụng sử dụng khung làm việc

Trang 17

1.3.2 Quy trình phát triển dựa trên phân tích vấn đề miền

Một hướng tiếp cận phức tạp hơn cho việc phát triển một khung làm việc là phân tích miền vấn đề Quy trình phát triển được chỉ ra trong hình 1.3 Hoạt động đầu tiên đó là phân tích miền vấn đề để phân loại và hiểu các thành phần trìu tượng (abstraction) nổi bật trong miền vấn đề Phân tích tên miền đòi hỏi phân tích các ứng dụng hiện có (đây là một nhiệm vụ khó thực hiện) và chỉ có thể nếu tổ chức có các ứng dụng được phát triển trong miền vấn đề Việc phân tích các ứng dụng hiện có cũng sẽ chiếm một tỷ lệ lớn ngân sách

Hình 1.3 Quy trình phát triển khung làm việc dựa trên phân tích miền vấn đề [8]

Sau khi các lớp trìu tượng được nhận biết, phát triển khung làm việc cùng với một ứng dụng kiểm tra, (sử dụng mũi tên như trong hình 1.3), sau đó điều chỉnh khung làm việc nếu cần thiết Tiếp theo, phát triển một ứng dụng thứ hai dựa trên khung làm việc đó Thay đổi khung làm việc nếu cần thiết và sửa đổi ứng dụng đầu tiên do đó nó làm việc với những thay đổi đưa ra trong khung làm việc Hãy để khung làm việc liên quan, thông qua các hoạt động bảo trì có kế hoạch, trong khi đó phát triển thêm nhiều ứng dụng dựa trên khung làm việc

1.3.3 Quy trình phát triển sử dụng các mẫu thiết kế

Quy trình phát triển một khung làm việc dựa trên mẫu thiết kế thực dụng có thể được nhận ra như chỉ rõ trong hình 1.4 Trước hết, phát triển một ứng dụng trong tên miền vấn đề Thứ hai, thiết lập và đào tạo nhân viên theo bộ chuẩn của các mẫu thiết

Trang 18

kế Lấy ứng dụng và áp dụng theo hệ thống mẫu thiết kế để tạo ra khung làm việc Sau

đó lặp lại giữa phát triển ứng dụng và khung làm việc có thể xảy ra Đồng thời trong quy trình này cũng tồn tại các hoạt động bảo trì khung làm việc theo kế hoạch

Hình 1.4 Quy trình phát triển khung làm việc sử dụng các mẫu thiết kế [8]

1.3.4 Quy trình phát triển khung làm việc chung

Các yếu tố chung của quy trình phát triển đƣợc chỉ ra trong hình 1.5:

– Phân tích miền vấn đề Điều này đƣợc thực hiện một cách hệ thống hoặc thông qua phát triển một hoặc một vài ứng dụng trong tên miền và lớp trìu tƣợng chính (key abstraction) đƣợc nhận ra

– Phiên bản đầu tiên của khung làm việc đƣợc phát triển nhằm tận dụng các lớp trìu tƣợng chính (key abstraction) đƣợc tìm thấy

– Một hoặc có thể một vài các ứng dụng đƣợc phát triển dựa trên khung làm việc Đây là hoạt động kiểm tra của khung làm việc Việc kiểm tra một khung làm việc để xem liệu nó có thể tái sử dụng hay không là hoạt động giống nhau nhƣ phát triển một ứng dụng dựa trên khung làm việc

Trang 19

– Các vấn đề khi sử dụng khung làm việc trong việc tạo ra các ứng dụng đều có

và được giải quyết trong phiên bản tiếp theo của khung làm việc

– Sau khi lặp lại chu kỳ này một số lần, khung làm việc sẽ đạt được một cấp độ chin muồi có thể chấp nhận được và có thể được đưa ra cho nhiều người dùng tái sử dụng trong tổ chức

Hình 1.5 Quy trình phát triển khung làm việc chung [8]

Trong thực tế, người ta không áp dụng mỗi phương pháp một cách riêng lẻ, mà thường kết hợp các ý tưởng của các phương pháp trên, tùy thuộc vào lớp các bài toán

cụ thể và những khả năng có được để đưa ra một cách làm phù hợp và hiệu quả

1.4 Phương pháp phát triển khung làm việc

Có một vài điểm khác nhau giữa việc phát triển khung làm việc và phát triển một ứng dụng chuẩn bình thường Trong đó điểm khác nhau quan trọng và đáng chú ý nhất

là cần phải xây dựng khung làm việc sao cho có thể bao gồm các khái niệm xác đáng trong một miền ứng dụng

Trang 20

Hình 1.6 dưới đây cho ta thấy rõ quá trình phát triển khung làm việc [1]:

Phân tích miền ứng dụng : đây là giai đoạn chuẩn bị

Thu thập các yêu cầu phân tích: phân tích để xác định yêu cầu

Thiết kế khung làm việc: thiết kế kiến trúc các thành phần của một khung làm

việc

Triển khai khung làm việc: triển khai các thành phần của thiết kế

Kiểm thử: kiểm thử khung làm việc đánh giá sự đáp ứng yêu cầu của nó

Hình 1.6 Quá trình phát triển khung làm việc [1]

1.4.1 Chuẩn bị cho việc phát triển khung làm việc

Phân tích sơ qua về miền ứng dụng sẽ giúp ta có thêm kiến thức về miền ứng dụng của khung làm việc nhằm xây dựng một khung làm việc Việc phân tích này như

sự khởi đầu cho quá trình phát triển khung làm việc Công việc của nó chính là nhận ra phần lõi của các lớp và các đối tượng chung cho các ứng dụng trong miền được phân

Trang 21

tích đó Mô hình miền chính là công cụ hỗ trợ đắc lực giúp phát triển một khung nhìn logic của hệ thống, nó cần tập trung vào các chế tác chính chứ không phải các chi tiết Đồng thời cũng phải mô tả những khái niệm hay được sử dụng Kết quả của việc phân tích miền ứng dụng chính là công cụ giao tiếp tới việc phát triển hệ thống giữa những người liên quan Trong giai đoạn này, cần tránh đưa ra các chi tiết thiết kế quá sớm, đồng thời cũng không nên mô tả lĩnh vực từ góc nhìn của nhà phát triển vì điều đó sẽ làm phát sinh các rủi ro, khiến cho việc trao đổi bị khó khăn

Nếu xác định được rõ các ca sử dụng thì sẽ giúp rất nhiều cho việc phân tích miền ứng dụng Nên có ít nhất hai tài liệu là kết quả khi phân tích miền ứng dụng, đó

là phạm vi của miền ứng dụng và mô hình tĩnh, chúng chứa các đối tượng và lớp quan trọng trong miền này Rất khó để xác định phạm vi của miền ứng dụng và việc phát triển một khung làm việc cho một vùng hẹp thì bao giờ cũng dễ hơn cho một lĩnh vực nên cần phải có đủ thời gian

Mô hình tĩnh nên chứa các đối tượng và các lớp quan trọng nhất của miền ứng dụng Đó là các đối tượng trong thế giới thực hay các đối tượng từ thế giới của ứng dụng này Để giúp cho việc giao tiếp giữa các nhà phát triển và người dùng trong tương lai thì nên đặt tên các lớp và các đối tượng theo cách hiểu của người dùng

1.4.2 Thu thập yêu cầu và phân tích

Thu thập yêu cầu và phân tích nhằm mục đích tập trung tất cả các yêu cầu hợp

lệ về miền ứng dụng và đưa ra ý tưởng sơ bộ về một hệ thống có thể đáp ứng đầy đủ

các yêu cầu này Pha này gồm hai hoạt động chính là thu thập yêu cầu và phân tích

Hai hoạt động này cần được thực hiện song song vì chúng có sự liên kết chặt chẽ với

nhau Kết quả của pha này là mô hình yêu cầu và mô hình phân tích Mô hình yêu cầu

xác định các yêu cầu mà hệ thống phải đáp ứng và mô hình phân tích sẽ phác thảo các khái niệm chính của hệ thống này

Đầu vào cho pha phân tích gồm một phân tích miền ứng dụng và danh sách các yêu cầu Cần có ít nhất hai ứng dụng cùng với các yêu cầu cho tương lai của khung làm việc Các điểm chung sẽ dễ tìm ra hơn nếu các yêu cầu của khung làm việc được cung cấp trên một cặp ứng dụng

Trang 22

Hình 1.7 Các quá trình con và sản phẩm của pha Thu thập yêu cầu và Phân tích [1]

1.4.2.1 Thu thập yêu cầu

Khái niệm về yêu cầu

Thu thập yêu cầu nhằm tìm ra các yêu cầu của hệ thống định phát triển Qua quá trình thu thập các yêu cầu sẽ đƣa ra đƣợc danh mục các yêu cầu cơ bản Thu thấp yêu cầu giúp đƣa ra đặc tả yêu cầu chi tiết và mô hình ca sử dụng Hai mô hình này kết hợp

để tạo nên mô hình yêu cầu Các mô hình yêu cầu này cũng là một định dạng cơ sở cho giai đoạn kiểm thử và thẩm định

Các mô hình yêu cầu này cũng là một định dạng cơ sở cho pha kiểm thử và thẩm định Ngoài hai tài liệu đƣợc đề xuất này, các tài liệu khác có thể đƣợc thêm vào trong

Mô hình yêu cầu

Các yêu cầu đƣợc chia thành hai nhóm: các yêu cầu của khung làm việc và các yêu cầu của ứng dụng cụ thể Sau đó chúng tiếp tục đƣợc chia thành các yêu cầu chức năng và các yêu cầu phi chức năng Việc phân chia các yêu cầu nhƣ vậy sẽ làm cho

Trang 23

việc nhận dạng các thuộc tính và các điểm chung trong các yêu cầu của các ứng dụng nhanh hơn

Hình 1.8 Sự phân chia các yêu cầu [1]

Các yêu cầu chức năng xác định các chức năng và dịch vụ mà hệ thống sẽ cung cấp Các yêu cầu phi chức năng xác định các ràng buộc mà hệ thống phải tuân theo khi phát triển và hoạt động

Có ba lớp khác nhau của các yêu cầu phi chức năng:

Các yêu cầu về sản phẩm, như tính hiệu quả, kích thước và tính khả chuyển

Các yêu cầu về quá trình phát triển, như các chuẩn, các quy ước về đặt tên,

Các yêu cầu từ bên ngoài, các chức năng bao trùm tất cả các yêu cầu phi chức

năng khác như các yêu cầu về chi phí, các yêu cầu từ các hệ thống khác và các yêu cầu không thể được đưa vào hai nhóm kể trên

Trang 24

Các yêu cầu phi chức năng của một khung làm việc nói chung là khác so với của các ứng dụng Chúng hướng vào thiết kế nhiều hơn,vì người sử dụng chúng chính là những nhà phát triển ứng dụng

Mô hình ca sử dụng đặc tả yêu cầu

Một mô hình Ca sử dụng chứa các tác nhân và các ca sử dụng Một ca sử dụng định nghĩa cách mà hệ thống sẽ được sử dụng và cách thức mà nó đáp ứng lại một yêu cầu cụ thể Mỗi ca sử dụng là một cách cụ thể để sử dụng hệ thống

Các ca sử dụng cũng nên phân chia như các yêu cầu, thành các ứng xử chung và các ứng xử cụ thể Sự phân chia này làm cho nó dễ dàng để nhận dạng cái gì là chung giữa các ứng dụng khác nhau và ứng xử nào chỉ là riêng của mỗi ứng dụng

Các yêu cầu chức năng nếu có thể nên được định dạng bằng các ca sử dụng Các

ca sử dụng sẽ hữu dụng hơn cho việc tìm các điểm chung giữa các ứng dụng, các ứng

xử chung mà nên được đưa vào trong khung làm việc

Ngoài ra, mô hình Ca sử dụng còn là một phương tiện trao đổi thông tin tốt giữa những người sử dụng và các nhà phát triển, bởi vì, chúng được trình bầy theo những khái niệm mà gần gũi với người sử dụng Một mô hình Ca sử dụng còn là một công cụ tốt cho việc tìm ra các điểm không nhất quán giữa các yêu cầu khác nhau Chúng còn

là cơ sở cho quá trình kiểm thử Mối quan hệ giữa mô hình Ca sử dụng và các mô hình khác của quá trình phát triển được mô tả ở hình 1.9

Hình 1.9 Mối quan hệ giữa mô hình Ca sử dụng và các mô hình khác [1]

Trang 25

1.4.2.2 Phân tích

Việc phân tích cần tập trung vào toàn bộ vấn đề mà không cần quan tâm đến môi trường thi hành nhằm mục đích phác thảo ra một mô hình của hệ thống mà đáp ứng đầy đủ các yêu cầu Mô hình phân tích bao gồm mô hình đối tượng tĩnh Giống như việc phân tích miền ứng dụng, mô hình phân tích được xây dựng từ các đối tượng thực Các đối tượng ở trong mô hình miền ứng dụng và mô hình phân tích nên được đặt tên giống nhau để đảm bảo dễ theo dõi và giảm thiểu các lỗi do hiểu nhầm

a Thực hiện việc phân tích

Việc lặp lại một cách tự nhiên chính là quy trình tạo ra mô hình phân tích Bằng cách làm mịn và tăng mức độ của việc chuẩn hóa giúp đạt được một mô hình phù hợp làm nền tảng cho giai đoạn thiết kế Một vài hoạt động thường thuộc về giai đoạn thiết

kế nhưng lại được hoàn thiện trước trong suốt giai đoạn phân tích nhằm tìm ra tất cả các lớp cũng như các mối quan hệ quan trọng trong mô hình phân tích Tình hình và vấn đề cần được phác thảo và mô tả từ quan điểm của người sử dụng Khi phác thảo được tình hình và vấn đề thì có thể nhận dạng các yếu tố trừu tượng và bắt đầu việc xây dựng mô hình phân tích

Quá trình phân tích nên gồm các bước sau:

 Phác thảo tình trạng và vấn đề

 Kiểm tra các giải pháp hiện có

 Nhận dạng các yếu tố trừu tượng chính

 Nhận dạng các yếu tố trừu tượng mức cao

 Nhận dạng những phần nào của vấn đề mà khung làm việc sẽ làm việc

 Yêu cầu đầu vào từ các khách hàng và thay đổi cách tiếp cận

Không cần thiết phải xóa bỏ các lớp từ mô hình miền ứng dụng trong quá trình làm mịn và nếu có thể thì nên đưa ra các lớp mới cần thiết với các yếu tố trừu tượng ở cấp cao hơn Điều đó làm tăng tính chung hóa của hệ thống Khi đưa ra các yếu tố trừu tượng ở cấp độ cao sẽ thấy được nhiều điểm tương đồng hơn giữa các ứng dụng Các điểm tương đồng đó sẽ được đưa vào trong khung làm việc

Tiếp đến là phân tích các kết cấu dữ liệu và các thuật toán, sau đó tổ chức các yếu tố trừu tượng Trước khi hình thành sơ đồ lớp có cấu trúc thì cần phải luôn luôn phân loại các đối tượng và các sự phụ thuộc Phân loại giải pháp nào là chung hoặc giải pháp nào là duy nhất đối với mỗi chương trình:

Trang 26

Có một vài đặc điểm chung đã được phân loại có thể được đưa vào trong khung làm việc để làm tăng tính chung của hệ thống theo yêu cầu sau này Các yếu tố trừu tượng có thể không tồn tại trong các ứng dụng đã được phát triển Tuy nhiên thật khó

để quyết định liệu tính chung hóa là có cần thiết hay không Một tính chung hóa sẽ làm tăng độ phức tạp và có thể làm tăng chi phí phát triển và chi phí tái sử dụng Do đó, cần phải cân nhắc giữa điểm chung và độ phức tạp của khung làm việc Các yếu tố trừu tượng ở cấp độ cao cần được đưa ra trong phạm vi miền của khung làm việc Các khung làm việc lớn cần được kết cấu thành các khung làm việc nhỏ hơn Nhìn chung các khung làm việc nhỏ thì tập trung hơn các khung làm việc lớn

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

Mục tiêu của mô hình này là mô tả các đối tượng, các quan hệ giữa các đối tượng

và các khái niệm khác của thế giới thực mà chúng là quan trọng đối với hệ thống định xây dựng Mô hình đối tượng tĩnh không nên chứa bất kỳ cấu trúc máy tính nào Mô hình đối tượng tĩnh nên được coi là tài liệu tham khảo không chỉ trong suốt quá trình phát triển mà còn ở cả giai đoạn bảo trì

Mô hình đối tượng tĩnh nên bao gồm các đối tượng phân tích và các liên kết giữa các đối tượng Các quan hệ kết hợp không phải là một điều quan trọng nhưng nếu chúng được tìm thấy thì nên đưa vào trong mô hình Việc phát triển một mô hình đối tượng tĩnh nên được thực hiện cho tất cả các ứng dụng Khi tìm thấy các sự trừu tượng chung, chúng nên được đưa vào trong mô hình đối tượng tĩnh của khung làm việc

1.4.2.3 Các kết quả và mô hình bổ sung

Đôi khi, không phải mỗi mô hình được giới thiệu ở trên là cần thiết, và có thể là không đủ Nếu các mô hình không bao trùm tất cả các yêu cầu hoặc các không làm nổi bật được các vấn đề quan trọng, thì thường sử dụng một sối mô hình bổ sung Trong trường hợp này, các mô hình đồ họa là tốt nhất

1.4.3 Thiết kế khung làm việc

Pha thiết kế khung làm việc bao gồm thiết kế kiến trúc, mà ở đó xác định các đối tượng và sự cộng tác giữa chúng, và thiết kế chi tiết, mà ở đó các lớp và các

phương thức của nó được mô tả chi tiết hơn Đầu ra từ pha thiết kế là một mô hình đối tượng tĩnh và các mô hình động mô tả các sự cộng tác Các mô hình này nên tạo thành một nền tảng đầy đủ cho sự thực hiện hệ thống

Trang 27

1.4.3.1 Quá trình thiết kế

Một thiết kế khung làm việc sẽ cung cấp các chức năng chung và trừu tượng đã được nhận dạng trong việc phân tích Nó là sự thực hiện các phần chung của các ứng dụng trong miền ứng dụng

Hình 1.10 Khung làm việc là phần chung của các ứng dụng trong một miền [1] Hình 1.10 là tiến trình của pha thiết kế, trong đó các thiết kế được đánh giá liên tục và các giải pháp thiết kế đề xuất có thể được kiểm chứng bằng các mẫu Trong pha thiết kế kiến trúc, đối tượng và các sự cộng tác của chúng sẽ được thay đổi, khi cân nhắc tới môi trường thực hiện Còn trong pha thiết kế chi tiết, các đối tượng được nhận dạng trong pha thiết kế kiến trúc sẽ được mô tả theo ngôn ngữ dự định dùng được để thực hiện khung làm việc và nếu cần thiết, các đối tượng đó sẽ được làm mịn Tiến trình của pha thiết kế được chỉ ra trong hình 1.10.; Trong đó, các thiết kế được đánh giá liên tục và các giải pháp thiết kế đề xuất có thể được kiểm chứng bằng cách làm mẫu

Ứng dụng 3

Trang 28

Hình 1.11 Các hoạt động trong pha thiết kế khung làm việc [7]

Trong thực tế, bằng cách nghiên cứu các ví dụ cụ thể có thể tìm ra các yếu tố rừu tượng của thiết kế được tìm từ “dưới lên” Thiết kế nên là một tổng quan trong đầu của các nhà thiết kế, một thiết kế mẫu hoặc một ứng dụng cũ trong đó vấn đề thiết kế tương tự đã được giải quyết

Ngoài việc tìm ra các trừu tượng, trong pha này còn phải nhận dạng các giải pháp thiết kế chung Một giải pháp thiết kế chung không chỉ giải quyết vấn đề hiện tại

mà còn sử dụng được với những vấn đề tương tự Các mẫu thiết kế là các giải pháp chung cho các vấn đề mà thường xảy ra trong thiết kế khung làm việc Các mẫu thiết

kế không những giúp cho việc trao đổi giữa các nhóm thiết kế mà còn làm cho khung làm việc được hiểu dễ dàng hơn

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

Khi thiết kế kiến trúc, một mô tả mức cao của khung làm việc và các ứng dụng được đưa ra dựa trên các mô hình phân tích Các hoạt động trong hình 1.12 là chung cho thiết kế kiến trúc trong hầu hết các phương pháp hướng đối tượng Mục tiêu của thiết kế kiến trúc là để nhận dạng các đối tượng cần có để thực hiện hệ thống và cách

mà chúng cộng tác với nhau Trong pha này, nếu cần thiết, hệ thống sẽ được chia thành các hệ thống con

Trang 29

Hình 1.12 Các hoạt động trong pha thiết kế kiến trúc [1]

Các yêu cầu và các mô hình phân tích chính là đầu vào của pha thiết kế kiến trúc, trong khi đó đầu ra của nó là các mô hình theo dạng của mô hình đối tượng tĩnh hoặc các mô hình động (các biểu đồ trạng thái, các lược đồ tương tác và các mô hình luồng

dữ liệu) Các mô hình này sẽ là cơ sở cho việc nhận dạng cách thực hiện bằng các lớp

a Làm mịn mô hình đối tượng phân tích

Trong bước làm mịn mô hình đối tượng phân tích, các đối tượng mới có thể được đưa ra để điều chỉnh hệ thống trong suốt quá trình phát triển Cần thực hiện song song phân tích môi trường thực hiện với pha phân tích, hoặc ít nhất phân tích môi trường thực hiện trước khi bắt đầu pha thiết kế Các thay đổi khác có thể là loại bỏ, chia tách hoặc sát nhập các đối tượng nhận được từ sự phân tích Cần phải kiểm soát các thay đổi đó vì chúng thường có xu hướng làm giảm sức mạnh của hệ thống do kiến trúc bị thay đổi

b Gán các trách nhiệm hệ thống tới các đối tượng cụ thể

Trách nhiệm của một đối tượng hoặc một hệ thống được định nghĩa như là “kiến thức để duy trì và các hoạt động mà nó có thể được thực hiện” Trong hệ thống, trách nhiệm sẽ được phân phối cho các đối tượng đã được nhận dạng trong các pha sớm hơn

Các trách nhiệm nên được đặt tại lớp mà về lôgíc lớp có trách nhiệm này Trong một số trường hợp, khó biết một trách nhiệm thuộc về một lớp nào Sau đó, người thiết

kế nên hướng tới mức cao nhất của sự trừu tượng Nếu một trách nhiệm có thể thuộc

Trang 30

về một vài lớp từ quan điểm được lôgic, thì trách nhiệm này nên đặt trong lớp ở mức

trừu tượng cao hơn

c Phân tích các sự cộng tác

Khi một đối tượng cần đến một hoặc nhiều các tác vụ của các đối tượng khác để

thực hiện đầy đủ chức năng của mình thì nó sẽ công tác với một đối tượng khác đó

Đối với mỗi đối tượng và mỗi trách nhiệm, sự cộng tác được tìm ra nếu như trách

nhiệm này chỉ có thể được đáp ứng đầy đủ nếu có sự cộng tác với các đối tượng khác

Hình 1.13 Nguyên tắc định nghĩa sự cộng tác giữa các lớp trừu tượng [1]

d.Làm mịn các cấu trúc thừa kế và các sự cộng tác

Hoạt động làm mịn được thực hiện trong suốt quá trình thiết kế Các sự trừu

tượng không được xác định nghĩa một lần, các nhà thiết kế hầu như chắc chắn phải lặp

lại thông qua các hoạt động trước

Một sự quan tâm chính khi làm mịn các cấu trúc phân cấp và các sự cộng tác nên

giữa các chức năng chung và các trừu tượng đã được nhận dạng trong sự phân tích Sự

làm mịn sâu hơn không nên vi phạm các trừu tượng có tính khái niệm này

Một cách để bắt đầu sự làm mịn là tìm các siêu lớp mà thực hiện cùng một tác vụ

và cố gắng chuyển tác vụ này vào một siêu lớp mới Bất kỳ khi nào, sự thừa kế nên

được thay thế bằng tổ hợp

Các nhà thiết kế nên tìm các lớp hoặc các tác vụ mà có các tên khác nhau, nhưng

cung cấp cùng chức năng Đặt tên lại cho chúng là một cách đơn giản có thể chấp nhận

được, và sẽ làm dễ dàng hơn nhận ra các điểm chung

Trang 31

Nếu có các tác vụ hoặc các lớp mà cung cấp các chức năng gần giống nhau, thì

có thể sử dụng tham số cho chúng Các lớp tương tự trong các ứng dụng khác có thể được thay thế bởi một lớp chung trong khung làm việc Lớp này sẽ sử dụng việc truyền các tham số khác nhau, tùy thuộc vào ứng dụng sử dụng lớp này

1.4.3.3 Thiết kế chi tiết

Trong pha thiết kế chi tiết, tất cả các lớp với các thuộc tính và các tác vụ được nhận dạng và được mô tả, khi sử dụng ngôn ngữ thực hiện dự định Đầu vào là các đối tượng và các sự cộng tác được nhận dạng trong thiết kế kiến trúc, đã mô tả trong mô hình đối tượng tĩnh và các mô hình động, ví dụ các lược đồ tương tác và các biểu đồ chuyển dịch trạng thái

Một tác vụ nên thực hiện nhiều hơn một nhiệm vụ Một tác vụ mà thực hiện nhiều nhiệm vụ khác nhau nên được chia thành một vài tác vụ Các lớp có nhiều hơn

25 tác vụ [1] mô tả các sự trừu tượng phức tạp, và có thể chứa một vài các trừu tượng khác Các sự trừu tượng này nên có lớp của bản thân nó Các sự trừu tượng có thể được đưa ra từ các mô hình mà chúng thuộc về, để duy trì cấu trúc của tài liệu Các sự trừu tượng mang tính khái niệm thuộc về sự phân tích

Để nhận dạng được các lớp sâu hơn, các ký hiệu tác vụ nên là thống nhất, tính chất đồng dạng nên được chú trọng hơn là tính cụ thể

1.4.4 Triển khai khung làm việc

Nội dung chính của pha này là sử dụng một ngôn ngữ lập trình hướng đối tượng

cụ thể, như C#, C++, Java, … để triển khai các thiết kế đã được tạo ra trong giai đoạn thiết kế Việc triển khai này liên quan chặt chẽ đến các yêu cầu của khung làm việc và ngôn ngữ thực hiện dự định Khi triển khai một khung làm việc, một cách tiếp cận từ trên xuống nên là cách phù hợp nhất, bắt đầu từ các lớp mức cao Các phát triển này thực hiện chức năng chung của các ứng dụng và tiếp tục thực hiện các đối tượng mức thấp

Tiếp sau pha thiết kế chi tiết, tất cả các lớp với các thuộc tính và phương pháp được xác định khi sử dụng ngôn ngữ được dự kiến Tuy nhiên, không có ranh giới rõ ràng giữa thiết kế chi tiết, triển khai và kiểm thử, bởi vì các sự không nhất quán sẽ được phát hiện trong khi triển khai và sẽ được phản hồi lại pha thiết kế chi tiết Các thành phần thậm chí còn được kiểm tra trong suốt pha triển khai

Các quy ước tiêu chuẩn về thực hiện nên được định nghĩa hoặc được sử dụng lại Các quy ước này bao gồm xác định các cấu trúc file, các quy ước đặt tên và các quy

Ngày đăng: 25/03/2015, 09:41

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
1. Lã Ngọc Quang(2006), “Khung làm việc và ứng dụng trong việc xây dựng phần mềm”, luận văn thạc sỹ - Khoa Công Nghệ Thông Tin, Đại học Công Nghệ, ĐHQGHNTài liệu tiếng Anh Sách, tạp chí
Tiêu đề: Khung làm việc và ứng dụng trong việc xây dựng phần mềm”
Tác giả: Lã Ngọc Quang
Năm: 2006
2. Gabriela B. Arevalo (2001), “Architectural description of Object-Oriented Frameworks” Sách, tạp chí
Tiêu đề: Architectural description of Object-Oriented Frameworks
Tác giả: Gabriela B. Arevalo
Năm: 2001
3. J.van Gurp and J. Bosch (2001), “Design, implementation and evolution of object oriented frameworks: concept and guidelines”, University of Groningen Sách, tạp chí
Tiêu đề: Design, implementation and evolution of object oriented frameworks: concept and guidelines
Tác giả: J.van Gurp and J. Bosch
Năm: 2001
4. Fayad M. E., D. C. Schmidt, R. E. Johnson (1999), “Building Application Frameworks: Object-Oriented Foundations of Framework Design”, NY: John Wiley and Sons, New York Sách, tạp chí
Tiêu đề: Building Application Frameworks: Object-Oriented Foundations of Framework Design
Tác giả: Fayad M. E., D. C. Schmidt, R. E. Johnson
Năm: 1999
5. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissades (1994), “Design patterns: Elements of Reusable Object-Oriented Software”, Reading, MA:Addsion – Wesley Sách, tạp chí
Tiêu đề: Design patterns: Elements of Reusable Object-Oriented Software
Tác giả: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissades
Năm: 1994
6. Ralph E. Johnson, Brian Foote (1991), “Design Reusable Classes”, Journal of Object-Oriented Programming Sách, tạp chí
Tiêu đề: Design Reusable Classes
Tác giả: Ralph E. Johnson, Brian Foote
Năm: 1991
7. Niklas Landin, Axel Niklasson (1995), “Development of Object-Oriented Frameworks” , Lund University, Lund, Sweden Sách, tạp chí
Tiêu đề: Development of Object-Oriented Frameworks
Tác giả: Niklas Landin, Axel Niklasson
Năm: 1995
8. Michael Mattsson (1996), “Object-Oriented frameworks, A survey of methodological issues”, Lund, Sweden Sách, tạp chí
Tiêu đề: Object-Oriented frameworks, A survey of methodological issues
Tác giả: Michael Mattsson
Năm: 1996

HÌNH ẢNH LIÊN QUAN

Hình 1.6 dưới đây cho ta thấy rõ quá trình phát triển khung làm việc [1]: - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 1.6 dưới đây cho ta thấy rõ quá trình phát triển khung làm việc [1]: (Trang 20)
Hình 1.7. Các quá trình con và sản phẩm của pha Thu thập yêu cầu và Phân tích [1]. - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 1.7. Các quá trình con và sản phẩm của pha Thu thập yêu cầu và Phân tích [1] (Trang 22)
Hình 1.8. Sự phân chia các yêu cầu [1]. - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 1.8. Sự phân chia các yêu cầu [1] (Trang 23)
Hình 1.9. Mối quan hệ giữa mô hình Ca sử dụng và các mô hình khác [1]. - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 1.9. Mối quan hệ giữa mô hình Ca sử dụng và các mô hình khác [1] (Trang 24)
Hình 1.11. Các hoạt động trong pha thiết kế khung làm việc [7]. - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 1.11. Các hoạt động trong pha thiết kế khung làm việc [7] (Trang 28)
Hình 1.12. Các hoạt động trong pha thiết kế kiến trúc [1]. - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 1.12. Các hoạt động trong pha thiết kế kiến trúc [1] (Trang 29)
Hình 2.2. Biểu đồ hoạt động quá trình đầu tư cho sản xuất mía đường - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 2.2. Biểu đồ hoạt động quá trình đầu tư cho sản xuất mía đường (Trang 37)
Hình 2.3. Biểu đồ miền lĩnh vực đầu tƣ trồng mía - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 2.3. Biểu đồ miền lĩnh vực đầu tƣ trồng mía (Trang 39)
Hình 2.5. Biểu đồ miền lĩnh vực của bài toán đầu tƣ chăn nuôi bò - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 2.5. Biểu đồ miền lĩnh vực của bài toán đầu tƣ chăn nuôi bò (Trang 43)
Hình 2.6. Mô hình miền lĩnh vực cho lớp các bài toán đầu tƣ trong nông nghiệp - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 2.6. Mô hình miền lĩnh vực cho lớp các bài toán đầu tƣ trong nông nghiệp (Trang 47)
Hình 2.7. Biểu đồ lớp thiết kế khối lập dự án và ký hợp đồng - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 2.7. Biểu đồ lớp thiết kế khối lập dự án và ký hợp đồng (Trang 48)
Hình 2.10. Biểu đồ lớp thiết kế khối thanh lý hợp đồng - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 2.10. Biểu đồ lớp thiết kế khối thanh lý hợp đồng (Trang 50)
Hình 3.2. Biểu đồ lớp thiết kế khối lập triển khai thực hiện đầu tƣ bài toán trồng mía - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 3.2. Biểu đồ lớp thiết kế khối lập triển khai thực hiện đầu tƣ bài toán trồng mía (Trang 56)
Hình 3.3. Biểu đồ lớp thiết kế khối thu hoạch sản phẩm bài toán trồng mía - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 3.3. Biểu đồ lớp thiết kế khối thu hoạch sản phẩm bài toán trồng mía (Trang 56)
Hình 3.6. Chi tiết hợp đồng đầu tƣ trồng mía - framework và ứng dụng cho một lớp bài toán quản lý (2)
Hình 3.6. Chi tiết hợp đồng đầu tƣ trồng mía (Trang 59)

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

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