ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

---------------o0o-----------------

THỰC TẬP CHUYÊN NGÀNH

KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI

Sinh viên: Nguyễn Đức Trọng

MSV: DTC0851200034

Giáo viên hướng dẫn: ThS Ngô Thị Lan

Bộ môn: Công Nghệ Phần Mềm

Thái Nguyên 2012

1

ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

THỰC TẬP CHUYÊN NGÀNH

KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI

Sinh viên: Nguyễn Đức Trọng

MSV: DTC0851200034

Giáo viên hướng dẫn:ThS Ngô Thị Lan

Bộ môn: Công Nghệ Phần Mềm

2

MỤC LỤC

LỜI NÓI ĐẦU................................................................................................................5

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN............................................................7

TÓM TẮT NỘI DUNG..................................................................................................8

Chương I. TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM............................................9

I. Khái niệm kiến trúc phần mềm và vai trò của kiến trúc phần mềm.....................9

II. Các nhân tố đánh giá chất lượng kiến trúc phần mềm....................................10

1. Các nhân tốt chất lượng...............................................................................11

2. Hiệu năng.....................................................................................................11

3. Khả năng mở rộng.......................................................................................12

III. Quy trình thiết kế kiến trúc phần mềm............................................................16

1. Phác thảo quy trình......................................................................................16

2. Xác định yêu cầu kiến trúc..........................................................................17

3. Thiết kế kiến trúc.........................................................................................19

4. Chuẩn hóa....................................................................................................20

Chương II. KỸ THUẬT XÂY DỤNG TẦNG TRUNG GIAN (MIDLEWARE).......21

I. Giới thiệu............................................................................................................21

II. Phân loại các kĩ thuật xây dựng tầng trung gian.............................................22

III. Các đối tượng phân bổ....................................................................................23

IV. Message-Oriented Middleware.......................................................................25

V. Application Servers.........................................................................................28

Chương III. MỘT SỐ KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI....................................31

I. Kiến trúc phần mềm hướng dịch vụ (Service Oriented Architecture – SOA)....31

1. Kiến trúc hướng dịch vụ là gì ?...................................................................31

2. Bốn nguyên tắc chính của hệ thống SOA.........................................................32

3. Các tính chất của một hệ thống SOA...............................................................33

4. Lợi ích của SOA..............................................................................................39

5. Một số mô hình triển khai SOA....................................................................43

3

II. Kiến trúc phần mềm cho dòng sản phẩm phần mềm (Software Productline Architechture)...........................................................................................................44

1. Dòng sản phẩm phẩn mềm..........................................................................44

2. Kiến trúc phần mềm cho dòng sản phẩm phần mềm...................................45

III. Kiến trúc phần mềm hướng mô hình - Model driven architecture (MDA).....46

1. Kiến trúc phần mềm hướng mô hình (MDA) là gì?...................................46

2. Ưu điểm của MDA......................................................................................47

3. MDA và các yêu cầu phi chức năng trong kiến trúc hệ thống.....................47

Chương IV. THIẾT KẾ KIẾN TRÚC PHẦN MỀM VỚI NGÔN NGỮ UML...........49

1. Sự ra đời của UML..........................................................................................49

2. Mục đích của UML.........................................................................................49

3. Đặc điểm của UML.........................................................................................49

4. Các thành phần của UML...............................................................................50

Chương V. ỨNG DỤNG THIẾT KẾ WEBSITE BÁN HÀNG SỬ DỤNG UML......63

A. Bài toán................................................................................................................63

B. Phân tích...............................................................................................................63

I. Các tác nhân......................................................................................................63

II. Các chức năng chính (Use Case):................................................................64

III. Đặc tả ca sử dụng.........................................................................................65

IV. Các loại biểu đồ..............................................................................................68

KẾT LUẬN..................................................................................................................90

TÀI LIỆU THAM KHẢO............................................................................................91

4

LỜI NÓI ĐẦU

Trong tiến trình kĩ nghệ phần mềm hiện nay, xây dựng một kiến trúc phần mềm tối ưu luôn là một trong những vấn đề then chốt đước các tổ chức phát triển phần mềm lớn trên toàn thế giới quan tâm. Đó là lí do vì sao mà các hội thảo đình đám với các nội dung liên quan tới kiến trúc phần mềm được các tập đoàn công nghệ thông tin lớn trên thế giới như IBM, Microsoft… tổ chức ngày một nhiều hơn (Hội thảo kiến trúc hướng dịch vụ và quản lí dịch vụ - IBM, Hội thảo kiến trúc phần mềm và thiết bị di động – Microsoft…).

Theo nhiều chuyên gia đầu ngành về công nghệ thông tin ở Việt Nam, lĩnh vực sản xuất phần mềm ở nước ta đang gặp phải một thực trạng báo động đó là vấn đề thiết kế kiến trúc trong xây dựng, phát triển phần mềm chưa được các nhà phát triển phần mềm trong nước quan tâm đúng mức. Đó là một trong các lí do giải thích vì sao với lực lượng làm việc trong lĩnh vực đông đảo như hiện nay (khoảng 200.000 người và dự kiến sẽ tăng lên 600.000 người đến năm 2020) nhưng về cơ bản chúng ta vẫn chỉ là một nước gia công phần mềm và sản xuất phần mềm theo đơn đặt hàng, các phần mềm do chính chúng ta thiết kế và sản xuất vẫn chưa tao ra được chỗ đứng trên thị trường quốc tế. Các giáo viên luôn than phiền rằng sinh viên học trong ngành công nghệ phần mềm của chúng ta hiện nay hầu hết quan tâm tới lập trình hơn là thiết kế, trong khi lập trình là công việc có mức thu nhập cũng như được đánh giá ít nhất trong các dự án công nghệ thông tin.

Hiện nay hầu hết sinh viên công nghệ thông tin ở các trường đại học lớn trên thế giới đều được học các kiến thức liên quan tới kiến trúc phần mềm một cách bài bản và chuyên sâu. Tuy nhiên sinh viên công nghệ thông tin ở Việt Nam lại không được đào tạo nhiều về kiến trúc phần mềm, bằng chứng là hiện chúng ta gần như chưa có một tài liệu chuyên sâu nào về kiến trúc phần mềm viết bằng tiếng Việt(cả ebook cũng như giáo trình xuất bản thành sách).

Nhận thức được tầm quan trọng của kiến trúc phần mềm trong phát triển phần mềm, thực trạng ngành phần mềm ở Việt Nam hiện nay cũng như sự thiếu hụt các tài liệu chuyên môn trong lĩnh vực này chính là lí do thôi thúc em đề xuất và thực hiện đề tài này.

Đề tài “Kiến trúc phần mềm hiện đại” được thực hiện dưới sự hướng dẫn nhiệt tình của cô Ngô Thị Lan – bộ môn Công Nghệ Phần Mềm, cô đã giúp em trong xây dựng ý tưởng cho đề tài, phác thảo chi tiết nội dung đề tài, cung cấp các tài liệu hữu ích và hướng dẫn chi tiết các nội dung nghiên cứu. Ngoài ra em còn nhận được rất

5

nhiều sự giúp đỡ của các thầy cô khác trong bộ môn Công Nghệ Phần Mềm, em xin chân thành cảm ơn các thầy cô đã nhiệt tình giúp đỡ và giúp em hoàn thành đề tài. Đồng thời em rất mong nhận được sự đóng góp nhiệt tình của thầy cô và các bạn để đề tài này được hoàn thiện hơn nữa, giúp em tiếp tục phát triển đề tài này cho đợt thực tập tốt nghiệp sắp tới cũng như phục vụ cho công việc sau khi ra trường.

Em xin chân thành cảm ơn.

Sinh viên

Nguyễn Đức Trọng

6

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

7

…………………………………………………………………………………………

…………………………………………………………………………………………

……………………………………………………………………………………......

TÓM TẮT NỘI DUNG

Bản báo cáo được chia thành 5 chương với nội dung như sau:

- Chương 1: Các khái niệm cơ bản về kiến trúc phần mềm, bản chất, ý nghĩa của

kiến trúc phần mềm trong việc phát triển phần mềm, nguyên tắc tổng quan của

quy trình thiết kế kiến trúc, các yếu tố đánh giá chất lượng kiến trúc phần mềm.

- Chương 2: Một số xây dựng tần trung gian trong kiến trúc phần mềm.

- Chương 3: Các kiến trúc phần mềm hiện đại đang dành được sự chú ý hiện

nay: Một số kỹ thuật xây dựng tầng trung gian trong kiến trúc phần mềm

(Middleware), Kiến trúc phần mềm cho dòng sản phẩm phần mềm

(ProductLine), Kiến trúc phần mềm phát triển theo hướng mô hình (Model-

Driven Architecture) , Kiến trúc phần mềm phát triển theo hướng dịch vụ

(Service- Oriented Architecture)

- Chương 4: Tổng quan về ngôn ngữ UML và sử dụng UML trong thiết kế kiến

trúc phần mềm

- Chương 5: Xây dựng kiến trúc website bán điện thoại với UML

8

Chương I. TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM

I. Khái niệm kiến trúc phần mềm và vai trò của kiến trúc phần mềm

Kiến trúc phần mềm là một chuyên ngành bắt đầu từ những năm 70 của thế kỷ

trước. Với việc gia tăng độ phức tạp và áp lực về việc phát triển các hệ thống thời gian

thực phức tạp, kiến trúc phần mềm nổi lên như là một kiến trúc cơ sở của việc phát

triển phần mềm và công nghệ hệ thống chủ lực.

Như bất kỳ lĩnh vực nghiên cứu nào khác, kiến trúc phần mềm cũng có những

thách thức ban đầu của nó. Một kiến trúc phần mềm thể hiện các phương diện cấu trúc

và hành vi của một hệ thống, nó có thể được định nghĩa như sau:

“Kiến trúc phần mềm của một chương trình hoặc hệ thống tính toán là cấu trúc

hoặc các cấu trúc của hệ thống đó, gồm các thành phần của phần mềm, các thuộc tính

có thể trông thấy được từ bên ngoài của các thành phần này, và các mối quan hệ giữa

chúng.”

Ðịnh nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô (coarse-

grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ

phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the

architecture). Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số

nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ

phận kiến trúc cơ bản còn lại. Các chi tiết bên trong của sự thiết kế và cài đặt thành

phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần

mềm đặc biệt chỉ như một hộp đen. Hộp đen này có các thuộc tính nhất định mà nó

biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung

các đích nghiệp vụ hoặc công nghệ thông tin. Kiến trúc phần mềm xác định các khối

kiến trúc cơ bản, với một mức độ chi tiết thích hợp. Nó cũng xác định và viết tư liệu

việc các bộ phận cơ bản liên quan lẫn nhau như thế nào.

Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân

vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây dựng theo

kiểu lặp lại, gia tăng, và độc lập. Các bộ phận riêng lẻ có các mối quan hệ hiện với

nhau. Khi đan xen vào nhau, các bộ phận riêng lẻ đó tạo nên kiến trúc của hệ thống, tổ

chức, hoặc ứng dụng.

9

Có một số nhầm lẫn về sự khác nhau giữa kiến trúc với thiết kế. Tất cả các kiến

trúc là thiết kế nhưng không phải tất cả các thiết kế là kiến trúc. Các thiết kế mà cần

phải ràng buộc, về mặt hệ thống, để đáp ứng các nhu cầu chức năng và phi chức năng

và các mục tiêu của nó, là có tính kiến trúc về bản chất. Trong khi kiến trúc coi một bộ

phận kiến trúc cơ bản là một hộp đen, thì thiết kế xử lý cấu hình, tuỳ biến, và các công

việc bên trong của một bộ phận kiến trúc cơ bản. Kiến trúc ràng buộc một thành phần

phần mềm với các thuộc tính bên ngoài của nó. Thiết kế thường lỏng hơn nhiều so với

kiến trúc, vì nó cho phép nhiều cách gắn kết các thuộc tính bên ngoài của thành phần

này. Thiết kế cũng cân nhắc các cách khác nhau để thực hiện các chi tiết bên trong của

thành phần.

Kiến trúc phần mềm có thể được sử dụng một cách đệ quy. Hãy xem xét một thành

phần phần mềm (C1) mà là một bộ phận của một kiến trúc phần mềm của một hệ

thống. Kiến trúc sư phần mềm chuyển thành phần này đến nhà thiết kế hệ thống, cùng

với các thuộc tính của nó, các khả năng về chức năng và phi chức năng nó phải thể

hiện, và mối quan hệ của nó với các bộ phận phần mềm khác. Nhà thiết kế sau khi

phân tích thành phần phần mềm C1, quyết định nó sẽ được phân tích thành các thành

phần chi tiết hơn (C11, C12, và C13), mỗi cái cung cấp một chức năng có thể dùng lại

được mà sẽ được sử dụng để thực thi các thuộc tính đã gán cho C1. Nhà thiết kế chi

tiết hoá C11, C12, C13 và các giao diện của chúng.

Tại điểm này, đối với nhà thiết kế, C11, C12, và C13 là các bản dựng kiến trúc

(hoặc các thành phần); mỗi cái đều có các giao diện bên ngoài được xác định rõ ràng.

Ðối với nhà thiết kế, C11, C12, và C13 là kiến trúc của thành phần phần mềm C1, và

các bản dựng cần được soạn thảo và thiết kế công phu hơn nữa để nhằm đến các cài

đặt bên trong của chúng. Kiến trúc có thể được sử dụng một cách đệ quy bằng cách

phân chia hệ thống lớn, phức tạp thành các bộ phận nhỏ, và tập trung vào từng bộ

phận.

Kiến trúc ràng buộc hệ thống bằng cách sử dụng các bộ phận kiến trúc cơ bản mà

thoả mãn chung các mục tiêu hành vi và chất lượng. Các cổ đông phải có khả năng

hiểu được kiến trúc. Như vậy điều cốt yếu là một kiến trúc phải được viết tư liệu thoả

đáng, như được thảo luận trong phần kế tiếp.

II. Các nhân tố đánh giá chất lượng kiến trúc phần mềm

10

1. Các nhân tốt chất lượng

Các nhà thiết kế kiến trúc phần mềm dành hầu hết thời gian của mình cho việc thiết kế

ra các hệ thống đảm bảo tập các yêu cầu chất lượng của hệ thống. Các yêu cầu chất

lượng là một phần của các yêu cầu phi chức năng. Có 4 nhất tố chất lượng mà các nhà

thiết kế luôn hướng tới đó là:

- Khả năng mở rộng

- Tính bảo mật

- Hiệu năng

- Độ tin cậy

2. Hiệu năng

Yêu cầu hiệu năng chỉ ra một lượng xác định các công việc mà hệ thống cần phải

thực hiện trong khoảng thởi gian nào đó . Thông thường các ứng dụng cần có khả

năng xử lí hàng trăm, đôi khi là hàng ngàn hoặc vạn giao dịch (transaction) mỗi giây,

những yêu cầu này thường thấy trong các hệ thống lớn của các tổ chức, đặc biệt trong

các tổ chức tài chính, viễn thông và các chính phủ.

a. Throughput

Throughput là sự đo lường lượng công việc mà một ứng dụng phải thực hiện trong

một đơn vị thời gian. Nó thường được đo bằng số giao dịch mỗi giây (pts) hay số

thông điệp được xử lí mỗi giây (mps).

Ví dụ một ứng dụng online của ngân hàng phải đảm bảo nó có thể thực hiện được tối

thiểu 1000, giao dịch online mỗi giây (1000pts), hay một hệ thống quản lí bán hàng có

thể cần sử lí 50 thông điệp yêu cầu mua hàng từ các khách hàng mỗi giây (50mps).

b. Thời gian đáp ứng (Response time)

Thời gian đáp ứng chỉ ra độ trễ về thời gian khi ứng dụng sử lí một giao dịch. Thời

gian đáp ứng thường gắn liền với thời gian ứng dụng sử dụng để phản hội lại một đầu

vào nào đó. Thời gian đáp ứng càng ngắn hiệu quả làm việc của người dùng càng cao.

11

Một ví dụ tiêu biểu là ứng dụng hộ trợ việc bán hàng tại các cửa hàng lớn, với lượng

khách hàng đông, khi một sản phẩm được quét tại các quầy thanh toán, việc hệ thống

hiển thị giá của sản phẩm trong thời gian ngắn giúp cho việc phục vụ khách hàng

được nhanh hơn, đây là mong muốn của cả khác hàng và cửa hàng.

c. Thời hạn hoàn thành (Deadlines)

Các ứng dụng yêu cầu nghiêm ngặt về thời gian hoàn thành một yêu cầu người

dùng thường là các ứng dụng phục vụ các công việc liên quan tới phân phối sản phẩm

hàng hóa, thư tín, thực hiện các giao dịch tài chính…

Chẳng hạn một hệ thống thanh toán trực tuyến (paypal là một ví dụ tiêu biểu), khi

người sử dụng gửi tiền vào t ài khoản của mình, nó phải hoàn thành trong một thời

gian nhất định yêu cầu của người dùng. Nếu trong thời gian đó mà hệ thống không thể

thực hiện được yêu cầu của người dùng thì họ sẽ không thể thực hiện được các giao

dịch tài chính của mình và đây là một vấn đề không thể chấp nhận được.

3. Khả năng mở rộng

Một cách tổng quan, khả năng mở rộng cho chúng ta biết một thiết kế sẽ ứng phó

thế nào khi mà các yêu cầu của ứng dụng ở một số khía cạnh nào đó tăng nên. Chúng

ta hãy xem xét một số khía cạnh sau:

a. Yêu cầu tải (Request load)

Ví dụ một ứng dụng server được thiết kế cho phép xử lí 100 giao dịch mỗi giây

(100pts) với một kiến trúc nào đó, nhưng khi ứng dụng cần nâng cấp để nó có thể xử lí

số giao dịch tăng gấp 100 lần thì kiến trúc này còn phù hợp ko?

Thông thường có hai giải pháp thường được sử dụng để nâng cao khả năng đáp

ứng của hệ thống khi tải trọng lên nó tăng gấp nhiều lần:

- Thiết kế các ứng dụng đa luồng hay nhiều luồng đơn được sử lí trên cùng một máy

tính (Scale up works). Để thực hiện được điều này chắc chắn yêu cầu về bộ nhớ và các

tài nguyên khác sẽ tăng nên, tuy nhiên tốc độ sử lí của hệ thống sẽ tăng nên đáng kể.

12

- Phân bố tải đồng đều trên các máy tính khác nhau (Scale out works), mục đích là

làm cho các máy tính cố hiệu quả làm việc như nhau vì việc đầu tư vào phần cứng sẽ

trở lên lãng phí nếu như một máy tính nào đó phải làm việc quá tải trong khi các máy

tính khác thì không hoạt động hết công suất.

Hình 1.1 mô tả quá trình scale-up và scale-out

Hình 1.1 Scale out versus scale up

b. Nhiều kết nối đồng thời (Simultaneous connections)

Một kiến trúc được thiết kế để phục vụ 1000 lượt truy cập trong cùng một thời

điểm nhưng nó sẽ đáp ứng ra sao khi số lượt truy cập tăng lên? Nếu mỗi lượt truy cập

của người dùng yêu cầu một lượng nhất định nào đó tài nguyên của hệ thống thì chắc

chắn hệ thống chỉ có thể thực phục vụ có hiệu quả với một giới hạn số lượt truy cập

nhất định.

c. Kích thước dữ liệu (Data size)

Một kiến trúc tốt cần có khả năng mở rộng khi yêu cầu về kích thước dữ liệu mà

nó sử lí tăng nên. Chẳng hạn với một ứng dụng chat online như ta thường thấy chúng

được thiết kế cho phép sử lí những mẩu tin của người dung trong một giới hạn kích

thước nhất định (thông thường là giới hạn về số kí tự). Tuy nhiên trong một số trường

hợp các mẩu tin mà người dùng mướn gửi đi vượt quá giới hạn mà ứng dụng cho

13

phép, thông thường trong trường hợp này người sử dụng sẽ phải cắt ngắn bản tinh

mình muốn gửi thành nhiều đoạn và gửi từng đoạn đi. Điều này đặt ra câu hỏi nếu

một ngày nào đó ta cần nâng cấp ứng dụng cho phép gửi đi các mẩu tin với kích thước

lớn đáp ứng yêu cầu của người sử dụng (đôi khi là các file dữ liệu, âm thành, hình

ảnh…) thì kiến trúc hiện tại của hệ thống có đáp ứng được ko?

d. Triển khai ứng dụng (Deployment)

Ở đây ta xem xét tới việc hệ thống được thiết kế thế nào để đảm bảo rằng nó có thể

được triển khai hiệu quả (thậm chí khi cần thay đổi) khi số lượng người sử dụng hệ

thống tăng nên (ở đây muốn nói tới số khách hàng), hay nói cách khác là hệ thống đó

có dễ dàng được cài đặt trên nhiều máy tính khác nhau không? Nó bao gồm các nỗ lực

để cấu hình, phân phối và cập nhật các phiên bản mới.

Một giải pháp lí tưởng là tạo ra một cơ chế tự động cài đặt và triển khải hệ thống

đến người sử dụng mới dựa trên những thông tin đăng kí của người sử dụng. Cơ chế

này đang được sử dụng rộng rãi với các ứng dụng phân phối trên Internet.

e. Khả năng sửa đổi (Modifiability)

Khả năng sửa đổi là yếu tố sống còn quyết định thời gian tồn tài của phần mềm khi

mà các yêu cầu người dùng luôn thay đổi theo thời gian. Khả năng sửa đổi có thể

được coi như là thước đo phản ánh việc phần mềm có dễ dàng được sửa đổi khi có sự

phát sinh các yêu cầu chức năng và phi chức năng hay không?

f. Tính bảo mật (Security)

Tính bảo mật của hệ thống là một chủ đề phức tạp, trong giới hạn nghiên cứu kiến

trúc phần mềm chúng ta chỉ nghiên cứu tới các yêu cầu bảo mật của một ứng dụng và

đưa ra một cơ chế thích hợp hỗ trợ nó.

Các yêu cầu bảo mật phổ biến bao gồm:

- Xác thực (Authentication): Các ứng dụng cần có khả năng xác nhận xem đối

tượng mà nó đang giao tiếp ( con người hay các ứng dụng khác) có hợp thức hay

không.

14

- Sự cấp quyền (Authorization): Những người sử dụng hay các ứng dụng đã được

xác thực chỉ được phép truy cập những tài nguyên nhất định của hệ thống. Chẳng hạn

một số người dùng nào đó chỉ có quyền đọc dữ liệu của hệ thống trong khi những

người khác lại có quyển đọc và ghi…

- Mã hóa (Encryption): Hệ thống phải đảm bảo rằng những thông tin quan trọng khi

được gửi/ nhận giữa các ứng dụng hay giữa người sử dụng với hệ thống được mã hóa

an toàn.

- Toàn vẹn (Integrity): Đảm bảo các thông tin khi truyền nhận không bị thay đổi.

- Không thoái thác (Nonrepudiation): Có một cơ chế an toàn tin cậy nhằm đảm bảo

cả người gửi tin và người nhận tin không thể thoái thác trách nhiệm với mẩu tin đã

trao đổi (một ví dụ tiêu biểu và nổi bật là ứng dụng chữ kí số).

g. Khả năng sẵn sàng (Availability)

Khả năng sẵn sàng của ứng dụng liên quan chặt chẽ tới độ tin cậy của nó. Nếu một

ứng dụng không sẵn sãng khi người sử dụng cần điều đó có nghĩa nó chưa đáp ứng

được yêu cầu chức năng.

h. Khả năng tích hợp (Integration)

Các hệ thống cần thiết kế cho phép nó có thể tích hợp với các ứng dụng khác trong

bối cảnh và phạm vi hoạt động rộng hơn. Thông thường giá trị của một hệ thống phần

mềm sẽ tăng lên nếu nó có thể tích hợp để cũng hoạt động thống nhất với các hệ

thống khác. Các ứng dụng khác có thể truy cập trực tiếp tới dữ liệu của hệ thống tuy

nhiên một giải pháp hay được sử dụng hơn là xây dựng một API như hình 3.2.

1.2 Các kiểu tích hợp

15

Cách duy nhất để các ứng dụng ngoài hệ thống tích hợp với hệ thống và truy cập

dữ liệu của nó là thông qua API

Việc tích hợp dữ liệu cần phải mềm mỏng và đơn giản. Các ứng dụng có thể viết

bằng một ngôn ngữ nào đó để xử lí văn bản, truy cập cơ sở dữ liệu quan hệ sử dụng

SQL… Cho nên việc xây dựng một API yêu cầu nhiều công sức nhưng nó sẽ cung cấp

một môi trường có khả năng kiểm soát nhiều hơn, nâng cao sự chuẩn xác và bảo mật

khi tích hợp các hệ thống với nhau.

Ngoài các nhân tố đánh giá chất lượng đã đề cập ở trên, tùy vào từng hệ thống cụ

thể trong một vài trường hợp người ta còn xem xét tới các nhân tố quan trọng khác

như: khả năng cài đặt dễ dàng trên các nền tảng phần cứng/phần mềm khác nhau

(Portability), dễ dàng kiểm thử (Testability), dễ dàng cho việc hộ trợ vận hàng khi hệ

thống đã được triển khai trong thực tế (Supportability)

III. Quy trình thiết kế kiến trúc phần mềm

1. Phác thảo quy trình

Vai trò của kiến trúc sư phần mềm không đơn giản chỉ là đưa ra các hoạt động

thiết kế kiến trúc cũng như kiến trúc của hệ thống. Kiến trúc sư phần mềm cần:

- Làm việc với đội phân tích yêu cầu hệ thống: đội phân tích yêu cầu chú trọng tới

các yêu cầu chức năng từ phía khách hàng và kiến trúc sư giữ vai trò quan trọng trong

việc tập hợp các yêu cầ đó bởi sự hiểu tổng thể hệ thống cần gì và đưa ra các nhân tố

chất lượng của hệ thống.

- Làm việc với các stakeholder khác nhau: Kiến trúc sư phần mềm giữ vai trò quan

trọng trong việc chắc chắn tất cả những gì stakeholder cần cho hệ thống đã được hiểu

chính xác và được đưa vào trong thiết kế. Chẳng hạn người quản trị hệ thống có thể

yêu cầu ứng dụng cần dễ dàng được cài đặt, theo dõi, quản lí và cập nhật…

- Lãnh đạo đội thiết kế kiến trúc: Xác định kiến trúc ứng dụng là một hoạt động thiết

kế. Kiến trúc sư lãnh đạo đội thiết kế, bao gồm các thiết kế viên hệ thống (hay trong

các hệ thống lớn là các kiến trúc sư khác) và đưa ra các dẫn dắt kĩ thuật để cuối cùng

đưa ra bản thiết kế chi tiết (architecture blueprint) của hệ thống cần triển khai.

16

- Làm việc với bên quản trị dự án: Kiến trúc sư phần mềm làm việc mật thiết với

người quản trị dự án nhằm giúp đưa ra nhằm đưa ra kế hoạch dự án, các ước lượng,

nhiệm vụ và kế hoạch thực hiện dự án.

Có 3 bước trong tiến trình thiết kế kiến trúc đó là: xác định yêu cầu kiến trúc, thiết

kế kiến trúc và chuẩn hóa (hình 1.3)

Hình 1.3 Tiến trình thiết kế kiến trúc

- Xác định yêu cầu kiến trúc: Liên quan tới việc tạo ra một tuyên bố hoặc mô hình

các yêu cầu, nó sẽ thúc đẩy việc thiết kế kiến trúc.

- Thiết kế kiến trúc: liên quan tới việc xác định cấu trúc và vai trò của các thành

phần trong kiến trúc hệ thống.

- Chuẩn hóa: liên quan tới việc kiểm tra (testing) kiến trúc dựa trên tập các yêu cầu

hệ thống.

2. Xác định yêu cầu kiến trúc

Trước khi một giải pháp thiết kế kiến trúc có thể được chính thức tiến hành nhằm

đưa ra bản thiết kế hệ thống, ta cần xem xét chi tiết các yêu cầu kiến trúc mà hệ thống

cần đáp ứng. Hình 1.4 thể hiện quá trình xác định các yêu cầu kiến trúc:

17

Hình 1.4 Input và output của quá trình xác định yêu cầu kiến trúc

Việc xác định các yêu cầu kiến trúc chủ yếu dựa trên các yêu câu chức năng và các

yêu cầu khác do stakeholder cung cấp. Quá trình xác định yêu cầu kiến trúc sẽ đưa ra

môt tập các yêu cầu về kiến trúc của hệ thống. Tất nhiên thực tế các thông tin mà kiến

trúc sư cần vẫn chưa được tài liệu hóa đầy đủ ở mức này. Cách duy nhất để kiến trúc

sư phần mềm có được đầy đủ các thông tin cần thiết cho việc thiết kế kiến trúc hệ

thống đó là họ phải trực tiếp làm việc với các stakeholder và nhiệm vụ này sẽ khó

khăn hơn nhiều nếu như kiến trúc sư phần mềm không phải là một chuyên gia trong

lĩnh vực nghiệp vụ của dự án họ đang triển khai.

Không phải tất cá các yêu cầu kiến trúc đều có giá trị tương đương nhau, rất nhiều

trong số đó là các yêu cầu ở mức ưu tiên thấp hay không cần thiết. Vì vậy chúng ta

cần phần loại các yêu cầu theo mức độ ưu tiên khác nhau. Người ta thường sử dụng 3

mức độ sau để phần loại:

- Cao (high): hệ thống phải hỗ trợ các yêu cầu này, đây là các yêu cầu sống còn của

hệ thống.

- Trung bình: các yêu cầu này cần thiết ở một số trạng thái nhất định của hệ thống

nhưng không phải lúc nào nó cũng có ý nghĩa đối với hệ thống.

18

- Thấp: các yêu cầu ở mức này chủ yếu là các mong đợi của khách hàng và nhà phát

triển với hệ thống đang xây dựng. Tuy nhiên nó không có ý nghĩa quyết định với việc

thiết kế kiến trúc hệ thống.

3. Thiết kế kiến trúc

Nhiệm vụ của kiến trúc sư hệ thống là cực kì quan trọng và chất lượng của thiết kế

kiến trúc thực sự là vấn đề đề phải quan tâm. Các tài liệu yêu cầu hoàn hảo cũng như

công sức làm việc cùng stakeholder sẽ trở lên vô nghĩa nếu như rút cuộc một thiết kế

tồi được được ra.

Hình 2.5 chỉ ra các input và output của quá trình thiết kế kiến trúc.

Hình 1.5 Input và output của quá trình thiết kế kiến trúc

Có hai bước trong gia đoạn thiết kế kiến trúc chúng được lặp đi lặp lại một cách tự

nhiên. Bước đầu tiên liên quan tới việc lựa chọn một chiến lược tổng thể cho kiến trúc

dựa trên các mẫu kiến trúc đã được chứng minh (framework). Bước thứ 2 liên qua tới

việc xác định các thành phần riêng lẻ sẽ tạo nên ứng dụng, chúng phù hợp với

framework và phân bổ cho chúng các vai trò nhất định trong hệ thống. Đầu ra của

19

quá trình này là một tập các khung nhìn kiến trúc (thể hiện thiết kế kiến trúc) và các

tài liệu thiết kế nhằm giải thích cho thiết kế đưa ra.

4. Chuẩn hóa

Trong suốt tiến trình thiết kế kiến trúc, mục tiêu của pha chuẩn hóa là nhằm đảm

bảo kiến trúc đưa ra thỏa mãn các mục tiêu của hệ thống. Việc chuẩn hóa kiến trúc hệ

thống luôn luôn là một thử thách đối với các kiến trúc sư hệ thống bởi vì nó không thể

được kiểm thử một cách tường minh để xác định xem liệu nó đã hoàn toàn đáp ứng

các các yêu cầu hay chưa. Thậm chí nó có thể bao gồm các thành thành phần mới cần

được xây dựng hay các “hộp đen” các thành phần đó như là tầng trung gian, các thư

viện và các ứng dụng đã tồn tại sẵn.

20

Chương II. KỸ THUẬT XÂY DỤNG TẦNG TRUNG GIAN (MIDLEWARE)

I. Giới thiệu

Để minh họa cho vai trò của tầng trung gian trong kiến trúc phần mềm chúng ta

hãy đi xem xét quá trình xây dựng kiến trúc của một ngôi nhà.

Khi kiến trúc sư thiết kế một ngôi nhà, họ sẽ tạo các bản vẽ, về cơ bạn một bản vẽ

sẽ cho thấy cái nhìn từ các góc khác nhau của ngôi nhà, cấu trúc và kết cấu của từng

phần trong ngôi nhà. Sự thiết kế này dựa trên những yêu cầu thiết kế của ngôi nhà

chẳng hạn như các khoảng không, loại hình thiết kế (văn phòng, nhà thờ, trung tâm

mua sắm, nhà ở…), yêu cầu thẩm mĩ, yêu cầu chức năng, giới hạn tài chính. Những

bản vẽ này thể hiện cái nhìn trừu tượng của ngôi nhà mong đợi.

Người ta vẫn còn cần tới rất nhiều cô gắng khác để biến bản vẽ kiến trúc ở trên

thành cái gì đó mà thực tế có thể bắt đầu xây dựng ngôi nhà. Chẳng hạn, cần thiết kế

chi tiết của tường, sàn nhà , cầu thang, hệ thống điện nước… Và mỗi một thành phần

này lại cần có một sự thiết kế chi tiết như: vật liệu, các thành phần để xây dựng.

Vật liệu và các thành phần dùng để xây dựng này là các khối cơ bản dùng để xây

lên ngôi nhà chúng được thiết kế để cho người ta có thể xây lên bất cứ kiến trúc gì mà

họ mong muốn.

Chúng ta hãy nghĩ đến tầng trung gian trong kiến trúc phần mềm như là những cái

ống nước hay dây dẫn trong kiến trúc của một phần mềm. Lí do là:

- Tầng trung gian trong kiến trúc phần mềm đã được chứng minh là cách để gắn kết

các thành phần khác nhau giúp chúng có thể dễ dàng trao đổi thôi tin với nhau. Tầng

trung gian cung cấp những đường ống dẫn để vận chuyển dữ liệu giữa các thành phần

và nó có thể được sử dụng trong miền rộng lớn các loại ứng dụng khác nhau.

- Tầng trung gian có thể được sử dụng để nối kết một số lượng lớn các thành phần

khác nhau theo một cách hiệu quả và dễ hiểu. Các kết nói có thể là: một – một, một –

nhiều và nhiều – nhiều.

- Từ phối cảnh ứng dụng của người dùng, tầng trung gian hoàn toàn bị ẩn đi. Người

sử dụng chỉ cần chạy ứng dụng và họ không cần quan tâm xem dữ liệu bên trong nó

được trao đổi như thế nào. Khi mà phần mềm vẫn còn hoạt động bình thường, tầng

trung gian như một cơ sở hạ tầng không nhìn thấy từ mắt của người sử dụng.

21

- Người sử dụng chỉ nhận thức được sự tồn tại của tầng trung gian khi nó bị hỏng

hóc ở đâu đó. Điều này cũng giống như đường ống dẫn nước và đường dây điện trong

ngôi nhà vậy.

Tầng trung gian cung cấp một cơ sở hạn tầng sẵn sàng để cho việc kết nối các

thành phần phần mềm khác nhau nó có thể được sử dụng trong nhiều miền ứng dụng

khác nhau. Bởi vì nó được thiết kế một cách chung chung và có khá năng cấu hình

trên những nền tảng phổ biến của ứng dụng phần mềm.

II. Phân loại các kĩ thuật xây dựng tầng trung gian

Sở dĩ người ta sử dụng thuật ngữ tầng trung gian là bởi vì nó nằm giữa ứng dụng

và hệ điều hành tức là nằm giữa của kiến trúc ứng dụng.

Các miền ứng dụng khác nhau chứa đựng những kĩ thuật và công nghệ phức tạp

khác nhau điều này làm cho tầng trung gian cũng trở nên phức tạp hơn rất nhiều. Tuy

nhiên trong khuôn khổ tài liệu này chúng ta sẽ chỉ đi tìm hiểu về các xu hướng chính

trong xây dựng tần trung gian. Hình 2.1 đưa ra một sự phân loại các kĩ thuật này và

tên của một vài sản phẩm cho mỗi kĩ thuật này.

Hình 2.1 Các kĩ thuật xây dựng tầng trung gian

- Tầng chuyển vận (Transport layer) tạo nên một đường ống (pipe) cơ bản để gửi và

di chuyễn dữ liệu giữa các thành phần phần mềm. Những đường ống này tạo nên một

nền tảng cho phép di chuyển dữ liệu một các mềm dẻo và đơn giản trong các kiến trúc

ứng dụng phân bổ.

22

- Application server được xây dựng trên nền tảng các dịch vụ chuyển vận. Nó cung

cấp khả năng vận chuyển, bảo mật và dẫn đường. Nó hỗ trợ cho việc lập trình, xây

dựng các ứng dụng đa luồng dựa trên server.

- Message brokers khai thác các dịch vụ chuyển vận hoặc các application server và

thêm vào đó các máy sử lí thông điệp chuyên gia. Các máy này cung cấp khả năng

vận chuyển thông điệp nhanh, tính năng lập trình ngôn ngữ bậc cao để định nghĩa các

trao đổi, xử lí và điều hướng các thông điệp giữa các thành phần khác nhau của một

ứng dụng.

- Business process orchestrators (BPOs) là một sự ra tăng các tính năng của

Message brokers nhằm hỗ trợ nhiều ứng dụng kiểu luồng công việc khác nhau. Trong

các ứng dụng này, quá trình xử lí nghiệp vụ có thể mất nhiều giờ và nhiều ngày để

hoàn thành. BPOs cung cấp các công cụ để mô tả quá trình nghiệp vụ thực hiện chúng

và quản lí các trạng thái trun gian trong khi mỗi bước trong quá trình xử lí vẫn được

thực hiện.

III. Các đối tượng phân bổ

Các đối tượng phân bổ là một kĩ thuật quan trọng trong các kĩ thuật xây dựng tầng

trung gian. Xây dựng tầng trung gian dựa trên các đối tượng phân bổ đã được sử dụng

từ trước năm 1990 và được mô tả tốt nhất bởi CORBA.

Xét một ví dụ đơn giản, một client gửi một yêu cầu lên server trên một đối tượng

yêu cầu thành phần môi giới (object request broker - ORB).

2.2 Các đối tượng phân bổ sử dụng CORBA

23

Trong CORBA những đối tượng phục vụ hỗ trợ giao diện được đặc tả sử dụng

ngôn ngữ đặc tả gian diện của CORBA (Interface description language – IDL), nó

định nghĩa những phương thức mà một đối tượng server hỗ trợ. Với đầu vào là các

tham số và trả về một kiểu dữ liệu nào đó. Một đoạn code đơn giản như sau:

Ở đây giao diện IDL định nghĩa một đối tượng CORBA với một hàm duy nhất

isAlive(), nó trả về một xâu và không nhận tham số nào. Một chương trình biên dịch

IDL sẽ được sử dụng để xử lí định nghĩa giao diện này. Trình biên dịch đó sinh ra

một bộ khung đối tượng trong một ngôn ngữ lập trình đích. Các bộ khung đối tượng

cung cấp cơ chế để gọi các phương thức trên server. Người lập trình viên sau đó phải

viết phần code cho mỗi phương thức của server trong một ngôn ngữ lập trình tự nhiên

nào đó.

Server phải tạo một thể hiện của của đối tượng Myservant và làm cho nó có khả

năng gọi được từ ORB.

Bây giờ client có thể khởi tạo một ORB và tham chiếu tới các phương thức nằm

trên server. Server lưu trữ một tham chiếu tới chính các phương thức của nó tại một

24

thư mục nào đó trên server. Client truy vấn tới thư mục này sử dụng tên logic của các

phương thức.

Lời gọi tớ các phương thức trên server trong có vẻ như được đồng bộ với các đối

tượng địa phương (local). Tuy nhiên nền tảng ORB vận chuyển, thống chế các yêu cầu

và các thông số kết hợp trên mạng đến server. Ở đây các mã lệnh được thực hiện và

kết quả được gửi trở lại client đang trong trạng thái chờ.

Trên đây là một mô tả rất đơn giản về kĩ thuật các đối tượng phân bổ. Có rất nhiều

các chi tiết khác cần phải được giải quyết để có thể triển khai xây dựng một hệ thống

thực. Chẳng hạn như xử lí ngoại lệ, định vị phương thức trên server, xử lí đa luồng…

Từ phối cảnh kiến trúc, để xây dựng một hệ thống hoàn chỉnh, ta cần giải quyết được

các vấn đề sau:

- Yêu cầu tới server là các lời gọi từ xa (remote call) thông qua ORB và môi trường

mạng điều này gây ra tác động đến hiệu năng của hệ thống. Do vậy ta cần thiết kế các

giao diện để các lời gọi từ xa có thể thủ nhỏ tối đa và hiệu năng hệ thống được nâng

cao.

- Trong bất kì các ứng dụng phân bổ nào, đều có thể xảy ra hiện tượng server hay

mạng bị hư hại trong một khoảng thời gian nhất định nào đó do vậy các ứng dụng cần

có cơ chế để đối phó với ngoại lệ này và có khả năng khởi động lại server.

- Nếu server lưu giữ các trạng thái của một tương tác giữa client và server (ví dụ đối

tượng customer lưu giữ tên, địa chỉ…), nếu server bị hư hại thì các trạng thái này có

thể mất vì vậy cần có một cơ chế cho phép khôi phục các trạng thái trước đó.

IV.Message-Oriented Middleware

Message-oriented middleware (MOM) là một trong những kĩ thuật then chốt

hướng tới việc xây dựng các hệ thống ứng dụng thương mại trên phạm vi rộng lớn. Nó

giúp kết dính các ứng dụng độc lập trên nhiều nền tảng khác nhau vào trong một hệ

25

thống tích hợp chung. Người sử dụng ko cần viết lại các ứng dụng có sẵn hay tạo ra

những sự thay đổi để các ứng dụng này có thể chạy trong hệ thống ứng dụng thương

mại rộng lớn. Bởi vì nó được thay thế bằng việc tạo ra các hàng đợi (queue) giữa

người gửi và người nhận, đây là một mức trung gian được tạo ra trong suốt quá trình

giao tiếp. MOM tạo ra các software bus để tích hợp các hệ thống phần mềm với nhau.

Hình 2.3 minh họa ứng dụng của MOM trong các tổ chức

Hình 2.3 Tích hợp các ứng dụng trên MOM

Chúng ta sẽ đi xem xét kiến trúc MOM cơ bản:

MOM thể hiện tính liên kết lỏng (loosely coupled) và bất dồng bộ

(Asynchronous). Điều này có nghĩa là bên gửi và bên nhận không được liên kết chặt

chẽ với nhau, nó không giống như kĩ thuật xây dựng tầng trung gian đồng bộ như

trong CORBA. Kĩ thuật xây dựng tầng trung gian đồng bộ có nhiều điểm mạnh riêng

tuy nhiên nó có một hạn chết là để toàn bộ hệ thống hoạt động thành công thì tất cả

các thành phần trong hệ thống và các liên kết mạng phải luôn luôn hoạt động trong

suốt thời gian hệ thống hoạt động.

MOM tách biệt bên gửi và bên nhận bằng việc sử dụng ngăn xếp trung gian phục

vụ cho việc lưu trữ các thông điệp. Bên gửi có thể gửi thông điệp tới bên nhận thông

qua MOM và nó biết rằng thông điệp đó sẽ được gửi tới bên nhận. Thậm chí nếu có sự

hư hỏng trên đường truyền hoặc bên nhận ko sẵn sàng đón nhận thông điệp. Bên gửi

26

chỉ cần báo cho MOM biết về thông điệp nó cần gửi đi sau đó tiếp tục các tiến trình

của mình. Bên gửi không quan tâm tới việc thông điệp được gửi đi như thế nào trên

đường truyền. Hình 2.4 mô tả MOM cơ bản

Hình 2.4 MOM cơ bản

MOM giống như là một server có thể quản lí và điều phối nhiều client trong cùng

một khoảng thời gian. Để tách biệt bên gửi và bên nhận, MOM cung cấp một hàng đợi

dùng để lư trữ các thông điệp. Bên gửi sẽ gửi các thông điệp nó muốn gửi đi đến hàng

đợi và bên nhận sẽ lấy đi các thông điệp được gửi đến cho nó từ hàng đợi. Một MOM

server có thể tạo và quản lí nhiều hàng đợi và nó có khả năng quả lí nhiều thông điệp

được gửi đi đồng thời sử dụng các luồng có tổ chức. Một hay nhiều tiến trình có thể

gửi thông điệp tới một hàng đợi và mỗi hàng đợi có thể có một hay nhiều bên nhận.

Mỗi hàng đợi có tên riêng để bên gửi và bên nhận xác định khi nó muốn thực hiện

một quá trình trao đổi thông điệp. Hình 2.5 minh họa quá trình gửi nhận thông điệp

thông qua MOM server

Hình 2.5 Gửi nhận thông điệp qua MOM server

27

Mỗi MOM server có một số trách nhiệm cơ bản. Đầu tiên nó phải chấp nhận thông

điệp được gửi từ ứng dụng bên gửi và gửi lại tín hiếu báo cho bên gửi biết rằng nó đã

nhận được thông điệp. Tiếp theo, nó đặt thông điệp tại điểm kế thúc của hàng đợi, ứng

dụng bên nhận có thể gửi nhiều thông điệp tới một hàng đợi trước khi bên nhận có thể

nhận được thông điệp thì MOM cần phải có sự chuẩn bị lưu giữ điệp trong hàng đợi

trong một khoảng thời gian nhật định.

Các thông điệp được phân phối theo cơ chế FIST-IN-FIRST-OUT (FIFO)

và theo thứ tự các thông điệp mà hàng đợi nhận được. Khi bên nhận yêu cầu (request)

thông điệp từ hàng đợi, thông điệp đó được phân phối cho bên nhận và nếu quá trình

này thành công thông điệp sẽ được xóa khỏi hàng đợi.

Cơ chế bất đồng bộ giúp tách biệt một cách tự nhiên quá trình gửi thông điệp và

làm cho dễ dàng hơn rất nhiều cho việc giải quyết nhiều vấn đề phức tập trong thiết

kế phần mềm.

- Bên gửi không cần trả lời lại một thông điệp, nó chỉ cần gửi thông điệp đi sau đó

tiếp tục các công việc của nó. Quá trình này thường được gọi là send and forget

messasging

- Bên gửi không cần trả lời ngay lập tức một yêu cầu thông điệp, bên nhận sẽ cần

một khoảng thời gian nào đó để sử lí một yêu cầu và bên gửi sẽ tiếp tục làm các công

việc hữu ích của nó thay vì chỉ chờ đợi yêu cầu thông điệp của bên nhận.

- Bên nhận và hệ thống mạng kết nối giữa bên gửi và bên nhận có thể bị hư hại

trong một khoảng thời gian nào đó và chúng không đồng hoạt động liên tiếp nhau.

MOM sẽ lưu giữ thông điệp và thực hiện phân phối thông điệp tới bên nhận trong lần

khởi tạo tiếp theo.

V. Application Servers

Có khá nhiều định nghĩa về application server nhưng tất cả đều khá giống nhau về

bản chất cốt lõi. Theo đó application server là một kĩ thuật xây dựng các thành phần

dựa trên server và nó nằm ở lớp giữa (middle-tier) của kiến trúc N-tier và nó cung cấp

sự giao tiếp được phân bổ, bảo mật, các giao dịch và sự bền bỉ.

Application server được sử dụng rộng rãi để xây dựng các ứng dụng internet. Hình

2.6 mô phỏng kiến trúc N-tier cho ứng dụng web.

28

Hình 2.6 Kiến trúc N-tier cho ứng dụng web

- Lớp client (Client Tier): Trong ứng dụng web, lớp client bao gồm một trình duyệt

web để gửi yêu cầu và download các trang web từ server về dưới dạng HTML và kĩ

thuật này không thuộc về application server.

- Lớp web (Web Tier): Lớp web chạy một web server dùng để kiếm soát yêu cầu từ

client. Khi yêu cầu tải trang từ client tới, web tier báo cho những thành phần web

server-hosted như servlets, Java Server Pages (JSPs) hay Active Server Pages (ASPs)

nó phụ thuộc vào web server được sử dụng. Yêu cầu tải trang tử client chỉ chính xác

thành phần mà nó muốn gọi. Thành phần này sau đó xử lí các thông số nó nhận được

từ yêu cầu tải trang của client để yêu cầu lớp logic nghiệp vụ (business logic tier) gửi

các thông tin theo yêu cầu từ client. Thành phần này tiếp tục định dạng lại dữ liệu mà

nó nhận được từ lớp logic nghiệp vụ sau đó trả lại client dưới dạng HTML thông qua

web server.

- Lớp logic nghiệp vụ (business logic tier): Lớp logic nghiệp vụ bao gồm sự logic

nghiệp vụ lõi cho ứng dụng. Các thành phần nghiệp vụ như Enterprise JavaBeans

29

(EJB) trong JEE, thành phần .NET hay các đối tượng CORBA. Thành phần logic

nghiệp vụ nhận yêu cầu từ lớp web sau đó thỏa mãn yêu cầu đó bằng các truy nhập

một hay nhiều cơ sở dữ liệu để lấy các dữ liệu phù hợp trả về lớp web. Môi trường

thời gian thực (run-time enviroment) được ví nhưng một bộ chứa đựng các thành phần

logic nghiệp vụ này. Bộ chứa đựng này tuy có nhiều loại khác nhau (ví dụ EJB, .NET,

CORBA) tuy nhiên nó đều bao gồm các giao dịch, sự quản lí chu kì sống của thành

phần logic nghiệp vụ, sự quản lí trạng thái, bảo mật, đa luồng và bộ quả lí tài nguyên.

Những thành phần này chỉ rõ trong các file nằm ngoài mã lệnh của nó kiểu của các

hành vi (behavior) cúng yêu cầu từ bộ chứa đựng trong môi trường thời gian thực và

dựa trên bộ chứa đựng này để cung cấp các dịch vụ. Điều này giải phóng lập trình

viên khỏi sự xáo trộn giữa logic nghiệp vụ và mã lệnh để kiểm soát hệ thống và các

vấn đề môi trường.

- Lớp những hệ thống thông tin thương mại (Enterprise Information Systems Tier):

bao gồm một hay nhiều cơ sở dữ liệu và các ứng dụng phía sau (back – end

application) như là máy tính lớn (mainframe) và các ứng dụng chuyên dụng khác. Các

thành phần nghiệp vụ phải truy vấn và tương tác với với những dữ liệu được lưu trữ

này để đáp ứng yêu cầu từ client.

Lõi của application server là bộ chứa các thành phần logic nghiệp vụ và sự hỗ trợ

nó cung cấp để thực hiện việc logic nghiệp vụ sử dụng các mẫu thành phần phần

mềm.

30

Chương III. MỘT SỐ KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI

I. Kiến trúc phần mềm hướng dịch vụ (Service Oriented Architecture – SOA)

1. Kiến trúc hướng dịch vụ là gì ?

Kiến trúc hướng dịch vụ (Service-oriented architecture) là một hướng tiếp cận với

việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng module, trong

đó mỗi module đóng vai trò là một “dịch vụ có tính loose coupling”, và có khả năng

truy cập thông qua môi trường mạng. Hiểu một cách đơn giản thì một hệ thống SOA

là một tập hợp các dịch vụ được chuẩn hoá trên mạng trao đổi với nhau trong ngữ

cảnh một tiến trình nghiệp vụ.

Trong SOA có ba đối tượng chính, minh họa trong Hình 3.1

Hình 3.1 – Sơ đồ cộng tác trong SOA

Nhà cung cấp (service provider) dịch vụ cần cung cấp thông tin về dịch vụ của

mình cho một dịch vụ lưu trữ thông tin dịch vụ (service registry). Người sử dụng

(service consumer) thông qua service registry để tìm kiếm thông tin mô tả về dịch vụ

cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp.

SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay

như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triển khai theo mô

hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là cơ sở và nền tảng cho

việc tích hợp, tái sử dụng lại những tài nguyên hiện có.

31

Thật ra, tư tưởng về một hệ thống SOA không phải là mới. Comnon Object

Request Broker Architecture (CORBA) và mô hình Distributed Component Object

Model (DCOM) của Microsoft hay như Enterprise Java Bean (EJB) của Java của đã

cung cấp tính năng này từ lâu. Tuy nhiên những cách tiếp cận hướng dịch vụ này vẫn

còn gặp phải một số vấn đề khó khăn (đã phân tích ở trên). SOA không chỉ là một cải

tiến đáng kể giúp giải quyết những yếu điểm của các công nghệ trước mà còn đem đến

nhiều ưu điểm nổi trội.

2. Bốn nguyên tắc chính của hệ thống SOA

2.1 Sự phân định ranh giới rạch ròi giữa các dịch vụ

Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao tiếp.

Thành phần giao tiếp này sẽ qui định về những định dạng thông điệp sử dụng trong

quá trình trao đổi : thông điệp nào sẽ được chấp nhận và thông điệp nào sẽ không

được xử lý. Và đây chính là cách duy nhất để các đối tượng bên ngoài có thể truy cập

thông tin và chức năng của dịch vụ. Ta chỉ cần gửi các thông điệp theo các định dạng

đã được định nghĩa trước mà không cần phải quan tâm đến cách xử lý của dịch vụ như

thế nào (môi trường thực thi, ngôn ngữ lập trình...). Điều này đạt được do sự tách biệt

giữa thành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ .

2.2 Các dịch vụ tự hoạt động

Các dịch vụ cần phải được triển khai và hoạt động như những thực thể độc lập mà

không lệ thuộc vào một dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa là nó

sẽ không bị sụp đổ khi có sự cố. Để thực hiện điều này, dịch vụ cần duy trì đầy đủ

thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động trong

trường hợp một dịch vụ cộng tác bị hỏng; và để tránh các cuộc tấn công từ bên ngoài

(như gửi thông điệp lỗi, hay gửi thông điệp ồ ạt) bằng cách sử dụng các kỹ thuật về

an toàn, bảo mật... Đây chính là ý nghĩa của khái niệm ‘loose coupling service’ mà ta

đã đề cập trong định nghĩa SOA.

2.3 Các dịch vụ chia sẻ lược đồ

Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoài, và

hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ

32

liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.). Như thế hệ thống của ta sẽ

có tính liên kết và khả năng dễ mở rộng.

2.4 Tính tương thích của dịch vụ dựa trên chính sách

Điều này nghĩa là, một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải

thỏa mãn các chính sách (policiy) và yêu cầu (requirements) của dịch vụ đó như là mã

hóa, bảo mật... Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai các

yêu cầu, chính sách đó.

3. Các tính chất của một hệ thống SOA

3.1 Loose coupling

Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách module với

nhau. Có hai loại coupling là rời (loose) và chặt (tight). Các module có tính loose

coupling có một số ràng buộc được mô tả rõ ràng trong khi các module có tính tight

coupling lại có nhiều ràng buộc không thể biết trước. Hầu như mọi kiến trúc phần

mềm đều hướng đến tính loose coupling giữa các module. Mức độ kết dính của mỗi

hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống của chính nó. Kết dính

càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng

dịch vụ mỗi khi có thay đổi nào đó xảy ra. Mức độ coupling tăng dần khi khi bên sử

dụng dịch vụ càng cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử

dụng dịch vụ được cung cấp. Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết

định dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ giữa hai bên càng chặt. Ngược

lại, nếu bên sử dụng dịch vụ không cần biết mọi thông tin chi tiết của dịch vụ trước

khi triệu gọi nó thì quan hệ giữa hai bên càng có tính loose coupling.

SOA hỗ trợ loose coupling thông qua việc sử dụng hợp đồng và liên kết (contract

and binding). Một người sử dụng truy vấn đến nơi lưu trữ và cung cấp thông tin dịch

vụ (registry) để lấy thông tin về loại dịch vụ cần sử dụng. Registry sẽ trả về tất cả

những dịch vụ thoải tiêu chuẩn tìm kiếm. Từ bây giờ người dùng chỉ việc chọn dịch

vụ mà mình cần, và thực thi phương thức trên đó theo mô tả dịch vụ nhận được từ

registry. Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào cài đặt của dịch vụ

mà chỉ dựa trên hợp đồng mà dịch vụ đó hỗ trợ.

33

Hình 3.2 - Tính chất loose-coupling

Tính loose coupling giúp gỡ bỏ những ràng buộc điều khiển giữa những hệ thống

đầu cuối. Mỗi hệ thống có thể tự quản lý độc lập nhằm tăng hiệu suất, khả năng mở

rộngvà khả năng đáp ứng cao. Những thay đổi cài đặt cũng được che dấu đi. Loose

coupling đem đến sự độc lập giữa bên cung cấp và bên sử dụng nhưng nó đòi hỏi các

interface phải theo chuẩn và cần một thành phần trung gian quản lý, trung chuyển yêu

cầu giữa các hệ thống đầu cuối.

3.2 Sử dụng lại dịch vụ

Bởi vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơi nhất

định nên chúng dễ dàng được tìm thấy và tái sử dụng. Nếu một dịch vụ không có khả

năng tái sử dụng, nó cũng không cần đến interface mô tả. Các dịch vụ có thể được tái

sử dụng lại bằng cách kết hợp lại với nhau theo nhiều mục đích khác nhau. Tái sử

dụng lại các dịch vụ còn giúp loại bỏ những thành phần trùng lắp và tăng độ vững

chắc trong cài đặt, nó còn giúp đơn giản hoá việc quản trị. Thực ra tái sử dụng dịch vụ

lại dễ dàng hơn tái sử dụng thành tố hay lớp. Những dịch vụ được dùng chung bởi tất

cả các ứng dụng của một hệ thống SOA gọi là những shared infrastructure service.

3.3 Sử dụng dịch vụ bất đồng bộ

34

Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp với

đầy đủ thông tin ngữ cảnh tới bên nhận. Bên nhận xử lý thông tin và trả kết quả về

thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp

được xử lý xong. Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch vụ

chuyển thông điệp, các yêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lý với tốc

độ tối ưu. Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về

nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ.

Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và

bất đồng bộ.

3.4 Quản lý các chính sách

Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật

kết hợp riêng gọi là các policy. Các policy cần được quản lý các áp dụng cho mỗi dịch

vụ cả khi thiết kế lẫn khi trong thời gian thực thi.Việc này tăng khả năng tạo ra các

dịch vụ có đặc tính tái sử dụng. Bởi vì các policy được thiết kế tách biệt, và tùy vào

mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm. Nếu không sử dụng các policy,

các nhân viên phát triển phần mềm, nhóm điều hành và nhóm nhóm hỗ trợ phải làm

việc với nhau trong suốt thời gian phát triển để cài đặt và kiểm tra những policy.

Ngược lại , nếu sử dụng policy, những nhân viên phát triển phần mềm giờ chỉ cần tập

trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗ trợ tập trung vào

các luật kết hợp.

3.5 Coarse granularity

Khái niệm granularity trong dịch vụ có thể hiểu theo hai cách. Đầu tiên, nó được

hiểu trong phạm vi toàn bộ kiến trúc cài đặt của dịch vụ. Thứ hai, nó được hiểu trong

phạm vi từng phương thức của từng interface triển khai. Mức độ granularity cũng

được hiểu ở mức tương đối. Ví dụ, nếu một dịch vụ cài đặt tất cả chức năng của một

hệ thống ngân hàng, chúng ta xem nó là coarse-grained. Nếu nó hỗ trợ chỉ chức năng

kiểm tra thể tính dụng, chúng ta lại xem nó là fine-grained. Trước khi có kiến trúc

thành tố và dịch vụ, các hệ thống phân tán chủ yếu dựa trên ý tưởng phân tán đối

tượng. Những hệ thống phân tán đối tượng chứa bên trong nó nhiều đối tượng fine-

grained trao đổi thông tin với nhau qua mạng. Mỗi đối tượng có những ràng buộc với

35

nhiều đối tượng khác bên trong hệ thống. Do truy cập đến một đối tượng phải qua

nhiều trung gian mà hiệu quả đạt được không cao nên khuynh hướng thiết kế hệ

thống phân tán đối tượng đang dần chuyển sang thiết kế các coarser-grained

interface.

Hình 3.3 minh họa một hệ thống phân tán đối tượng với nhiều mối liên kết. Cùng

với kích thước và độ phức tạp của hệ thống ngày càng tăng, những ràng buộc này trở

nên ngày càng khó quản lý. Hiệu suất cũng giảm tương ứng số lượng các kết nối trung

gian. Khả năng bảo trì cũng giảm khi số lượng ràng buộc giữa những đối tượng ngày

một tăng. Khi một đối tượng cần được thay đổi ở interface, nó có thể ảnh hưởng đến

một lượng lớn những đối tượng phân tán khác. Nhân viên phát triển phải biên dịch và

triển khai lại toàn bộ đối tượng bị thay đổi và những đối tượng liên quan với

chúng.Một hệ thống dựa trên quản lý các truy cấp đến đối tượng bên trong dịch vụ

thông qua một số coarse-grained interface như Hình 3.4. Một dịch vụ có thể được

cài đặt như một tập những đối tượng fine-grained nhưng bản thân những đối tượng đó

lại được sử dụng trực tiếp qua mạng. Trong khi đó một service được cài đặt như

những đối tượng có một hoặc nhiều đối tượng coarse-grained hoạt động như những

facades phân tán thì những đối tượng này lại có thể được sử dụng qua mạng và cho

phép truy cập đến các đối tượng sâu bên trong. Tuy nhiên các đối tựơng bên trong

service đó bây giờ sẽ trao đối trực tiếp với nhau ở trong cùng một máy chứ không

phải trên mạng.

Hình 3.3 – Các đối tượng fine-grained

36

Hình 3.4 – Các đối tượng coarse-grained

Mặc dù những service nói chung hỗ trợ coarser-grained interface hơn các hệ thống

phân tán đối tượng và các hệ thống hướng thành tố, độ “thô” vẫn hàm chứa bên trong

nó chứa một mức độ granularity nào đó , như hình Hình 3.5

Hình 3.5 – Các mức độ granularity

3.6 Khả năng cộng tác

Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác (Interoperability), khả

năng mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác

nhau. Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng

kết nối. Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định

dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu. Interoperability is achieved bằng

cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client. Kỹ

thuật này đạt được bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung

gian. Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu khả kết

(interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống. Ví dụ Web

Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống, JAX-RPC và JAXM

chuyển đối tượng dạng Java thành SOAP.

37

3.7 Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm truy tìm dịch vụ (service discovery). Một người sử dụng

cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi

cần. Người sử dụng chỉ cần hỏi một registry về dịch vụ nào thoả yêu cầu tìm kiếm. Ví

dụ, một hệ thống chuyển khoảng (consumer) yêu cầu một registry tìm tất cả các dịch

vụ có khả năng kiểm tra thẻ tín dụng. Registry trả về một tập các entry thoả yêu cầu.

Cácentry chứa thông tin về dịch vụ, bao gồm cả phí giao dịch. Bên sử dụng sẽ chọn

một dịch vụ có phí giao dịch thấp nhất trong danh sách các dịch vụ trả về, kết nối đến

nhà cung cấp dịch vụ đó dựa trên thông tin registry entry để sử dụng dịch vụ kiểm tra

thẻ tín dụng. Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cần thiết

dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô

tả cung cấp và gửi đi. Nhà cung cấp dịch vụ sẽ thực thi kiểm trả thẻ tín dụng và trả về

một thông điệp có định dạng đúng như trong phần mô tả dịch vụ. Mối ràng buộc duy

nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry

trung gian. Mối ràng buộc này là ràng buộc trong thời gian chạy chứ không phải ràng

buộc trong lúc biên dịch. Tất cả thông tin cần thiết về dịch vụ được lấy về và sử dụng

trong khi chạy.

Ví dụ trên cho thấy cách bên sử dụng triệu gọi dịch vụ một cách “động”. Đây là

một thế mạnh của SOA. Với SOA, bên sử dụng dịch vụ không cần biết định dạng của

thông điệp yêu cầu và thông điệp trả về,cũng như địa chỉ dịch vụ cho đến khi cần.

3.8 Tự hồi phục

Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục

hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. Một hệ thống tự

hồi phục (self-healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà

không cần sự can thiệp của con người.

Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nao

trong tình trạng hỗn loạn. Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thể hoạt

động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tổng hợp từ những từ

nhiều dịch vụ của nhiều tổ chức khác nhau. Độ tin cậy phụ thuộc vào khả năng phụ

38

hồi của phần cứng sau khi bị lỗi. Hạ tầng mạng phải cho phép các kết nối động từ

nhiều hệ thống khác nhau kết nối đến trong khi chạy. Một khía cạnh khác ảnh hưởng

đến độ tin cậy là kiến trúc mà dựa trên đó ứng dụng được xây dựng. Một kiến trúc hỗ

trợ kết nối và thực thi động khi chạy sẽ có khả năng tự phục hồi hơn một hệ thống

không hỗ trợ những tính năng trên.

Thêm vào đó, bởi vì những hệ thống dựa trên dịch vụ yêu cầu sự tách biệt giữa

nterface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một interface. Nếu

một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất

giao dịch cho khách hàng mà không bị ảnh hưởng gì. Khả năng này chỉ có được khi

client chỉ tương tác với interface của dịch vụ chứ không tương tác trực tiếp cài đặt của

dịch vụ. Đây là một trong những tình chất cơ bản của các hệ thống hướng dịch vụ.

4. Lợi ích của SOA

Nói đến SOA là nói đến ‘tiết kiệm’- cả tiết kiệm chi phí lẫn thu được giá trị nhiều

hơn từ các hệ thống có sẵn. Hẳn cũng phải có lý do để hàng trăm tập đoàn đã chú ý

đến SOA như một giải pháp tích hợp nhằm giảm giá thành của một đề án một cách rất

ấn ượng.

Sử dụng lại những thành phần có sẵn

Một trong những lợi ích rõ ràng nhất của SOA là nó giúp các công ty thu được giá

trị nhiều hơn bằng cách sử dụng lại những tài nguyên sẵn có; kết quả là giảm chi phí

cho phần kiến trúc và tích hợp. Ngoài ra nó còn giúp giảm chi phí mua phần mềm

mới. Thời gian viết chương trình lấy dữ liệu từ máy chủ trước đây được tính bằng

tháng thì bây giờ chỉ còn tính bằng phút ! Lợi ích của việc sử dụng lại có thể chia làm

2 phần :

• Lợi ích từ việc sử dụng lại những thành phần nhằm giảm tính dư thừa.

• Lợi ích từ việc sử dụng lại những thành phần có sẵn khi thiết kế cung cấp một chức

năng mới.

Đầu tiên như đã nói, nhiều phần mềm doanh nghiệp đã phát triển thành những

nhóm phần mềm tách biệt (funtional silos), thông thường là tương ứng với mỗi đơn vị

39

kinh doanh. Ví dụ một công ty bán lẻ có thể có một nhóm phần mềm cho hệ thống

phân phối, một nhóm phần mềm cho hệ thống lưu kho và một nhóm phần mềm cho

những chức năng liên kết. Thông thường những nhóm phần mềm này đựơc phát triển

trên nhiều nền tảng khác nhau, sử dụng nhiều ngôn ngữ lập trình khác nhau và thường

có nhiều tính năng lặp lại giữa chúng. Một hệ thống SOA cho phép các công ty tránh

tình trạng lặp dư thừa, tạo ra những đơn thể dịch vụ chia sẻ giữa các ứng dụng.

Trong một hệ thống SOA, chỉ cần thay đổi duy nhất một phiên bản của dịch vụ cần

được thay đổi và chỉ cần kiểm thử một lần, sử dụng những kỹ năng tương ứng với

những kỹ năng đã dùng để phát triển dịch vụ. Lợi ích rõ ràng nhất là giảm chi phí bảo

trì phần mềm. Ngoài ra điều này còn giúp doanh nghiệp chịu trách nhiệm nhiều hơn

với những thay đổi về về mặt nghiệp vụ và cho phép doanh nghiệp cập nhật những

tính năng của nó nhanh hơn.

Bằng cách phân rã một ứng dụng thành những đơn thể dịch vụ nghiệp vụ, sau đó

cho những dịch vụ này liên kết lại với nhau, các hệ thống bây giờ có thể sử dụng lại

được các thành phần có sẵn, giảm chi phí phát triển từng phần độc lập cho mỗi tính

năng mới chưa có. Thay vì phải “thay đổi” , với SOA ta chỉ cần tạo ra các “cầu nối”

liên hệ giữa những hệ thống và ứng dụng khác nhau, thay vì chỉnh sửa hoặc xây dựng

lại từ đầu. Bởi vì có đa phần các dịch vụ mới sử dụng lại những dịch vụ sẵn có nên chi

phí phát triển các thành phần mới được giảm đến mức tối thiểu. Nghĩa là :

• Các công ty có thể triển khai những tiến trình xử lý mới nhanh hơn rất nhiều.

• Chi phí dành cho phát triển và kiểm thử giảm đáng kể

• Giảm rủi ro khi dịch vụ tạm ngưng hoạt động

Lợi ích cuối cùng của việc tái sử dụng thường khó nhận thấy, đó là sử dụng những

thành phần có sẵn trước đó mỗi khi có thể thì mỗi khi có lỗi xảy ra ta có thể giới hạn

vào khu vực có những thành phần đang được phát triển. Nhờ đó rủi ro về lỗi phần

mềm giảm đi và tăng chất lượng dịch vụ.

Giảm chi phí phát triển và kiểm thử, và tránh công việc trùng lặp là một trong

những lợi ích mà SOA mang lại. Nhưng quan trọng vẫn là lợi ích từ việc tăng khả

40

năng kinh doanh. Nếu những nhân tố này được đánh giá đúng mức thì lợi ích mang lại

là rất đáng kể.

Giải pháp ứng dụng tổng hợp cho doanh nghiệp

Cũng với ví dụ trên, SOA mang đến khả năng tổng hợp một lớp các ứng dụng mới

bằng cách kết hợp chức năng từ những hệ thống có sẵn, cung cấp cho người cuối

những chức năng liên kết. Ở đây một số tiến trình cũ có thể được kết hợp với nhau bên

trong một cổng thông tin (portal) giúp cho người dùng cuối chỉ cần truy cập một lần

mà vẫn có thông tin về hàng loạt sản phẩm của doanh nghiệp. Loại kết hợp này có thể

khó khăn nếu không sử dụng SOA vì nó đòi hỏi việc tích hợp phức tạp, nỗ lực lập

trình và kiểm thử. Nhưng với SOA , một ứng dụng tổng hợp có thể được tổng hợp dễ

dàng, bất kể sự khác nhau về địa lý hoặc công nghệ phát triển các dịch vụ đó. Điều

này cho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí đến mức tối

thiểu và tăng sức mạnh thoả mãn yêu cầu của người dùng cuối hiệu quả hơn.

Tính loose coupling giúp tăng tính linh hoạt và khả năng triển khai cài đặt Lợi ích

kế tiếp đến từ tính loose coupling của SOA, trong đó phía triệu gọi dịch vụ không cần

quan tâm đến địa chỉ hoặc công nghệ nền tảng của service. Nó mang đến khả năng

linh hoạt cao và nhiều lợi ích khác.

Trong một hệ thống SOA ta triệu gọi dịch vụ thông qua các interface theo một

dạng thức chuẩn nên giúp lập trình viên tránh được việc phải lặp lại công việc tạo mới

các service có khả năng hiểu tất cả những công nghệ được sử dụng bởi từng dịch vụ

trong hệ thống. Thứ hai, trong trường hợp cần kết nối với các đối tác thương mại thì

những dịch vụ có tính loose-coupling, những interface chuẩn càng đem lại nhiều lợi

ích hơn. Với một hệ thống SOA, thật dễ dàng khi cung cấp một loạt những dịch vụ ra

bên ngoài cho một đối tác nào đó sử dụng. Nhờ tính độc lập địa chỉ và công nghệ của

SOA, đối tác kia không cần quan tâm đến dịch vụ được cài đặt như thế nào, và nhờ

các dịch vụ đã theo chuẩn giao tiếp nên đối tác đó chỉ cần một lượng thông tin nhỏ

vừa đủ để sử dụng dịch vụ. Tương tự cho điều ngược lại, nếu đối tác đã xây dựng một

hệ thống SOA thì việc đem sử dụng chức năng một số dịch vụ của họ vào sử dụng bên

trong hệ thống của mình cũng trở nên dễ dàng và nhanh chóng. Đặc tính này của SOA

41

hứa hẹn tăng hiệu suất và tự động hoá.Cuối cùng một lợi ích mà tính loose coupling

mang lại là tăng khả năng triển khai.

Như đã phân tích ở trên, những thành phần có tính loose coupling có thể được triệu

gọi mà không cần biết chúng được cài đặt như thế nào mà chỉ cần biết cách thức triệu

gọi chúng thông qua một interface chuẩn. Vì vậy chỉ cần bọc những thành phần sử

dụng interface ứng dụng thành dạng dịch vụ, ta đã có một đơn thể thành phần được sử

dụng trong hệ thống SOA như những dịch vụ bình thường khác.

Thích ứng với những thay đổi trong tương lai

Các phương pháp tiếp cận truyền thống trong quy trình phát triển phần mềm có thể

mô tả ngắn gọn là người dùng mô tả họ cần gì – công ty phát triển phần mềm – triển

khai hệ thống theo yêu cầu. Quy trình này đôi khi gặp khó khăn khi gặp những tình

huống thay đổi không định trước. Với SOA, công ty phát triển phần mềm có thể tạo

nên những quy trình nghiệp vụ uyển chuyển, phức tạp biến đổi tùy “theo yêu cầu” và

theo “thời gian thực“.

Hỗ trợ đa thiết bị và đa nền tảng.

SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới. Điều này

cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau bao gồm cả những trình duyệt

và thiết bị di động như pager, điện thoại di động, PDA và các thiết bị chuyên dụng

khác sử dụng cùng một chức năng mà vẫn có thông tin trả về tùy theo dạng thiết bị.

Tính độc lập công nghệ này giúp cho các công ty tiết kiệm chi phí rất nhiều nhất là khi

phải xử lý với vô số công nghệ hiện đang được sử dụng.

Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp.

Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộng bằng cách

thêm nhiều thể hiện (instance) của một service. Công nghệ chia tải (load-balancing) sẽ

tự động tìm và định tuyến yêu cầu đến thể hiện service thích hợp. Tương tự, SOA có

thể chuyển tiếp nội dung yêu cầu đến một thể hiện khác khi cần,nhờ đó tăng khả năng

42

sẵn sàng phục vụ. Cần nhấn mạnh là lợi ích mà SOA mang lại không phải là ít mà là

rất ấn tượng. Thực tế giá trị kinh tế mà SOA mang lại lớn đến nỗi các tạp đoàn trên

thế giới đang suy xét xem làm thế nào để chuyển toàn bộ các kiến trúc phần mềm có

sẵn của họ thành SOA.

5. Một số mô hình triển khai SOA

Chúng ta sẽ thảo luận về ba mô hình triển khai chính của SOA là : service registy,

service broker và service bus. Service registry : đây là mô hình truyền thống để định

vị và liên kết các dịch vụ trong một hệ thống SOA. (xem hình Hình 2-6) . Mô hình

service registry về cơ bản chỉ cần các chuẩn Web services thông thường là SOAP,

WSD và UDDI. Vấn đề lớn nhất của mô hình này là các liên kết dịch vụ là kết nối tĩnh

và phải định nghĩa trong thiết kế, điều này làm cho mô hình trở nên cứng nhắc. Có

một cách cải tiến làm cho mô hình này linh hoạt hơn là tìm kiếm, định vị các dịch vụ

khi chạy. UDDI hỗ trợ nhiều cấu hình khác nhau cho cùng một dịch vụ cung cấp bởi

nhiều nhà cung cấp dịch vụ khác nhau. Điều này cho phép chia tải và tăng tính tin cậy

bởi vì service directory có thể tìm kiếm một dịch vụ nào đó trên tất cả các nhà cung

cấp dịch vụ hiện có .

Service broker : Một bộ trung gian làm việc giữa dịch vụ cung cấp và dịch vụ tiêu

thụ. Trong mô hình cơ bản, tất cả những thông điệp đều được trung chuyển qua

service broker. Dịch vụ này có thể làm nhiều chức năng như định tuyến dựa trên dữ

liệu thông điệp, xử lý lỗi, chuyển đổi thông điệp, chia tải và lọc thông tin. Nó cũng có

thể cung cấp dịch vụ bảo mật, chuyển đổi giao thức, lưu vết và các dịch vụ hữu ích

khác. Tuy nhiên, service broker là nơi có thể xảy ra hiện tượng nghẽn cổ chai và là

điểm dễ bị hỏng hóc. Mô hình broker phân tán là một bước cải tiến mới, ở đó mỗi nền

tảng dịch vụ có một broker cục bộ cho phép giao tiếp với một service broker trung tâm

và giao tiếp trực tiếp với các service broker cùng cấp ở các nền tảng dịch vụ khác.

Service bus : đây là mô hình ra đời sau nhất trong 3 mô hình nhưng nó đã được sử

dụng trong các sản phẩm thương mại large-scale (như IBM, BEA). Service bus cũng

là mô hình có tính loose coupling nhất trong các mô hình, trong đó các dịch vụ không

kết nối trực tiếp với nhau. Đôi khi các service bus kết nối với nhau thành một mạng

các service bus.

43

II. Kiến trúc phần mềm cho dòng sản phẩm phần mềm (Software Productline

Architechture)

1. Dòng sản phẩm phẩn mềm

Vấn đề sử dụng lại trong kĩ nghệ phần mềm luôn là yêu cầu quan trọng mà mọi

nhà thiết kế phần mềm đều đặt ra trước các dự án phần mềm. Việc sử dụng lại các

module đã được xây dựng và kiểm định về chất lượng trước đó giúp cho các nhà phát

triển nhanh chóng tìm ra các giải pháp chất lượng cao và rút ngắn thời gian xây dựng

phần mềm. Trước đây việc sử dụng là cái cấu phần phần mềm thưởng là sử dụng lại

các thành phần rất nhỏ như: các hàm đơn, các thư viện hàm, các kiểu dữ liệu… Nó đã

được chứng mình là mang lại hiệu quả cao nhưng nó không thể hoàn toàn đáp ứng các

yêu cầu của ngành công nghiệp phần mềm hiện đại.

Các phương pháp tiếp cận hiện đại nhưng dòng sản phẩm phần mềm (software

product line hay SPL) đã được chứng minh là một phương pháp tiếp cận có hiệu quả,

nó đáp ứng được các yêu cầu về sự thay đổi và đa dạng, phức tạp của các sản phẩm

phần mềm. Nó giúp hạ giá thành sản phẩm và rút ngắn thời gian dự án trong khi vẫn

đảm bảo các yêu cầu chất lượng.

Hình 3.6 minh họa một ví dụ về việc sử dụng lại trong các sản phẩm công nghiệp

thông thường (product line)

Hình 3.6 Ví dụ về product line

Với mỗi sản phẩm trong SPL, hầu hết các thành phần đều được xây dựng dựa trên

thành phần lõi (core asset). Thành phần lõi thực hiện các chức năng cơ bản mà nó lặp

44

lại trên hầu hết các sản phẩm đồng thời nó có khả năng đáp ứng các thay đổi và có thể

được sử dụng cho bất kì sản phẩm riêng biệt nào. Các thành phần lõi cung cấp một

giao diện cho việc chọn lọc các chức năng mong muốn vào từng sản phẩm phần mềm.

2. Kiến trúc phần mềm cho dòng sản phẩm phần mềm

Việc phát triển các phần mềm theo dòng sản phẩm (SPL) thường được hiểu là

công việc xây dựng kiến trúc dòng sản phẩm phần mềm (product line architecture hay

PLA). PLA là kiến trúc hướng tới việc sử dụng lại các thành phần l õi trong SPL. Mục

đích là:

- Hỗ trợ có hệ thống trong phạm vi đã được kiểm soát sự biến đổi các chức năng.

- Tạo ra sự dễ dàng cho việc chọn lựa các tùy chọn chức năng sẵn có trong việc tạo

ra sản phẩm mới.

Một PLA đạt được mục tiêu này bằng cách sử dụng các cơ chế kĩ thuật cho việc sử

dụng lại và thay đổi.

Về bản chất, để có thể sử dụng lại các cấu phần phần mềm, các nhà phát triển cần:

- Tìm kiếm và hiểu các cấu phần phần mềm đó.

- Làm cho cấu phần phần mềm sẵn sàng cho sử dụng bằng các kết hợp chặt chẽ nó

với sản phẩm mà họ đang phát triển.

- Sử dụng cấu phần phần mềm bằng cách gọi (invoke) cấu phần phần mềm

a. Tìm kiếm và hiểu một cấu phần phần mềm

Căn cứ và đặc điểm và các yêu cầu chức năng của của sản phẩm phần mềm đang

phát triển, các kĩ sư phần mềm tìm kiếm các cấu phần phần mềm phù hợp với sản

phẩm của mình và sử dụng tài liệu API và các tài liệu tham khảo hỗ trợ cho việc dùng

lại cấu phần phần mềm.

b. Tích hợp cấu phần phần mềm và một sản phẩm

Sau khi đã tìm ra một cấu phần phần mềm phù hợp cho việc sử dụng lại, nhà phát

triển phần mềm cần làm cho nó sẵn sàng để sử dụng cho sản phẩm của mình. Có

nhiều cách để thực hiện việc này, nó có thể được phân loại dựa trên ràng buộc thời

gian (binding time) của họ. Dưới đấy là một số ví dụ những ràng buộc thời gian chính

và một số cơ chế:

- Thời gian lập trình – bởi kiểm soát phiên bản mã nguồn

45

- Thời gian xây dựng (buid time) –bởi kiểm soát phiên bản của các thư viện tĩnh

- Thời gian liên kết (link time) – bởi sự hỗ trợ cửa hệ điều hành và máy ảo dành cho

các thư viện động

- Thời gian chạy (run time) – bởi tầng trung gian hoặc nền tảng đặc biệt của các ứng

dụng cho sự cấu hình hay các plug-in động, và cơ chế ngôn ngữ lập trình.

c. Gọi một cấu phần phần mềm

Để gọi các cấu phần phần mềm, các ngôn ngữ lập trình cun cấp các cơ chế gọi như

thủ tục / hàm / phương thức. Cơ chế này trong SPL cũng hoàn toàn tương tự như

trong việc phát triển các phần mềm thông thường.

III. Kiến trúc phần mềm hướng mô hình - Model driven architecture (MDA)

1. Kiến trúc phần mềm hướng mô hình (MDA) là gì?

Trong tiến trình kĩ nghệ phần mềm hiện nay, các tổ chức phát triển phần mềm

đang cố gắng gia tăng việc sử dụng các ngôn ngữ hình thức trừu tượng cho các giải

pháp mô hình hóa. Trong nhiều tiến trình phát triển phần mềm phổ biến hiện nay, các

miêu tả trừu tượng, ví dụ như trong Java hay C#, đước chuyển sang các dạng thực thi

được bởi các công cụ hỗ trợ. Giải pháp mô hình hóa trong phát triển phần mềm giúp

tăng chất lượng sản phẩm, giảm thiểu lỗi do việc biên dịch từ dạng trừu tượng sang

dạng thực thi được được thực hiện tự động bởi các công cụ như trình biên dịch.

MDA được định nghĩa bởi OMG như sau: “MDA là một cách tiếp cận đặc tả hệ

thống công nghệ thông tin, nó phân tách các đặc tả chức năng và các đặc tả thực thi”.

Một mô hình trong MDA là một đặc tả hình thức của chức năng và cấu trúc cũng

như hành vi ứng xử của một ứng dụng hay một hệ thống phần mềm. Trong cách tiếp

cận MDA một hệ thống phần mềm đầu tiên được phân tích và đặc tả như một mô hình

tính toán độc lập (Computation Independent Model – CIM” (CIM còn được hiểu ra

mô hình miền – domain model). CIM chú trọng vào môi trường và các yêu cầu của hệ

thống. Các chi tiết tính toán và triển khai được giấu đi ở mức độ mô tả này.

Hình 3.7 mô phỏng CIM được chuyển hóa thành PIM (Platform Independent

Model), PIM chứa các thông tin tính toán phục vụ cho ứng dụng nhưng nó không

chứa các thông tin chi tiết về các công nghệ nền tảng cơ sở sẽ được sử dụng để thực

hiện PIM. Cuối cùng PIM được chuyển đổi thành một PSM (Platform Specific

46

Model), PSM chứa các mô tả chi tiết và các yếu tố cụ thể để thực hiện nền tảng thực

hiện mục tiêu.

Hình 3.7 Chuyển đổi mô hình trong MDA

Một nền tảng trong MDA chứa các tập hợp các hệ thống con và các công nghệ

cung cấp một tổ hợp các chức năng dựa trên giao diện và các mẫu được đặc tả.

MDA được hỗ trợ bởi một series các chuẩn của OMG, bao gồm UML, MOF (Meta

Object Facility), XMI (XML Metadata Interchange), và CWM (Common Warehouse

Metamodel). Các chuẩn trong MDA định nghĩa một hệ thống được phát triển như thế

nào theo cách tiếp cận hướng mô hình và sử dụng các công cụ MDA tương thích.

2. Ưu điểm của MDA

Mô hình (model) giữ vai trò chính trong MDA nhưng chính xác tại sao chúng ta lại

cần tới các mô hình? Dưới đây là câu trả lời.

Mô hình cung cấp sự trừu tượng hóa của hệ thống, cho phép các stakeholder khác

nhau có những khung nhìn ở các mức khác nhau về hệ thống. Ngoài ra mô hình còn

được sử dụng theo nhiều cách khác như: dự đoán chất lượng hệ thống, điều chỉnh lại

thiết kế theo đúng yêu cầu, dùng để trao đổi với phân tích viên hệ thống, kiến trúc sư

hệ thống và kĩ sư lập trình hệ thống. Đặc biệt trong thế giới MDA, chúng còn được sử

dụng như kế hoạch tri tiết cho việc triển khai hệ thống.

Ưu điểm thứ 3 của MDA là khả năng di động, khả năng tương tác và tái sử dụng

điều này có được nhờ kiến trúc kiểu phân chia của MDA. Các vấn đề chính về thiết kế

của CIM, PIM và PSM rất khác nhau và có thể được phát triển độc lập với nhau.

Nhiều CIM, PIM và PSM có thể được sử dụng cho cùng một ứng dụng nhằm thể hiện

các mức độ sàng lọc khác nhau và các khung nhìn khác nhau.

3. MDA và các yêu cầu phi chức năng trong kiến trúc hệ thống

Các mô hình trong MDA hầu hết đều tập trung thể hiện một kiến trúc hệ thống.

Theo một ý nghĩa rộng, mô hình miền (domain model) và mô hình hệ thống (system

47

model) là sự trừu tượng các khung nhìn khác nhau của kiến trúc hệ thống. Các mô

hình sản sinh mã lệnh xử lí các thành phần khác nhau của mô hình kiến trúc cùng với

chi tiết thực thi. Các mã lệnh đó sau đó có thể được sử dụng bởi các công cụ để cấu

trúc lại kiến trúc ứng dụng.

Các yêu cầu phi chức năng (non functional requirement or NFR) là trở ngại chính

của kiến trúc hệ thống. NFR liên quan tới những nhân tố chất lượng như: hiệu suất,

khả năng tái sử dụng, khả năng di động, khả năng tương tác, tính khả chuyển và bảo

mật. Mặc dù MDA không trực tiếp chỉ ra các nhân tốt chất lượng này nhưng nó giúp

hệ thống đạt được các nhân tố đó:

- Một mức độ nhất định của các nhân tố ở trên (hiệu suất, khả năng tái sử dụng…)

được xây dựng trong tất cả các mô hình thông qua sự phân tách các thành phần MDA

như đã trình bày ở trên.

- MOF và UML cho phép mở rộng các yêu cầu và các thành phần thiết kế nhắm tới

các yêu cầu phi chức năng.

- Các quy tắc tạo lập mô hình giúp ích cho việc giải quyết các nhân tố chất lượng

trong suốt các sự chuyển đổi mô hình.

48

Chương IV. THIẾT KẾ KIẾN TRÚC PHẦN MỀM VỚI NGÔN NGỮ UML

1. Sự ra đời của UML

Đầu thập kỷ 90, trước khi UML ra đời, có một vài ngôn ngữ mô hình hoá:

- Grady Booch’s Booch Modeling Methodology

- James Rambaugh’s Object Modeling Technique – OMT

- Ivar Jacobson’s OOSE Methodology

- Hewlett- Packard’s Fusion

- Coad and Yordon's OOA and OOD

Mỗi ngôn ngữ trên đều có hệ thống ký hiệu riêng, phương pháp xử lý riêng và

công cụ hỗ trợ riêng, và có điểm mạnh, điểm yếu riêng. Các nhà phát triển phần mềm

thường sử dụng phối hợp các điểm mạnh của mỗi phương pháp cho ứng dụng của

mình. Trong thực tế, sự khác biệt giữa các phương pháp đó hầu như không đáng kể và

theo cùng tiến trình thời gian, tất cả những phương pháp trên đã tiệm cận lại và bổ

sung lẫn cho nhau. Mặt khác, một nhu cầu nảy sinh từ thực tế là cần có một tiếng nối

chung (ngôn ngữ chung) cho các nhà phát triển phần mềm để mô hình hóa hệ thống.

Vì vậy, những người tiên phong trong lĩnh vực mô hình hoá hướng đối tượng đã ngồi

lại cùng nhau để tích hợp những điểm mạnh của mỗi phương pháp và đưa ra một mô

hình thống nhất cho lĩnh vực công nghệ phần mềm. Dẫn đến sự ra đời của ngôn ngữ

UML (Unified Modeling Language) là ngôn ngữ mô hình hóa hợp nhất từ các cách kí

hiệu của OMT, Booch91 và OOSE cũng như các ý tưởng tốt nhất của một số phương

pháp khác.

2. Mục đích của UML

- Mô hình hoá các hệ thống sử dụng các khái niệm hướng đối tượng.

- Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá.

- Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng

buộc khác nhau.

Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy.

3. Đặc điểm của UML

- UML là ngôn ngữ dùng để trực quan hóa: Khi không có ngôn ngữ mô hình hóa

trực quan thì việc trao đổi về các ý tưởng giữa những người lập trình sẽ gặp khó khăn.

Việc xây dựng mô hình sử dụng ngôn ngữ UML đã giải quyết được các khó khăn trên.

49

Khi trở thành một chuẩn trong việc lập mô hình, mỗi kí hiệu mang một ý nghĩa rõ

ràng và duy nhất, một nhà phát triển có thể đọc được mô hình xây dựng bằng UML do

một người khác viết. Những cấu trúc mà việc nắm bắt thông qua đọc mã lệnh là khó

khăn nay đã được thể hiện trực quan.

- Cụ thể hóa: UML cho phép xây dựng các mô hình một các tỉ mỉ, rõ ràng, đầy đủ ở

các mức độ chi tiết khác nhau. Đặc biệt là UML thực hiện việc chi tiết hoá tất cả các

quyết định quan trọng trong phân tích, thiết kế và thực thi một hệ thống phần mềm.

- Sinh mã ở dạng nguyên mẫu : Các mô hình xây dựng bởi UML có thể ánh xạ tới

một ngôn ngữ lập trình cụ thể như : Java, C++... thậm chí cả các bảng trong một

CSDL quan hệ hay CSDL hướng đối tượng. UML cho phép cập nhật một mô hình từ

các mã thực thi.( ánh xạ ngược). Điều này tạo ra sự nhất quán giữa mô hình của hệ

thống và các đoạn mã thực thi mà ta xây dựng cho hệ thống đó.

- Lập và cung cấp tài liệu: Một tổ chức phần mềm ngoài việc tạo ra các đoạn mã

lệnh( thực thi) thì còn tạo ra các tài liệu: Ghi chép về các yêu cầu của hệ thống, kiến

trúc của hệ thống, thiết kế , mã nguồn, kế hoạch dự án, tests, các nguyên mẫu, …

UML sẽ cho ta biết cách tạo ra và đọc hiểu được một mô hình đươc cấu trúc tốt,

nhưng nó không cho ta biết những mô hình nào nên tạo ra và khi nào tạo ra chúng. Đó

là nhiệm vụ của quy trình phát triển phần mềm.

4. Các thành phần của UML

4.1 Hướng nhìn (quan sát)

Hướng nhìn (view): là sự trừu tượng hóa gồm các biểu đồ khác nhau. Mỗi hướng

nhìn chỉ ra một khía cạnh riêng biệt của hệ thống. Các hướng nhìn nối kết ngôn ngữ

mô hình hóa với quy trình được chọn cho giai đoạn phát triển.

50

Hình 4.1 Các hướng nhìn trong UML

- Hướng nhìn ca sử dụng(Use-Case View): Chỉ ra khía cạnh chức năng của một hệ

thống, nhìn từ hướng tác nhân bên ngoài. Bao gồm các Use Case mô tả ứng xử của hệ

thống theo cách nhìn nhận của người dùng, người phân tích hệ thống. Nó không chỉ ra

cách cấu trúc của hệ thống phần mềm, nó chỉ dùng để nhìn nhận một cách tổng quát

những gì mà hệ thống sẽ cung cấp, thông qua đó người dùng có thể kiểm tra xem các

yêu cầu của mình đã được đáp ứng đầy đủ hay chưa hoặc có chức năng nào của hệ

thống là không cần thiết. Hướng nhìn Use case mang tính trung tâm, bởi nó đặt ra nội

dung thúc đẩy sự phát triển các hướng nhìn khác. Hướng nhìn Use case là hướng nhìn

dành cho khách hàng, nhà thiết kế, nhà phát triển và người thử nghiệm; nó được miêu

tả qua các biểu đồ Use case (use case diagram) và thỉnh thoảng cũng bao gồm cả các

biểu đồ hoạt động (activity diagram)

- Hướng nhìn logic (Logical View): Chỉ ra chức năng sẽ được thiết kế bên trong hệ

thống như thế nào, qua các khái niệm về cấu trúc tĩnh cũng như ứng xử động của hệ

thống. Được dùng để xem xét các phần tử bên trong hệ thống và mối quan hệ, sự

tương tác giữa chúng để thực hiện các chức năng mong đợi của hệ thống. Cấu trúc

tĩnh được miêu tả bằng các biểu đồ lớp (class diagram) và biểu đồ đối tượng (object

diagram). Quá trình mô hình hóa động được miêu tả trong các biểu đồ trạng thái (state

diagram), biểu đồ trình tự (sequence diagram), biểu đồ tương tác (collaboration

diagram) và biểu đồ hoạt động (activity diagram). Hướng nhìn logic được sử dụng

cho các nhà thiết kế và nhà phát triển.

51

- Hướng nhìn song song (Concurrency View) (hay hướng nhìn tương tranh Process

View): Chia hệ thống thành các tiến trình(process) và luồng(thread), mô tả việc đồng

bộ hóa và các xử lý đồng thời. Dùng cho người phát triển và tích hợp hệ thống, bao

gồm các biểu đồ sequence, collaboration, activity và state.

- Hướng nhìn thành phần (Implementation View): Bao gồm các component và file

tạo nên hệ thống vật lý. Nó chỉ ra sự phụ thuộc giữa các thành phần này, cách kết hợp

chúng lại với nhau để tạo ra một hệ thống thực thi.

- Hướng nhìn triển khai (Deployment View): Chỉ ra cấu hình phần cứng mà hệ

thống sẽ chạy trên đó. Nó thể hiện sự phân tán, cài đặt các phần mà tạo nên kiến

trúcvật lý của hệ thống. Biểu đồ được sử dụng là biểu đồ Deployment.Ngoài các

hướng nhìn kể trên, ngành công nghiệp phần mềm còn sử dụng cả các hướng nhìn

khác, ví dụ hướng nhìn tĩnh-động, hướng nhìn logic-vật lý, quy trình nghiệp vụ

(workflow) và các hướng nhìn khác.

Tùy theo đặc điểm của hệ thống mà người phát triển hệ thống sẽ quyết định là cần

mô tả nó dười góc nhìn nào, vận dụng các biểu đồ nào. Nếu hệ thống nhỏ gọn được

cài đặt trên một máy tính đơn thì mô tả nó dưới 2 góc nhìn là góc nhìn ca sử dụng và

góc nhìn thiết kế là đủ. Nếu là hệ thống phản ứng theo sự kiện thì phải chú ý thêm góc

nhìn quá tình. Nếu hệ thống là một hệ khách hàng / dịch vụ thì phải đề cập đến góc

nhìn thực thi và góc nhìn bố trí để mô tả phương tiện vật lý của hệ thống.

4.2. Phần tử cấu trúc

Phần từ cấu trúc là các danh từ trong mô hình UML. Chúng là bộ phận tĩnh của mô

hình để biểu diễn các thành phần khái niệm hay vật lý. Có bảy loại phẩn tử cấu trúc

như mô tả sau đây:

- Lớp: mô tả tập các đối tượng cùng chung thuộc tinh, thao tác, quan hệ và ngữ

nghĩa. Một lớp cài đặt một hay nhiều ghép nối.

- Giao diện: là tập hợp các thao tác làm dịch vụ của lớp hay thành phần. Giao diện

mô tả hành vi thấy được từ ngoài của thành phần. Giao diện biểu diễn toàn bộ hay một

phần hành vi của lớp. Giao diện định nghĩa tập đặc tả thao tác chứ không định nghĩa

52

cài đặt của chúng. Giao diện thường không đứng một mình mà được gắn vào lớp hay

thành phần thực hiện giao diện.

- Thành phần: 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.

- Trường hợp sử dụng (Use case): Mô tả trình tự các hành động mà hệ thống sẽ thực

hiện để đạt được một kết quả cho tác nhân nào đó. Tác nhân là những gì bên ngoài

tương tác với hệ thống. Tập hợp các Use Case của hệ thống sẽ hình thành các trường

hợp mà hệ thống được sử dụng.

- Nút (node): là 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 các tài nguyên tính toán. Có thể đặt tập các thành phần trên nút chuyển từ nút này

sang nút khác. Nút có thể là máy tính, thiết bị phần cứng.

4.3 Phần tử hành vi

Phần tử hành vi là bộ phận động của mô hình UML. Chúng là các động từ của mô

hình, biểu diễn hành vi theo thời gian và không gian.

- Tương tác: là hành vi bao gồm tập các thông điệp trao đổi giữa các đối tượng trong

ngữ cảnh cụ thể để thực hiện mục đích cụ thể. Hành vi của nhóm đối tượng hay của

mỗi thao tác có thể được chỉ ra bằng tương tác.

- Máy trạng thái: là hành vi chỉ ra trật tự các trạng thái mà đối tượng hay tương tác

sẽ đi qua để đáp ứng sự kiện. Hành vi của lớp hay cộng tác của lớp có thể được xác

định bằng máy trạng thái. Máy trạng thái kích hoạt nhiều phần tử, bao gồm trạng thái,

chuyển tiếp (từ trạng thái này sang trạng thái khác), sự kiện và các hoạt động (đáp ứng

sự kiện).

Hình 4.2 Phần tử hành vi và trạng thái

4.4 Phần tử nhóm

Phần tử nhóm là bộ phận tổ chức của mô hình UML.

53

Gói (package): là cơ chế đa năng để tổ chức các phần tử vào nhóm. Các phần tử

cấu trúc, hành vi và ngay cả phần tử nhóm có thể cho vào gói. Không giống thành

phần (component), phần tử nhóm hoàn toàn là khái niệm, có nghĩa rằng chúng chỉ tồn

tại vào thời điểm phát triển hệ thống chứ không tồn tại vào thời gian chạy chương

trình

4.5 Chú thích (annotaitonal)

Phần tử chú thích là bộ phận chú giải của mô hình UML. Đó là lời giải thích áp dụng

để mô tả các phần tử khác trong mô hình. Phần tử chú thích được gọi là ghi chú

(note).

Hình 4.3 Gói và chú thích

4.6 Các quan hệ trong UML

- Phụ thuộc (dependency): là quan hệ ngữ nghĩa hai phần tử trong đó thay đổi phần tử

độc lập sẽ tác động đến ngữ nghĩa của phần tử phụ thuộc.

- Kết hợp (association): là quan hệ cấu trúc để mô tả tập liên kết (một liên kết là kết

nối giữa các đối tượng). Khi đối tượng của lớp này gửi/nhận thông điệp đến/từ đối

tượng của lớp kia thì ta gọi chúng là có quan hệ kết hợp.

- Tụ hợp (aggregation): là dạng đặc biệt của kết hợp, nó biểu diễn quan hệ cấu trúc

giữa toàn thể và bộ phận.

54

- Quan hệ hợp thành (composition): nếu như đối tượng toàn thể bị hủy bỏ thì các đối

tượng bộ phận của nó cũng bị hủy bỏ theo.

- Khái quát hóa (generalization): là quan hệ đặc biệt hóa/ khái quát hóa mà trong đó

đối tượng cụ thể sẽ kế thừa các thuộc tính và phương pháp của đối tượng tổng quát.

- Hiện thực hóa (realization): là quan hệ ngữ nghĩa giữa giao diện và lớp (hay thành

phần) hiện thực lớp; giữa UC và hợp tác hiện thực UC.

4.7 Biểu đồ

Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa được sắp xếp để

minh họa một thành phần cụ thể hay một khía cạnh cụ thể của hệ thống. Một biểu đồ

là một thành phần của một hướng nhìn cụ thể; và khi được vẽ ra, nó thường thường

cũng được xếp vào một hướng nhìn. Mặt khác, một số loại biểu đồ có thể là thành

phần của nhiều hướng nhìn khác nhau, tùy thuộc vào nội dung của biểu đồ.

Một mô hình hệ thống thường có nhiều loại biểu đồ, mỗi loại có nhiều biểu đồ khác

nhau.

a. Biểu đồ trường hợp sử dụng (Use case – UC)

Biểu đồ UC chỉ ra chức năng tổng thể của hệ thống đang phát triển. Khách hàng,

quản lý dự án, phân tích viên, lập trình viên, kỹ sư kiểm tra chất lượng và những ai

quan tâm tổng thể đến hệ thống đều có thể biết được hệ thống sẽ hỗ trợ gì thông qua

biểu đồ này.

Ví dụ:

55

Hình 4.4 Biểu đồ Use Case mẫu

Trong hình trên cho ta thấy các chức năng của hệ thống rút tiền tự động ATM:

Khách hàng (là tác nhân) có thực hiện các chức năng Rút tiền, Gửi tiền, Chuyển tiền,

Xem số dư tài khoản, Thay đổi số căn cước cá nhân (PIN) và Thanh toán. Nhân viên

ngân hàng (là tác nhân khác) có khả năng khởi động UC với Thay đổi số căn cước cá

nhân. Trường hợp sử dụng Thanh toán có mũi tên đi đến tác nhân ngoài là hệ thống tín

dụng: hệ thống tín dụng sẽ sử dụng thông tin trả về từ chức năng thanh toán của hệ

thống ATM. Với các sự mô tả ca sử dụng rõ ràng và đơn giản được cung cấp trên sơ

đồ như vậy, cho ta dễ dàng nhìn thấy chức năng cần thiết nào có hay không có trong

hệ thống.

b. Biểu đồ trình tự.

Biểu đồ trình tự chỉ ra luồng chức năng xuyên qua các UC, nó là biểu đồ mô tả

tương tác giữa các đối tượng và tập trung vào mô tả trật tự các thông điệp theo thời

gian.

Phân tích viên thấy được luồng tiến trình, người phát triển thấy được các đối tượng

cần xây dựng và các thao tác cho các đối tượng này, kỹ sư kiểm tra chất lượng có thể

thấy chi tiết của tiến trình đễ xây dựng qui trình thử nghiệm, kiểm tra. Biểu đồ trình tự

có ích cho mọi người tham gia dự án.

56

Ví dụ:

Hình 4.5 Ví dụ về biểu đồ trình tự

c. Biểu đồ cộng tác

Biểu đồ cộng tác chỉ ra các thông tin như biểu đồ trình tự theo cách khác, nó tập

trung vào tổ chức cấu trúc của các đối tượng gửi và nhận thông điệp. Biểu đồ cộng tác

và biểu đồ trình tự thuộc loại biểu đồ tương tác và chúng có thể biến đổi qua lại. Các

đối tượng giao tiếp trực tiếp với nhau được thể hiện bằng đường nối.

Qua biểu đồ cộng tác, kỹ sư kiểm tra chất lượng và kiến trúc sư hệ thống thấy

được việc phân bổ tiến trình giữa các đối tượng.

Ví dụ:

57

Hình 4.6 Ví dụ về biểu đồ tương tác

d. Biểu đồ lớp

Biểu đồ lớp chỉ ra tương tác giữa các lớp trong hệ thống. Các lớp được xem như kế

hoạch chi tiết của các đối tượng.

Người phát triển sử dụng biểu đồ lớp để xây dựng các lớp. Các công cụ phần mềm

như Rose phát sinh mã trình xương sống cho các lớp, sau đó người phát triển phải chi

tiết hóa nó bằng ngôn ngữ lập trình. Kiến trúc sư quan sát thiết kế hệ thống thông qua

biểu đồ lớp. Kiến trúc sư cũng dễ phát hiện ra nếu giữa các lớp thiếu giao tiếp.

Ví dụ:

58

Hình 4.7 Biểu đô lớp

e. Biểu đồ trạng thái (Sate transition)

Biểu đồ chuyển trạng thái mô tả vòng đời của đối tượng, từ khi nó được sinh ra

đến khi bi phá hủy. Biểu đồ chuyển trạng thái cung cấp cách thức mô hình hóa các

trạng thái khác nhau của đối tượng. Trong khi biểu đồ lớp cung cấp bức tranh tĩnh về

các lớp và quan hệ của chúng thì biểu đồ chuyển trạng thái được sử dụng để mô hình

hóa các hành vi động của hệ thống.

Thông thường, không tạo lập biểu đồ chuyển trạng thái cho mọi lớp mà chỉ sử

dụng cho các lớp phức tạp. Nếu đối tượng của lớp tồn tại trong nhiều trạng thái và có

ứng xử khác nhau trong mỗi trạng thái thì nên xây dựng biểu đồ chuyển trạng thái cho

chúng. Biểu đồ chuyển trạng thái chỉ dành cho việc làm tài liệu Rose không phát sinh

mã trình từ biểu đồ này.

Ví dụ:

59

Hình 4.8 Biểu đồ trạng thái

f. Biểu đồ thành phần (component)

Biểu đồ thành phần cho ta cái nhìn vật lý của mô hình. Biểu đồ thành phần cho ta

thấy được các thành phần phần mềm trong hệ thống và quan hệ giữa chúng. Hai loại

thành phần trong biểu đồ, đó là thành phần khả thực và thành phần thư viện. Trong

Rose, mỗi lớp mô hình được ánh xạ đến một thành phần mã nguồn.

Có thể có nhiều biểu đồ thành phần cho một hệ thống, số lượng này phụ thuộc vào

các hệ thống con của chúng. Mỗi hệ thống con là gói thành phần. Tổng quát, gói là tập

hợp các đối tượng.

Bất kỳ ai có trách nhiệm dịch chương trình đều quan tâm đến biểu đồ loại này.

Biểu đồ cho ta thấy trình tự dịch của các mođun trong hệ thống. Đồng thời nó cũng

cho biết rõ thành phần nào được tạo ra khi chạy chương trình. Biểu đồ thành phần chỉ

ra ánh xạ của lớp và các thành phần cài đặt.

Ví dụ:

60

Hình 4.9 Biểu đồ thành phần

g. Biểu đồ triển khai (deployment)

Biểu đồ triển khai chỉ ra bố trí vật lý của mạng và các thành phần hệ thống sẽ đặt ở

đâu.

Thông qua biểu đồ triển khai mà người quản lý dự án, người sử dụng, kiến trúc sư và

đội ngũ triển khai hiểu phân bổ vật lý của hệ thống và các hệ thống con sẽ được đặt ở

đâu.

Ví dụ:

Hình 4.10 Biểu đồ triển khai

61

Dựa trên tính chất của các biểu đồ, UML chia các biểu đồ thành hai lớp mô hình:

- Biểu đồ mô hình cấu trúc (Structural Modeling Diagrams): biểu diễn các cấu trúc

tĩnh của hệ thống phần mềm được mô hình hoá. Các biểu đồ trong mô hình tĩnh tập

trung biểu diễn khía cạnh tĩnh của hệ thống, lien quan đến cấu trúc cơ bản cũng như

các phần tử chính trong miền quan tâm của bài toán. Các biểu đồ trong mô hình tĩnh

bao gồm:

Biểu đồ gói

Biểu đồ đối tượng và lớp

Biểu đồ thành phần

Biểu đồ triển khai

- Biểu đồ mô hình hành vi (Behavioral Modeling Diagrams): Nắm bắt đến các hoạt

động và hành vi của hệ thống, cũng như tương tác giữa các phần tử bên trong và bên

ngoài hệ thống. Các dạng biểu đồ trong mô hình động bao gồm:

Biểu đồ use case

Biểu đồ tương tác dạng tuần tự

Biểu đồ tương tác dạng cộng tác

Biểu đồ trạng thái

Biểu đồ động

5. Giới thiệu về RUP (Rationnal Unified process)

5.1 Giới thiệu tổng quan về RUP

Quy trình phát triển phần mềm nổi bật nhất và ngày càng được sử dụng rộng rãi là

Rationnal Unified process (RUP). Mặc dù RUP mới được phát triển trong những năm

gần đây, nhưng sự xuất hiện của RUP đánh dấu một xu hướng phát triển mới trong

giai đoạn bùng nổ của ngành công nghệ phần mềm.

- Tiến trình RUP là một tiến trình mô hình hóa với UML do “ba người bạn” đưa ra,

song nó không phải là một chuẩn.

- RUP là quy trình công nghệ phần mềm được phát triển bởi hãng Rational. Mục

đích chính của RUP là giúp sản xuất phần mềm có chất lượng cao thoả mãn nhu cầu

của người dùng cuối, trong khuân khổ thời gian và ngân sách.

- Rup đảm bảo quy trình luôn được cải tiến hơn trên cơ sở những kinh nghiệm phản

hồi từ đối tác sử dụng, sự tiến hoá và những cách vận dụng tốt nhất trong thực tế.

62

- RUP sử dụng ngôn ngữ UML để mô hình hoá và cung cấp những hướng dẫn để sử

dụng UML một cách hiệu quả nhất. Hoạt động chính của RUP là tạo, cải tiến và quản

lý các loại mô hình. Ngoài ra, RUP nhấn mạnh việc phát triển những mô hình giàu

ngữ nghĩa biểu diễn hệ thống dưới góc độ của người phát triển.

Ngày nay, RUP được hỗ trợ bởi các công cụ, giúp tự động hoá phần lớn các quy

trình phát triển phần mềm. Các công cụ hỗ trợ RUP có thể kể đến là quản lý đề án,

phân công nhân sự, tạo lập và quản lý mô hình, kiểm chứng…

5.2 Kiến trúc tổng quan của RUP

Rup được tổ chức theo 2 trục: có tất cả 4 pha theo chiều dọc và 9 công đoạn trải dài xuyên suốt 4 pha theo chiều ngang.

- Trục hoành: tổ chức theo thời gian phát triển dự án, thể hiện khía cạnh động của quy trình gồm: Chu kỳ, các pha, các quá trình lặp, các cột mốc.

- Trục tung: Tổ chức theo nội dung công việc thể hiện khía cạnh tĩnh của chương trình gồm: ai (worker), như thế nào (Activities), làm cái gì (Artifacts) và khi nào (workflows).

Trong mỗi pha có các lần lặp, mỗi lần lặp gồm nhiều vòng lặp để sau khi kết thúc một lần lặp sẽ cho ra một sản phẩm cụ thể.

63

5 .3 Đặc điểm của RUP

Tiến trình RUP là một tiến trình phát triển phần mềm dựa trên nguyên tắc: “lặp và tăng trưởng, tập trung vào kiến trúc, dẫn dắt theo các ca sử dụng và khống chế bởi các nguy cơ”.

- Lặp và tăng trưởng: Dự án được cắt thành những vòng lặp hoặc giai đoạn ngắn cho phép kiểm soát dễ dàng sự tiến triển của dự án. Cuối mỗi vòng lặp thì một phần thi hành được của hệ thống được sản sinh theo cách tăng trưởng ( thêm vào) dần dần. Các công đoạn chính trong một lần lặp:Trong mỗi lần lặp, có thể bao gồm bất kỳ năm công đoạn nào từ công đoạn xác định yêu cầu đến kiểm tra. Lần lặp đầu tập trung vào những công đoạn đầu. Một lần lặp lại có thể khởi động sau hoặc trong vài trường hợp là bắt đầu ngay sau khi hoàn thành lần lặp trước. Những lần lặp lại khác nhau thực hiện mỗi workflow với mức độ chi tiết khác nhau. Những lần lặp đầu thực hiện các workflows đầu tiên sâu hơn. Những lần lặp sau thực hiện workflows sau sâu hơn. Số lượng của công việc sẽ đợc làm trong một workflow là tương đối. Workflows nào đó có thể yêu cầu nhiều công sức hơn. Đôi khi một workflow đượcchọn phụ thuộc vào yêu cầu của dự án. Ta không thể đạt được sự hoàn thiện trong mỗi lần lặp lại. Ta cần phải sử dụng quy tắc 80 / 20 (80 phần trăm của công việc có thể hoàn thành với 20 phần trăm công sức, 20 phần trăm cuối cùng của công việc có thể đạt được bởi 80 phần trăm công sức). Khi lấn lặp là 80 thì ta có thể tiếp tục chuyển sang giai đoạn khác.- Tập trung vào kiến trúc: Toàn bộ hệ thống phức tạp phải được phân chia thành từng phần (các môđun) để có thể dễ dàng triển khai và duy trì, tạo nên một kiến trúc. Kiến trúc phải được trình bày theo năm góc nhìn khác nhau bởi các biểu đồ UML. Dẫn dắt theo các ca sử dụng: RUP nhấn mạnh sự đáp ứng các nhu cầu của người dùng, thể hiện bởi các ca sử dụng. Do dó các ca sử dụng ảnh hưởng và dẫn đường cho mọi giai đoạn phát triển hệ thống. Nắm bắt yêu cầu là để phát hiện ra các ca sử dụng. Thiết kế và cài đặt là để xây dựng hệ thống theo từng ca sử dụng. Kiểm định và nghiệm thu hệ thống thực hiện theo từng ca sử dụng. Ca sử dụng là căn cứ để xác định các vòng lặp và tăng trưởng, đó cũng là căn cứ để phân công công việc trong nhóm phát triển hệ thống. - Khống chế bởi các nguy cơ: Các nguy cơ chính đối với dự án phải phát hiện sớm và phải loại bỏ càng sớm càng tốt. Yêu cầu này cũng là căn cứ để xác định thứ tự trước sau của các vòng lặp.

5.4 Các thành phần của RUP

RUP định nghĩa bốn thành phần sau:

64

- Worker: định nghĩa công việc và trách nhiệm của mỗi cá nhân, hoặc một số cá nhân làm việc với nhau trong nhóm.- Tìm các use case và các actor cho hệ thống của phân tích viên hệ thống.- Artifacts: là những thông tin được phát sinh, thay đổi hoặc sử dụng bởi quy trình.Ví dụ: Mô hình Use Case (Use Case Mode), mô hình thiết kế (Design mode), các sưu liệu (document), các thành phần thực thi.- Workflows: mô tả cách thức tiến hành các hoạt động theo trình tự và vai trò của mỗi worker.

5.5 Các pha trong tiến trình RUP

Tiến trình RUP được tổ chức thành pha nối tiếp trong thời gian là: Khởi đầu, triển khai, xây dựng và chuyển giao.

1) Pha khởi đầu(inception):

Nhằm cho cái nhìn tổng quát về hệ thống sẽ xây dựng (chức năng, hiệu năng, công nghệ, …) và về dự án sẽ triển khai ( phạm vi, mục tiêu, tính khả thi, …). Giai đoạn này cần đưa ra tình huống về mặt nghiệp vụ có thể có đối với hệ thống và xác định phạm vi của dự án. Các tình huống nghiệp vụ gồm: tiêu thức đánh giá sự thành công, đánh giá rủi ro, xác định các nguồn lực cần thiết cho dự án và một bản kế hoạch tóm tắt chỉ ra lịch trình của các điểm mốc chủ yếu của dự án. Thông thường phải xây dựng bản mẫu khái niệm cho pha khảo sát khả thi để đánh giá tính rủi ro của các chức năng phần mềm, sức mạnh và độ phức tạp của hệ thống, công nghệ mới sẽ áp dụng. Loại bản mẫu này không cần tuân thủ các quy luật phát triển phần mềm thông thường như độ tin cậy cao, tốc độ xử lý phải nhanh.Cuối pha này cần kiểm tra các mục tiêu của quá trình phát triển của dự án và đưa ra kết luận là nên phát triển hay nên loại bỏ dự án.

Với dự án nhỏ, khảo sát khả thi thường chỉ giới hạn bởi danh sách yêu cầu phần mềm. với các dự án trung bình thì pha khảo sát khả thi sẽ thực hiện trong khoảg một tháng, bao gồm cả việc xây bản mẫu makét. Với các dự án lớn, viêc xây dựng makét có thể là một dự án con và nó cũng có các bước thực hiện như mô tả ở trên.

2) pha triển khai: (elaboration)

Bao gồm sự phân tích chi tiết hơn về hệ thống chức năng, cấu trúc tĩnh ( dùng các biểu đồ ca sử dụng, biểu đồ lớp, các biểu đồ tương tác). Đồng thời một kiến trúc hệ thống cũng được đề xuất. Kiến trúc này có thể dựng thành nguyên mẫu, trên đó có thể sử dụng nhiều ý đồ đối với hệ thống.

65

Pha này bắt đầu bằng phân tích yêu cầu và mô hình hóa lĩnh vực. Phân tích các vấn đề nghiệp vụ, xác định kiến trúc hợp lý, xây dựng kế hoạch cho dự án, giới hạn các yếu tố rủi ro cao nhất. Những quyết định về mặt kiến trúc cần được đưa ra cho toàn bộ hệ thống, đồng thời cần mô tả hầu hết các yêu cầu của hệ thống. Cuối pha này cần kiểm tra các mục tiêu và phạm vi chi tiết của hệ thống, sự lựa chọn về kiến trúc và cách xử lý các rủi ro có thể đồng thời quyết định có tiếp tục chuyển sang pha xây dựng hay không.

3) Pha xây dựng (construction):

Tập trung vào việc thiết kế và thực thi ( cài đặt) hệ thống nếu pha triển khai chỉ mới cho một kiến trúc hệ thống cơ bản thì pha xây dựng kiến trúc đó được tinh tế và chi tiết hóa, có thể chỉnh sửa, tha đổi. Pha xây dựng kết thúc khi đã phát hành được (ít nhất là trong nội bộ) một hệ thống hoàn chỉnh cùng các tư liệu kèm theo. Pha xây dựng là pha kéo dài về thời gian và tổn hao về sức lực hơn cả. Pha này bao gồm việc mô tả các yêu cầu còn lại chưa được xác định, xác định các “tiêu thức chấp nhận”, làm mịn thiết kế và hoàn thành việc lập trình ứng dụng. Cuối pha này cần xác định liệu hệ thống phần mềm, các điểm triển khai và người dùng đã sẵn sàng đi vào hoạt động chưa.

4) Pha chuyển giao (transition):

Nhằm chuyển hệ thống đã xây dựng từ tay những người phát triển hệ thống tới tay các người dùng cuối, phải đảm bảo rằng phần mềm luôn sẵn sàng cho người sử dụng. Khi hệ thống đã tới tay người sử dụng thì các vấn đề thường phát sinh đòi hỏi những bước tiếp theo là căn chỉnh hệ thống, xác định các vấn đề chưa được phát hiện trước đó hay hoàn thiện các chức năng trước đó bị trì hoãn. Pha này thường bắt đầu với việc tung ra phiên bản Beta và sau đó là thay thế bởi bản chương trình đầy đủ.

Pha chuyển giao có thể trải rộng trên những lần lặp riêng và bao gồm các công việc chính sau:

- Thực thi các hoạch định phát triển.- Hoàn thành các hỗ trợ cần thiết đối với người sử dụng.- Kiểm tra sản phẩm phân phối ở vị trí phát triển.- Tạo phiên bản Release cho sản phẩm.- Lấy các phản hồi từ người sử dụng.- Hiệu chỉnh sản phẩm dựa trên phản hồi từ người sử dụng.- Phân phối sản phẩm.

Mỗi pha đặc biệt là pha xây dựng và pha triển khai lại được chia thành một số vòng lặp (kéo dài từ 2 đến 4 tuần). Mỗi vòng lặp lại hoàn thành một phần của hệ thống và trải qua một số công đoạn trong 9 công đoạn khác nhau.

66

5.6 Các công đoạn trong tiến trình RUP

Rup có 9 công đoạn sau:

Mô hình hóa nghiệp vụ hiện tại (Business modeling): mô tả cấu trúc và quy trình nghiệp vụ. Nắm bắt yêu cầu hệ thống (Requirement): mô tả nghiệp vụ bằng phương pháp “tình huống sử dụng” (use case base method) Phân tích và thiết kế (Analysis & Design). Cài đặt hệ thống (implementation). Kiểm tra sản phẩm (Test): mô tả các tình huống và kịch bản thử nghiệm, tiến hành thử nghiệm hệ thống phần mềm. Phân phối sản phẩm (devolopment). Quản lý dự án (Project managerment). Quản lý thay đổi yêu cầu và cấu hình hệ thống (Configuration & Change Mgmt): kiểm soát các thay đổi và duy trì sự hợp nhất của các thành phần dự án. Thiết lập môi trường làm việc trong toàn bộ dự án (Envirionment): đảm bảo các hạ tầng cần thiết để có thể phát triển được hệ thống.

5.7 Các mô hình và tài liệu trong RUP

Quá trình thực hiện qua toàn bộ các pha được gọi là chu trình phát triển; Kết quả của quá trình phát triển các RUP được gọi là các Artifact, bao gồm các mô hình và các bộ tài liệu, đó là:

- Mô hình nghiệp vụ: là sự trừu tượng hóa tổ chức nghiệp vụ của hệ thống cần xây dựng.- Mô hình tình huống sử dụng:(use case) các yêu cầu mang tính chức năng của hệ thống phần mềm.- Mô hình phân tích và thiết kế: mô hình tổ chức các đối tượng của hệ thống phần mềm để giải quyết vấn đề của bài toán.- Mô hình triển khai: mô hình kiến trúc phần cứng và phần mề hệ thống cần thiết để triển khai.- Mô hình thử nghiệm: xác định các bước mà hệ thống sẽ được kiểm tra.

Các tài liệu:

- Bộ tài liệu về xác định yêu cầu hệ thống: mô tả những gì hệ thống cần lầm.- Bộ tài liệu thiết kế: mô tả hệ thống sẽ được xây dựng như thế nào.- Bộ tài liệu lập trình: mô tả các thành phần ứng dụng được phát triển như thế nào.- Bộ tài liệu triển khai: mô tả cấu trúc triển khai hệ thống

Mỗi giai đoạn trong Rup bao gồm các mô hình UML khác nhau.

67

Nhìn từ khía cạnh quản lý, RUP bố trí toàn bộ thời gian vào các pha được kết thúc bằng một cột mốc. Ở cuối mỗi pha có một đánh giá kết quả thực hiện. Nếu chấp nhận dự án chuyển sang pha kế tiếp còn ngược lại thì thực hiện pha lại trên.

Hoạch định các pha: Việc hoạch định các pha không nhất thiết phải giống nhau. Đối với hệ thống vừa và nhỏ nên hoạch định các pha như sau:

  Khởi đầu Triển khai

 Xây dựng Chuyển giao

Công sức 5 % 20 % 65 % 10%

Thời gian 10 % 30 % 50 % 10%

Liều lượng cho mỗi công đoạn là tùy thuộc vòng lặp đó ở pha nào: Ở các pha đầu thì công đoạn đầu: nắm bắt yêu cầu, phân tích và thiết kế dược nhấn mạnh, ở pha cuối thì công đoạn: Thực thi, kiểm định và bố trí lại được nhấn mạnh

68

Chương V. ỨNG DỤNG THIẾT KẾ WEBSITE BÁN HÀNG SỬ DỤNG UML

A. Bài toán

Khi có yêu cầu nhập thiết bị: nhân viên tiến hành ghi phiếu yêu cầu gồm các thông

tin chi tiết về thiết bị và gửi đến cho nhà cung cấp. Nhà cung cấp sẽ gửi đơn chào

hàng chi tiết các thiết bị bao gồm các thông tin như: tên, loại thiết bị, số lượng, nguồn

gốc….Qua đơn chào hàng của nhà cung cấp thì cửa hàng sẽ đưa ra đơn đặt hàng và

gửi đến cho nhà cung cấp, để đáp ứng nhu cầu nhập thiết bị của cửa hàng nhà cung

cấp sẽ chuyển thiết bị cho cửa hàng theo hợp đồng mua,bán hàng hóa và biên lai bàn

giao thiết bị (kiêm hóa đơn thanh toán tiền thiết bị).Trước khi nhập hàng vào kho thì

cửa hàng sẽ kiểm tra xem đã đủ thiết bị chưa theo biên bản bàn giao thiết bị mà nhà

cung cấp gửi đến, đồng thời cửa hàng sẽ ghi các thông tin cần thiết vào sổ chi và sổ

kho. Nếu thiết bị nào không đạt yêu cầu thì cửa hàng sẽ trả lại nhà cung cấp, và yêu

cầu nha cung cấp cấp lại những thiết bị như hợp đồng đã thỏa thuận.

Khi khách có nhu cầu mua thiết bị, khách hàng xem thông tin hàng hóa, tìm kiếm

hàng cần mua. Nếu khách hàng chọn được thiết bị cần mua thì cửa hàng sẽ kiểm tra

trong kho, nếu trong kho còn hàng thì nhân viết sẽ viết phiếu bán hàng và thông báo

cho khách. Khách hàng gửi tiền thanh toán cho cửa hàng qua thẻ ATM hoặc thanh

toán trực tiếp tại cửa hàng, cửa hàng sẽ lập biên lai thu tiền cho khách đồng thời sẽ ghi

các thông tin cần thiết vào sổ thu và sổ kho. Sau đó cửa hàng sẽ tiến hành bàn giao

thiết bị cho khách và gửi khách hàng hóa đơn thanh toán, phiếu bảo hành và các giấy

tờ liên quan, có kèm theo các khuyến mại(nếu có).

Để tiện cho việc quản lý hệ thống mới sẽ lưu trữ và quản lý thông tin về nhà cung

cấp và thông tin khách hàng. Có thể sửa hoặc xóa khi cần thiết. Sau một khoảng thời

gian nhất định nhân viên các bộ phận sẽ tổng hợp thông tin mua, bán, và các thông tin

khác. Quản trị viên là người có quyền cao nhất, có quyền cấp phát hoặc thu hồi các tài

khoản của nhân viên cũng như khách hàng.

B. Phân tích

I. Các tác nhân

Tác nhân gồm có:

69

1. Khách hàng

2. Nhân viên

3. Quản trị viên

I. Các chức năng chính

1. Quản lý hàng bán

Tác nhân: Nhân viên.

Điểu kiện: Phải đăng nhập vào hệ thống.

Mô tả: Ca sử dụng bắt đầu khi nhân viên đăng nhập vào hệ thống. Dựa vào yêu cầu

của khách hàng, nhân viên sẽ lập hóa đơn bán hàng với các thông tin của khách hàng:

tên khách hàng, địa chỉ, điện thoại, email và kiểm tra hàng trong kho xem có còn hay

đáp ứng được không (tìm hàng), nếu đáp ứng được thì sẽ giao hàng cho khách hàng và

cập nhật thông tin hàng bán , khách hàng vào hệ thống. Nếu hàng trong kho không

đáp ứng được thì thông báo cho khách hàng.

2. Quản lý hàng nhập

Tác nhân: Nhân viên

Điều kiện: Phải đăng nhập vào hệ thống.

Mô tả: Sau một thời gian định kỳ, cửa hàng sẽ nhập thêm hàng mới. Nhân viên lập

hóa đơn yêu cầu nhập hàng gồm thông tin về hàng muốn nhập gồm: tên hàng nhập, số

lượng nhập, tên nhà cung cấp. Bên nhà cung cấp sẽ cung cấp hàng theo yêu cầu cho

cửa hàng. Nhưng trước khi nhận hàng, nhân viên sẽ kiểm tra hàng xem có đáp ứng cả

về chất lượng và số lượng không. Nếu không đảm bảo một trong các yêu cầu thì nhân

viên sẽ từ chối nhập. Sau đó nhân viên sẽ lập hóa đơn nhập hàng gồm: tên hàng nhập,

số lượng nhập, đơn giá nhập, ngày nhập, nhà cung cấp.

3. Quản lý khách hàng

Tác nhân: Nhân viên

Điều kiện: Đăng nhập được vào hệ thống.

70

Khách hàng sau khi mua hàng tại công ty sẽ được lưu lại thông tin: tên khách

hàng, địa chỉ, điện thoại. Khách hàng sẽ được xếp vào các nhóm khách hàng khách

nhau tương ứng với giá trị hàng mua, dựa giá trị hàng mua khách nhau khách hàng sẽ

được giảm giá tương ứng theo các chương trình khuyến mại (nếu có).

4. Quản lý nhà cung cấp

Tác nhân: Nhân viên

Điều kiện: Đăng nhập được vào hệ thống.

Nhà cung cấp cũng được quản lý như khách hàng gồm: tên nhà cung cấp, địa chỉ,

điện thoại, mặt hàng cung cấp.

5. Báo cáo thông kê

Tác nhân: Nhân viên

Điều kiện: Đăng nhập được vào hệ thống.

Hàng tháng nhân viên sẽ thực hiện lập báo cáo thống kê hàng nhập, thống kê hàng

bán, thống kê doanh thu dựa vào hóa đơn bán hàng và nhập hàng hàng tháng.

6. Quản lý quyền truy nhập

Tác nhân: Quản trị viên

Điều kiện: Đăng nhập được vào hệ thống.

Quản trị viên sẽ đăng nhập vào hệ thống. Chọn các chức năng cấp phát quyền, thay

đổi quyền, xóa quyền của các nhân viên cửa hàng và khách hàng.

7. Mua hàng

Tác nhân: Khách hàng

Điều kiện: Đăng nhập được vào hệ thống

Sau khi chọn được các mặt hàng muốn mua, khách hàng có tài khoản sẽ đăng nhập

vào hệ thống hoặc đăng kí mới tài khoản rồi đăng nhập (nếu chưa có), sau đó khác

hàng thực hiện gửi thông tin đơn hàng cho cửa hàng gồm: mã hàng, số lượng, mã

khách hàng. Các thông tin này sẽ được lưu lại trên hệ thống và sau đó được kiểm

tra bởi nhân viên cửa hàng.

8. Quản lí tài khoản

71

Tác nhân: khách hàng, nhân viên, quản trị viên

Khách hàng, nhân viên và quản trị viên tiến hàng đăng nhập vào hệ thống xem và

cập nhật thông tin cá nhân, mật khẩu thông qua chưc năng này.

9. Đăng nhập

Tác nhân: nhân viên, quả trị viên, khách hàng

Tác nhân thực hiện đăng nhập vào hệ thống để thực hiện các thao tác quản lí.

10. Đăng xuất

Tác nhân: nhân viên, quả trị viên, khách hàng

Tác nhân đăng xuất khỏi hệ thống, kết thúc phiên làm việc.

11. Đăng kí tài khoản

Tác nhân: khách hàng

Khách hàng đăng kí tài khoản với các thông tin: username, password, tên, địa chỉ,

email, số điện thoại (tài khoản nhân viên được cấp bởi quản trị viên, tài khoản

quản trị viên được khởi tạo bởi phía nhà cung cấp phần mềm khi bàn giao sản

phẩm).

II. Đặc tả ca sử dụng

1. Ca sử dụng quản lý bán hàng

Tóm tắt : Mô phỏng quá trình lập hóa đơn và bán hàng cho khách

Actor: nhân viên

Dòng sự kiện: Ca sử dụng bắt đầu khi nhân viên đăng nhập vào hệ thống. chọn

chứa năng thêm hóa đơn bán hàng. Hệ thống hiện thị form yêu cầu nhân viên nhập các

thông tin của khách hàng: tên khách hàng, địa chỉ, điện thoại, hệ số giảm. thông tin

hàng bán: tên hàng bán, số lượng, giá bán, thông tin hóa đơn: tên hàng, số lượng, giá

bán, ngày lập, nhân viên lập, tổng tiền. Nhân viên có thể nhập trực tiếp mà hàng hoặc

chọn chức năng tìm kiếm để tìm kiếm hàng. Hệ thống lưu các thông tin vào csdl. Nếu

các thông tin nhập lỗi thì hệ thống sẽ hiện thị thông báo lỗi yêu cầu nhân viên kiểm tra

và nhập lại. Ngoài ra nhân viên có thể xem, sửa, xóa các hóa đơn đã nhập.

2. Ca sử dụng quản lý nhập hàng

72

Tóm tắt: Mô tả quá trình nhập hàng vào kho.

Actor : nhân viên

Dòng sự kiên: Ca sử dụng khi nhân viên đăng nhập vào hệ thống và chọn chức

năng nhập hàng. Hệ thống hiển thị form nhập hàng. Nhân viên nhập các thông tin về

hàng nhập : mã hàng nhập, tên hàng nhập, số lượng nhập, đơn giá nhập, tên nhà cung

cấp, ngày nhập. Hệ thống kiểm tra thông tin nhập và thực hiện lưu thông tin vào csdl.

Nếu các thông tin không hợp lệ hệ thống sẽ thông báo lỗi và yêu cầu nhân viên kiểm

tra các thông tin, và nhập lại. Ngoài ra nhân viên có thể xem, sửa, xóa các mặt hàng

đã nhập.

3. Ca sử dụng quản lý khách hàng

Tóm tắt: Mô tả quá trình lập báo cáo hàng nhập

Actor : nhân viên

Dòng sự kiện : Ca sử dụng bắt đầu khi nhân viên chọn chức năng quản lý khách

hàng. Hệ thống hiển thị màn hình quản lý khách hàng. Nhân viên chọn các chức năng

thêm, sửa, xóa thông tin khách hàng, thay đổi nhóm khách hàng, hệ số giảm khi mua

hàng.

4. Ca sử dụng quản lý nhà cung cấp

Tóm tắt: Mô tả quá trình quản lý nhà cung cấp

Actor : nhân viên

Dòng sự kiện : Ca sử dụng bắt đầu khi nhân viên chọn chức năng quản lý nhà cung

cấp. Hệ thống hiển thị màn hình quản lý nhà cung cấp. Nhân viên chọn các chức năng

thêm, sửa, xóa thông tin nhà cung cấp. Hệ thống thực hiện lưu những thay đổi.

5. Ca sử dụng Báo cáo thông kê

Tóm tắt: Mô tả quá trình lập báo cáo hàng bán

Actor : Nhân viên

73

Dòng sự kiện: Ca sử dụng bắt đầu khi nhân viên đăng nhập vào hệ thống và chọn

chức năng báo cáo thống kê, sau đó nhân viên có thể chọn thống kê theo hàng nhập,

hàng bán, doanh thu.

6. Ca sử dụng quản lý quyền truy nhập

Tóm tắt: Mô tả quá trình quản trị quyền truy cập hệ thống

Actor : Quản trị viên

Dòng sự kiện: Ca sử dụng bắt đầu khi quản trị viên đăng nhập vào hệ thống. Hệ

thống hiện thị màn hình làm việc của quản trị viên. Quản trị viên có thể thực hiện cấp

quyền, thay đổi quyền, xóa quyền của các người dùng. Hệ thống thực hiện lưu thay

đổi vào csdl.

7. Ca sử dụng mua hàng

Khách hàng truy cập website, xem các mặt hàng trên website và chọn các mặt

hàng muốn mua sau đó chọn chức năng gửi thông tin đơn hàng để gưi thông tin đơn

hàng muốn mua về cho nhà cung cấp, nếu khách hàng chưa đăng nhập hệ thống sẽ

yêu cầu khách hàng đăng nhập. Khách hàng cũng có thể sửa hoặc xóa các mặt hàng

đã chọn.

8. Ca sử dụng quản lí tài khoản

Nếu khách hàng chưa có tài khoản thì khách hàng sẽ chọn chức năng đăng kí để

đăng kí mới tài khoản với các thông tin username, password, họ tên, số điện thoại, địa

chỉ, email. Quản trị viên, nhân viên và khách hàng sau khi đăng nhập đều có thể sử

dụng chức năng xem hoặc cập nhật thông tin tài khoản, đăng xuất khỏi hệ thống.

9. Ca sử dụng đăng nhập

Ca sử dung bắt đầu khi quản trị viên, nhân viên hoặc khách hàng truy cập website

và chon chức năng đăng nhập. Form đăng nhâp hiển thị và người sử dụng điền

username và password để đăng nhập hệ thống.

10. Ca sử dụng đăng xuất

Sau khi đăng nhập vào hệ thống, người dùng bấm nút “Log out”, thông tin phiên

làm việc của người dùng bị xóa bỏ và người dùng trở về trạng thái chưa đăng nhập.

11. Ca sử dụng đăng kí tài khoản

74

Khách hàng truy cập website, bấm vào nút “Đăng kí”, hệ thống hiển thị form đăng

kí gồm các thông tin: username, password, tên, địa chỉ, số điện thoại, email. Khách

hàng điền các thông tin yêu cầu sau đó bấm nút “Hoàn tất đăng kí” để hoàn thành quá

trình đăng kí. Nếu quá trình khách hàng thao tác gặp lỗi hệ thống sẽ hiển thị thông

báo.

III. Các loại biểu đồ thiết kế kiến trúc

Khi thiết kế kiến trúc ta tập trung vào tổng quan hệ thống, qua phân tích xác định các usecase của hệ thống, ta xem xét tới việc xác định gói các lớp trong kiến trúc hệ thống, xây dựng biểu đồ gói, biểu đồ thành phần và biểu đồ triển khai. Trong tiến trình thiết kế kiến trúc ta không quá chú trọng tới chi tiết các lớp cũng như các biểu đồ hành vi của hệ thống. Các biểu đồ này sẽ được xem xét ở phần thiết kế chi tiết hệ thống.

1. Biểu đồ Use case

a) Biểu đồ use case mức tổng quan

75

b) Biểu đồ use case mở rộng trên Ql ban hang

c) Biểu đồ use case mở rộng trên QL nhap hang

76

77

d) Biểu đồ use case mở rộng trên QL khach hang

e) Biểu đồ use case mở rộng trên QL nha cung cap

78

f) Biểu đồ use case mở rộng trên Bao cao, thong ke

g) Biểu đồ use case mở rộng trên Bao QL tai khoan

79

h) Biểu đồ use case mở rộng trên QL quyen truy nhap

i) Biểu đồ use case mở rộng trên Mua hang

80

2. Biểu đồ gói (các lớp) – Theo mô hình MVC

a) Các gói tổng quan

b) Gói giao diện

81

c) Gói điều khiển

d) Gói dữ liệu

82

3. Biểu đồ thành phần

6.Biểu đồ triển khai

May Quan Tri Vien

May Nhan Vien

May Khach Hang

May In Application Server

CSDL

83

KẾT LUẬN

Các vấn đề liên quan tới kiến trúc phần mềm vẫn luôn dành được sự quan tâm đặc biệt đối với các tổ chức phát triển phần mềm trên toàn thế giới, đặc biệt nó đã và đang trở thành một vấn đề cấp bách đối với các nhà phát triển phần mềm Việt Nam. Các kiến trúc sư phần mềm được đào tạo bài bản sẽ góp phần không nhỏ giúp ngành công nghệ thông tin Việt Nam sánh ngang với các cường quốc công nghệ thông tin khác trên thế giới. Hứa hẹn một tương lai mới cho các sinh viên công nghệ thông tin nói chung và công nghệ phần mềm nói riêng.

Sau 2 tháng nỗ lực hết mình để hoàn thành đề tài dưới sự hướng dẫn của cô Lan và các thầy cô khác trong bộ môn, em tự nhận thấy mình đã đạt được một số kết quả và hạn chế như sau:

Những kết quả đạt dược:

Nghiên cứu, hiểu và lắm được các vấn đề cơ bản về kiến trúc phần mềm, các kiến trúc phần mềm hiện đại, xây dựng kiến trúc phần mềm với UML.

Báo cáo chi tiết đề tài Rèn luyện khả năng đọc hiểu tiếng Anh và cải thiện khả năng dịch thuật

Hạn chế:

Trong thời gian giới hạn của đề tài (cũng như đề tài này mới ở mức nghiên cứu phương pháp luận), em vẫn chưa xây dụng được hệ thống thống phần mềm thực sự theo các kiến trúc phần mềm đã tìm hiểu, em dự định sẽ xây dựng hệ thống này trong đợt thực tập tốt nghiệp sắp tới.

Một lần nữa em xin chân thành cảm ơn sự giúp đỡ của thầy cô và rất mong nhận được nhiều sự đóng góp hơn nữa giúp đề tài được hoàn thiện hơn.

Sinh viên

Nguyễn Đức Trọng

84

TÀI LIỆU THAM KHẢO

1. Essential Software Architecture (2nd edition) – Lan Gorton

2. Microsot Application Architecture Guide (2nd edition) – Microsoft

3. An Introduction to Software Architecture - David Garlan and Mary Shaw

4. Bài giản phát triển phần mềm hướng đối tượng với UML – Ngô Thị Lan (ĐH

CNTT & TT Thái Nguyên)

85