Ví dụ giai đoạn thiết kế kiến trúc Architecture Design - AD sẽ thực hiệnchuyển hóa các đặc tả yêu cầu phần mềm Software Requirement Specification -SRS thành các mô tả thiết kế kiến trúc
Trang 2ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
LUẬN VĂN THẠC SĨ
NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Phạm Ngọc Hùng
Hà Nội - 2011
Trang 3MỤC LỤC
DANH MỤC HÌNH VẼ v
DANH MỤC BẢNG vi
CHƯƠNG 1: GIỚI THIỆU 1
1.1 Đặt vấn đề 1
1.2 Nội dung nghiên cứu 3
1.3 Cấu trúc luận văn 3
CHƯƠNG 2: TỔNG QUAN VỀ THIẾT KẾ KIẾN TRÚC PHẦN MỀM 5
2.1 Định nghĩa về kiến trúc phần mềm 5
2.2 Các thành phần chính trong thiết kế kiến trúc phần mềm 5
2.2.1 Thành phần 7
2.2.2 Kết nối 7
2.2.3 Giao diện 10
2.2.4 Cấu hình 11
2.3 Một số kiểu kiến trúc điển hình 11
2.4 Các bước thiết kế kiến trúc phần mềm 13
2.5 Đánh giá ưu nhược điểm của SAD 22
CHƯƠNG 3: TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ, XỬ LÝ ẢNH TRONG Y TẾ 24
3.1 Quy trình khám, chữa bệnh 24
3.2 Phân tích xử lý nghiệp vụ 25
CHƯƠNG 4: THIẾT KẾ KIẾN TRÚC CHO HỆ THỐNG QUẢN LÝ, XỬ LÝ ẢNH TRONG Y TẾ 29
4.1 Thiết kế kiến trúc tổng thể cho hệ thống 29
4.2 Thiết kế cho chức năng lớn trong hệ thống 34
CHƯƠNG 5: CÀI ĐẶT KIẾN TRÚC PHẦN MỀM 40
5.1 Cách thức cài đặt kiến trúc phần mềm 40
5.2 Phương pháp đi từ thiết kế kiến trúc tới thiết kế chi tiết 40
5.3 So sánh SAD và SDD 43
KẾT LUẬN 45
TÀI LIỆU THAM KHẢO 47
PHỤ LỤC 48
Trang 4BẢNG CÁC CHỮ VIẾT TẮT
basic 6.0
thống nhất
Trang 5DANH MỤC HÌNH VẼ
Hình 1.1: Mô hình phát triển phần mềm hình chữ V [5] 1
Hình 2.1: Thiết kế kiến trúc phần mềm hệ thống quản lý thông tin bệnh nhân 6
Hình 2.2: Không gian tùy chọn của thủ tục gọi kết nối [2] 8
Hình 2.3: Không gian tùy chọn của kết nối sự kiện [2] 9
Hình 2.4: Không gian tùy chọn của kết nối truy cập dữ liệu [2] 10
Hình 2.5: Kiến trúc gọi trả lại [2] 11
Hình 2.6: Kiến trúc phân tầng [2] 12
Hình 2.7: Các bước thiết kế kiến trúc phần mềm [3] 15
Hình 3.1: Quy trình khám chữa bệnh 24
Hình 3.2: Sơ đồ ca sử dụng của chức năng quản lý thông tin bệnh nhân 26
Hình 3.3: Sơ đồ ca sử dụng của chức năng quản lý quá trình chụp ảnh 26
Hình 3.4: Sơ đồ ca sử dụng của chức năng thao tác với ảnh 27
Hình 4.1: Kịch bản chụp ảnh 31
Hình 4.2: Kiến trúc tổng thể của hệ thống 33
Hình 4.3: Tình huống người dùng, nghiệp vụ, hệ thống trên màn hình kết nối ảnh 36
Trang 6DANH MỤC BẢNG
Bảng 2.1: Các thành phần trong thiêt kế kiến trúc hệ thống quản lý thông tin
bệnh nhân 6
Bảng 2.2: Đặc điểm của kiểu kiến trúc gọi trả lại 12
Bảng 2.3: Đặc điểm của kiểu kiến trúc phân tầng 13
Bảng 2.4: Khung kiến trúc của các điểm nổi bật [3] 18
Bảng 4.1: Đặc điểm của thiết kế kiến trúc tổng thể 34
Bảng 4.2: Đặc điểm của các thành phần trong thiết kế kiến trúc khi mở màn hình kết nối 38
Bảng 5.1: Ánh xạ các thành phần trong SAD với SDD 40
Bảng 5.2: So sánh SAD với SDD 44
Trang 7CHƯƠNG 1: GIỚI THIỆU 1.1 Đặt vấn đề
Trong phát triển phầm mềm, có rất nhiều mô hình phát triển khác nhau như
mô hình thác nước, mô hình xoắn ốc, … Hiện nay, mô hình phát triển phầnmềm được sử dụng rộng rãi là mô hình chữ V, được cải tiến từ mô hình thácnước Trong mô hình phát triển phần mềm hình chữ V, các công việc được chiathành các giai đoạn khác nhau, mỗi giai đoạn sẽ thực hiện một số công việc cụthể Ví dụ giai đoạn thiết kế kiến trúc (Architecture Design - AD) sẽ thực hiệnchuyển hóa các đặc tả yêu cầu phần mềm (Software Requirement Specification -SRS) thành các mô tả thiết kế kiến trúc được thể hiện thông qua các hình vẽ, tàiliệu mô tả, … Dựa vào kết quả thiết kế kiến trúc đó, các nhà thiết kế chi tiết cóthể tạo ra các bản thiết kế chi tiết cho phần mềm, phục vụ cho quá trình cài đặtchương trình được dễ dàng, thuận tiện
Trang 8với vài chức năng cần thiết, rất khó cho bảo trì và tái sử dụng Đôi khi, chúng talàm việc có phần chủ quan và mang tính tự phát, nhưng nếu bình tĩnh nghiêncứu, làm việc có kế hoạch và áp dụng các tiến trình thiết kế phần mềm vào trongbài toán của mình, chúng ta có thể thấy được nhiều hướng đi, nhiều cách giảiquyết, mà có thể đó là những lời giải tối ưu mà trước đó chúng ta không thấyhoặc đã bỏ qua Điều quan trọng hơn cả là chúng ta có thể theo dõi và kiểm soátđược những gì đang xảy ra Thiết kế là đồng nghĩa với việc tiết kiệm thời gian
và tiền bạn Nếu không có bản thiết kế hoặc thiết kế không tốt, khi có thay đổiyêu cầu một vài chức năng trong phần mềm hoặc nâng cấp, cải tiến các chứcnăng đó, chúng ta phải làm lại một chương tình hoàn toàn mới hoặc phải nghiêncứu lại toàn bộ mã nguồn, điều đó đồng nghĩa với việc tiêu tốn của chúng ta khánhiều thời gian và tiền bạc Mặt khác dưới một góc nhìn rộng và bao quát hơn,thông qua việc phản ánh các kết quả của quá trình phân tích, thiết kế thường xácđịnh cho chúng ta nhiều hướng đi, nhiều cách thức giải quyết trên cùng một bàitoán, từ đó cho phép chúng ta chọn được cách thức tốt nhất và con đường ngắnnhất để đi tới đích [1]
Với sự phát triển nhanh của công nghệ thông tin, ngày nay nhiều lĩnh vựctrong đời sống đã được tin học hóa, giúp cho quá trình xử lý công việc nhanh vàđơn giản hơn, giúp cho tiết kiệm rất nhiều thời gian và tiền bạc
Với sự phát triển của kinh tế, ngày nay cuộc sống con người được cải thiệnrất nhiều Nhu cầu về chăm sóc, khám chữa bệnh, phát hiện, chuẩn đoán và chữatrị bệnh sớm được tăng lên, khi đó tin học là cánh tay đắc lực giúp cho việc này.Năm 2009, khi tôi đang làm việc tại công ty phần mềm FPT, chúng tôi nhậnđược đơn đặt hàng của khách hàng bên Nhật Bản, yêu cầu nâng cấp, xây dựngchức năng mới cho hệ thống quản lý, xử lý ảnh trong y tế Khi nhận được bàitoán, chúng tôi đã tiến hành khảo sát và phân tích thấy hệ thống cũ có một sốhạn chế như sau:
Thứ nhất hệ thống là một chương trình hoàn chỉnh, với mã nguồn rất lớn, hỗnđộn nhưng rất ít tài liệu mô tả về hệ thống Kiến thức về các chức năng, xử lýnghiệp vụ của hệ thống không được viết thành tài liệu, mỗi người hiểu một phầnrời rạc Khi phát triển, phần mềm được phát triển dựa trên hai công nghệ, môitrường lập trình khác nhau Phần giao diện giao tiếp với người dùng được viếtbằng VB6, sử dụng nhiều thành phần sẵn có trong VB6 Ngoài ra sử dụng rất nhiềucác thư viện của hãng thứ ba nên tính đồng nhất không cao, thường xuyên phảinâng cấp các phiên bản Cùng với thời gian phần cứng được thay đổi nhiều, khi đóVB6 không thể đáp ứng với phần cứng với các phiên bản mới hơn Mặt
Trang 9khác có nhiều loại màn hình kích thước khác nhau, chương trình phải đáp ứng
sự tùy biến sao cho phù hợp với các loại màn hình đó, việc này VB6 làm rất khókhăn, gần như không thể Hơn nữa, VB6 là ngôn ngữ lập trình hướng thủ tụcnên khả năng mở rộng kém, khi thêm các chức năng mới rất khó khăn Phầnthuật toán xử lý, lưu trữ, thao tác với ảnh thì viết bằng C++ Các phần viết rờirạc, sự sử dụng lại kém, hình như không có
Hạn chế thứ hai là quá trình bảo trì và nâng cấp vô cùng khó khăn, khi mởrộng thì mất nhiều công sức, thậm chí làm ảnh hướng tới chức năng đã có, cóthể dẫn tới xử lý sai
Những khó khăn này đặt ra cho chúng tôi phải có phương pháp đánh giá,hướng tiếp cận phù hợp để có thể nâng cấp, xây dựng chức năng mới cho phùhợp và xử lý chính xác Cuối cùng, sau một thời gian phân tích, đánh giá nghiêmtúc, chúng tôi đã tìm ra được hướng đi phù hợp, đó là phải làm tốt ngay từ giaiđoạn phân tích, thiết kế, đặc biệt là thiết kế kiến trúc phần mềm
1.2 Nội dung nghiên cứu
Luận văn tập trung nghiên cứu lý thuyết về thiết kế kiến trúc phần mềm, cácthành phần chính trong thiết kế kiến trúc phần mềm, đặc điểm của một số kiểukiến trúc phần mềm tiêu biểu, các bước thiết kế kiến trúc phần mềm và đánh giá
ưu nhược điểm của thiết kế kiến trúc phần mềm Sau đó luận văn tập trung vàoquá trình khảo sát, phân tích hệ thống quản lý, xử lý ảnh trong y tế Từ kết quảkhảo sát, phân tích đó, luận văn trình bày chi tiết quá trình áp dụng các bướcthiết kế kiến trúc phần mềm vào bài toán quản lý, xử lý ảnh trong y tế
Luận văn cũng mô cách thức cài đặt thiết kế kiến trúc phần mềm, đề xuấtphương pháp, các bước đi từ thiết kế kiến trúc tới thiết kế chi tiết sau cho hiệuquả
1.3 Cấu trúc luận văn
Các phần còn lại của luận văn có cấu trúc như sau:
Chương 2 trình bày các khái niệm cơ bản về kiến trúc phần mềm, thiết kếkiến trúc phần mềm, một số kiểu kiến trúc phần mềm tiêu biểu Sau đó trình bàycác bước thiết kế kiến trúc phần mềm và đánh giá ưu nhược điểm của thiết kếkiến trúc phần mềm
Chương 3 mô tả về quy trình khám chữa bệnh trong y tế Phân tích xử lýnghiệp vụ của hệ thống quản lý, xử lý ảnh trong y tế
Chi tiết quá trình áp dụng các bước thiết kế kiến trúc phần mềm đã nêu ở
Trang 10chương 2 để thiết kế kiến trúc cho hệ thống quản lý, xử lý ảnh trong y tế được
mô tả chi tiết trong chương 4
Chương 5 mô tả cách thức cài đặt kiến trúc phần mềm Đề xuất phương pháp, các bước đi từ thiết kế kiến trúc tới thiết kế chi tiết sao cho hiệu quả.Tóm tắt kết quả đã đạt được, trình bày những hạn chế và hướng nghiên cứu phát triển trong tương lai sẽ được trình bày trong phần kết luận
Trang 11CHƯƠNG 2: TỔNG QUAN VỀ THIẾT KẾ KIẾN TRÚC PHẦN
MỀM 2.1 Định nghĩa về kiến trúc phần mềm
Kiến trúc của hệ thống phần mềm là tập hợp các quyết định thiết kế cơ bản
về hệ thống [2] Có ba hiểu biết cơ bản về kiến trúc phần mềm là mỗi ứng dụng
có một kiến trúc, mỗi ứng dụng có ít nhất một kiến trúc sư và kiến trúc khôngphải là một giai đoạn của phát triển phần mềm
Kiến trúc phần mềm là các kế hoạch chi tiết xây dựng một hệ thống phầnmềm và tiến hóa Các quyết định thiết kế bao gồm mọi khía cạnh của hệ thốngđược phát triển bao gồm:
tổng hợp chính xác
được thực hiện một cách tuần tự chính xác
được phát tỏa chỉ cần dùng một sự kiện thông báo
bởi sự nhân bản chức năng xử lý
dựng bởi công cụ Java Swing hay Visual C#
Kiến trúc phần mềm có phạm vi rộng lớn, xuyên suốt trong quá trình pháttriển phần mềm Luận văn chỉ tập trung chủ yếu vào một thành phần quan trọngtrong kiến trúc phần mềm là thiết kế kiến trúc phần mềm
2.2 Các thành phần chính trong thiết kế kiến trúc phần mềm
Thiết kế kiến trúc phần mềm gồm bốn thành phần chính là thành phần(component), kết nối (connector), giao diện (interface) và cấu hình(configuration)
Hình 2.1 mô tả một ví dụ về kiến trúc của hệ thống quản lý thông tin bệnhnhân được thiết kế theo mô hình ba lớp gồm lớp trình diễn (Presentaion), lớp xử
lý nghiệp vụ (Business) và lớp truy cập, xử lý dữ liệu (Data Access Layer ADL) Lớp trình diễn sẽ có nhiệm vụ giao tiếp với người dùng, nhận yêu cầu từngười dùng và hiển thị kết quả cho người dùng Khi nhận được yêu cầu củangười dùng (thêm mới thông tin về bệnh nhân), lớp trình diễn sẽ yêu cầu lớp xử
-lý nghiệp vụ xử -lý và nhận kết quả trả về từ lớp nghiệp vụ, sau đó hiển thị kết
Trang 12quả cho người dùng Lớp xử lý nghiệp vụ có nhiệm vụ xử lý nghiệp vụ của bàitoán, lớp này sẽ nhận các yêu cầu của lớp trình diễn, xử lý các thao tác liên quantới nghiệp vụ, gửi yêu cầu tới tầng truy cập dữ liệu để lấy, cập nhật dữ liệu nếucần, sau đó trả kết quả về cho lớp trình diễn Lớp truy cập dữ liệu có nhiệm vụđọc, cập nhật dữ liệu từ các file hoặc cơ sở dữ liệu (CSDL) Sau đó trả về kếtquả cho lớp xử lý nghiệp vụ
Presentation
(SaveData)
In: PatientInfo Out: ErrorCode
Database (Server 2)
Interface
Hình 2.1: Thiết kế kiến trúc phần mềm hệ thống quản lý thông tin bệnh nhân.
Các thành phần ở hình 2.1 được mô tả chi tiết trong bảng 2.1 dưới đây
Bảng 2.1: Các thành phần trong thiêt kế kiến trúc hệ thống quản lý thông tin bệnh nhân
Thành phần Các lớp Presentaion, Business, DAL và CSDL (Server 1,
Trang 13Kết nối Lớp trình diễn, lớp xử lý nghiệp vụ, lớp truy cập dữ liệu
kết nối với nhau theo cơ chế truyền thông điệp của lập trìnhhướng đối tượng Riêng lớp truy cập dữ liệu sẽ kết nối với
Trang 14CSDL theo cơ chế truy cập dữ liệu để thực hiện truy vấn,cập nhật dữ liệu
Giao diện Đầu vào của lớp xử lý nghiệp vụ, lớp truy cập dữ liệu và
CSDL là các thông tin về bệnh nhân (PatientInfo) như: Mãbệnh nhân, tên bệnh nhân…
Đầu ra tương ứng của các lớp đó là các mã lỗi Khi cácphương thức (SaveData) thực thi xong sẽ trả về các mã lỗi
để cho các thành gọi tới nó có thể biết được trạng thái củaquá trình thêm mới dữ liệu là thành công hay thất bại
Cấu hình Cấu hình sẽ thiết lập các quy định để các thành phần hoạt
động với nhau Cấu hình sẽ được thể hiện một file cấu hìnhcủa hệ thống, dựa vào đó lớp truy cập dữ liệu sẽ tương tácvới dữ liệu thuộc thành phần nào (Server hay Server 2)
Sau đây mô tả chi tiết khái niệm về thành phần, kết nối, giao diện và cầuhình
2.2.1 Thành phần
Thành phần tóm lược một tập các chức năng con hoặc dữ liệu của hệ thống
và giới hạn sự truy nhập tới các tập con (thành phần con) thông qua định nghĩacác giao diện
Thành phần có thể là các hệ thống con (Sub System - SS) trong một hệ thốnglớn, hoặc các dựa án (project), gói (package) trong một SS
Trang 15Thủ tục gọi kết nối (Procedure call connectors):
Thủ tục gọi kết nối là mô hình luồng điều khiển giữa các thành phần thôngqua các kĩ thuật gọi khác nhau, là các tọa độ kết nối (coordination connectors).Ngoài ra chúng còn thực hiện truyền dữ liệu giữa các thành phần tương tác quaviệc sử dụng các tham số và giá trị trả về Ví dụ phương thức hướng đối tượng,phân nhánh và thực thi trong Unix nơi mà có môi trường giống nhau, hay sự gọilại (call back) trong sự kiện hệ thống
Các thủ tục gọi thường được dùng làm cơ sở cho kết nối hỗn hợp, chẳng hạnnhư các thủ tục gọi từ xa Không gian tùy chọn của thủ tục gọi kết nối được mô
Push from L to R Invocation record
Communication
Procedure call
Push from R to L
Has table Coordination
Multiple Entry point
Single Invocation
Explicit
Implicit
Asynchronous Synchronicity
Synchronous Cardinatily
Fan out Fan in
Private
Trang 17thành phần Không gian tùy chọn của kết nối sự kiện đƣợc mô tả chi tiết tronghình 2.3.
Cardinatily
Producers Observers Event patterns
Best effort
Delivery
Exactly once
At most once Communication
Mode
Traps
Signals Software
GUI input/output
Triggers
Trang 18Hình 2.3: Không gian tùy chọn của kết nối sự kiện [2] Kết nối truy cập dữ liệu (Data access Connector)
Kết nối truy cập dữ liệu cho phép các thành phần truy cập dữ liệu được duytrì bởi thành phần lưu trữ dữ liệu, do đó chúng cung cấp các dịch vụ truyềnthông
Trước khi quyết định lưu trữ dữ liệu phải tính đến cách thức sẽ truy cập vào dữliệu đó ra sao và sẽ dọn dẹp dữ liệu thế nào sau khi truy cập được hoàn thành, dữliệu được lưu trữ liên tục hoặc tạm thời Ví du truy cập dữ liệu liên tục bao gồm cơchế truy vấn như dữ liệu để truy cập CSDL, truy cập dữ liệu trong kho như mộtkho chứa dữ liệu Truy cập dữ liệu tạm thời bao gồm truy cập vùng nhớ (heap hoặcstack) và thông tin vùng đệm Không gian tùy chọn của kết nối truy
Trang 19cập dữ liệu đƣợc mô tả chi tiết trong hình 2.4.
Process specific
Global
Access
Accessor Mutator Register
Transient
Cache Communication
Data Acces
DMA Coordination
Stack Repository access
Persistent
File I/O Dynamic data exchange Database Access
Protected Public
Life Cycle
Initialiaztion Termination
Trang 20Giao diện là điểm giao tiếp giữa hai thành phần với nhau Các thành phần sẽhạn chế sự truy cập vào các thành phần con trong đó bằng cách chỉ đưa ra một
số giao diện chính
Giao diện cũng thể hiện sự liên kết lỏng lẻo hay chặt chẽ giữa các thành phần.Trong thiết kế kiến trúc chúng ta thường tuân thủ các nguyên lý hướng đốitượng, các thành phần và mô đun (module) rất linh động và độc lập với nhau.Tuy nhiên, chúng cũng đem lại một số rắc rối do sự linh động và khả năng tái sửdụng trong phần mềm cũng đồng nghĩa với việc xuất hiện hàng loạt các lớp trừutượng, các phân tầng trong mô hình thiết kế Các phân tầng trừu tượng này sẽlàm giảm hiệu năng và tốc độ của hệ thộng Do đó trong quá trình thiết kế kiếntrúc phần mềm phải cân nhắc phần mềm nào cần ưu tiên sự linh động và khảnăng tái sử dụng, phần mềm nào ưu tiên tốc độ và hiệu năng để đưa ra thiết kếphù hợp nhất
Trang 212.3 Một số kiểu kiến trúc điển hình
Một kiểu kiến trúc là một tập các quyết định thiết kế kiến trúc áp dụng trongmột ngữ cảnh phát triển phần mềm hoặc dựa trên sự ràng buộc của các quyếtđịnh thiết kế kiến trúc cụ thể cho một hệ thống cụ thể trong phạm vi thiết kế đó.Tập các quyết định thiết kế cũng dựa trên sự suy luận lợi ích chất lượng trongmỗi kết quả hệ thống
Kiểu kiến trúc được trình bày trong [2], có tám kiểu kiến trúc cơ bản là: Main Program and Subroutines, Layered, Data-flow styles, Shared memory, Interpreter, Implicit invocation, Peer-to-peer, “Derived” styles Trong khi đó, kiểu kiến trúc được tình bày trong [4] và [6], phân chia các kiểu kiến trúc theo nhóm dựa trên đặc điểm của kiểu kiến trúc
Kiểu kiến trúc gọi – trả lại (Main Program and Subroutines)
Đây là kiểu kiến trúc truyền thống bao gồm: Mô hình gọi – trả lại (Mainprogram and subroutines) và hướng đối tượng (object-oriented) Hình 2.5 minhhọa kiểu kiến trúc gọi – trả lại
r
u d e
l
l a
c
e
r u e
c
o r
P
Procedure call
In: IValue3 Out: OValue3
Routine 1
l c
u e
c e
r
Trang 22In: none ll
P
r
Out: none Routine 1.1 Routine 1.2
Routine 3.1 Routine 3.2
Hình 2.5: Kiến trúc gọi trả lại [2].
Trang 23Đặc điểm của kiểu kiến trúc gọi trả lại được mô tả chi tiết trong bảng 2.2.
Bảng 2.2: Đặc điểm của kiểu kiến trúc gọi trả lại
Kiểu kiến trúc Program and subroutines
Đặc điểm Theo phong cách hướng thủ tục, chức năng lớn được
phân rã thành các chức năng con Chương trình gồm mộtchương trình chính và gọi tới các chương trình con
Thành phần Chương trình chính và các chương trình con
Kết nối Lời gọi hàm
Lý do lựa chọn Đơn giản, dễ hiểu
Dễ sử dụng với các hệ thống vừa và nhỏ, độ phức tạpkhông lớn
Kiểu kiến trúc phân tầng (Layered)
Kiểu kiến trúc phân tầng là phân chia các mối quan tâm của ứng dụng
thành các lớp độc lập Hình 2.6 minh họa kiểu kiến trúc phân tầng
u e
l
a c
re
u e
c
ro
P
Server
Trang 24Hình 2.6: Kiến trúc phân tầng [2].
Trang 25Đặc điểm của kiểu kiến trúc phân tầng được mô tả chi tiết trong bảng 2.3.
Bảng 2.3: Đặc điểm của kiểu kiến trúc phân tầng
Đặc điểm Phân chia các mối quan tâm của ứng dụng thành lớp độc
lập
Thành phần Các tầng (layer) Các tầng này có thể là các hệ thống con
trong hệ thống lớn hoặc là các dự án (project) hoặc gói(package) trong hệ thống nhỏ
Kết nối Các giao thức của tầng tương tác
Lý do lựa chọn Với ứng dụng phức tạp, ta muốn giảm thiểu sự phức tạp
bằng cách nhóm các chức năng có nhiệm vụ và tính chấtgiống nhau vào chung một tầng
Để cải thiện khả năng bảo trì và mở rộng ứng dụng bằngcách giảm thiểu phụ thuộc
Khi đã có những ứng dụng trước đó, cung cấp sẵn tìnhhuống xử lý nghiệp vụ thông qua các giao diện dịch vụ.Ứng dụng phải hỗ trợ nhiều loại máy khách (client) vàthiết bị khác nhau
Muốn thực hiện các quy tắc nghiệp vụ phức tạp vào quátrình
2.4 Các bước thiết kế kiến trúc phần mềm
Đầu năm 2009, khi đó tôi may mắn được tham gia vào dự án về xử lý ảnhtrong y tế cho khách hàng Nhật Bản Hệ thống này rất lớn, cực kì phức tạp nên
có sự tham gia phát triển của nhiều công ty phần mềm ở Nhật Bản, Trung Quốc
và Việt Nam Công ty tôi chịu trách nhiệm cho một số hệ thống con trong hệthống lớn này Trước đó chúng tôi chỉ quen với việc làm thiết kế chi tiết(Software Detailed Desgin – SDD) rồi thực hiện viết mã nguồn Khi khách hàngyêu cầu chúng tôi viết tài liệu về thiết kế kiến trúc phần mềm (SoftwareArchitecture Design – SAD) cho phần của mình thì tất cả đều bỡ ngỡ, khôngbiết SAD là gì Người quản trị dự án của chúng tôi đã xin sự hỗ trợ từ phía tổng
Trang 26công ty, hi vọng với một công ty phần mềm lớn nhất Việt Nam như Fsoft thì cónhiều người biết Nhưng câu trả lời chúng tôi nhận được là không nhiều ngườibiết về vấn đề này, người có kinh nghiệm thì rất ít và đang tham gia các dự ánkhác nên không thể hỗ trợ Tự thân vận động, chúng tôi cũng thử làm, nhưngkết quả thì tạo ra một thứ SAD mà như SDD, SAD được tạo ra sau khi có SDD(điều này đi ngược với quy trình bình thường) Sau lần thất bại này, chúng tôi
đã cử người sang làm việc trực tiếp với khách hàng để học hỏi May mắn chochúng tôi là khách hàng là công ty phần mềm lớn của Nhật Bản, nơi đó cónhững bậc thầy về SAD Với sự cố gắng hết mình tìm hiểu, tham khảo SAD của
hệ thống cũ, cộng với sự giúp đỡ nhiệt tình của khách hàng, khoảng một nămsau chúng tôi có sản phẩm SAD hoàn chỉnh, được khách hàng đánh giá cao, rấttin tưởng vào khả năng thành công
Cá nhân tôi trước đó là lập trình viên, thực hiện tạo SDD và viết mã nguồn.Sau đó tôi được hướng dẫn, chỉ bảo về SAD, đọc tham khảo và tìm hiểu kĩ vềcác tài liệu SAD trước đó Do hệ thống lớn và phức tạp, có nhiều công ty thamgia phát triển nên hệ thống được chia ra làm nhiều SS, mỗi bên chịu trách nhiệmvài SS Và mỗi SS này cũng rất lớn và phức tạp, nên chúng được phân chia rathành các mô đun lớn Mỗi SS đều có SAD tổng quan, sau đó mỗi mô đun lớntrong SS này sẽ có SAD riêng, dựa vào SAD tổng quan đó Tôi được giao phụtrách một nhóm gồm gần mười thành viên, chịu trách nhiệm viết SAD cho nhiều
mô đun lớn, sau đó sẽ đưa kết quả của mình nhờ các chuyên gia bên phía kháchhàng xem xét, đánh giá May mắn cho tôi là khách hàng chấp nhận và đánh giácao về sản phẩm này Sau đó SAD được chuyển cho các thành viên trong nhóm
để tạo SDD và thực hiện viết mã nguồn Kết quả sản phẩm cuối cùng của chúngtôi gặp rất ít lỗi khi kiểm thử, sau khi sửa chạy rất ổn định, đáp ứng đủ tính năng,vượt trên cả mong đợi vì đây là mô đun lớn và khó nhất trong dự án Sản phẩmcủa chúng tôi đã hoàn thiện vào cuối năm 2010 và đầu năm 2011 sản phẩm đó đãđưa vào sử dụng rộng rãi tại nhiều bệnh viện lớn tại Tokyo, Nhật Bản
Cùng thời gian này, trên lớp cao học chúng tôi được học môn các vấn đềhiện đại trong phát triển phần mềm của thầy Trương Anh Hoàng Trong mônnày thầy Hoàng đã nói về định nghĩa SAD, các kiểu SAD … Chúng tôi tìm tòitài liệu tham khảo trên mạng, thảo luận sôi nổi trong lớp học để hiểu rõ thêm vấn
đề Tôi cố gắng ngồi suy luận, đánh giá mối liên hệ giữa những gì mình đã làmthực tế và lý thuyết trong sách vở
Cuối cùng từ những gì đã làm trong thực tế, cộng với việc đọc tài liệu thamkhảo [2] và [3], tôi xin tóm lược lại, làm rõ các bước thiết kế kiến trúc phần
Trang 27mềm như dưới đây.
Các bước thiết kế kiến trúc phần mềm có tính chất lặp, được mô tả như hình2.7 dưới đây:
Hình 2.7: Các bước thiết kế kiến trúc phần mềm [3].
Hình 2.7 cho thấy, thiết kế kiến trúc phần mềm gồm 5 bước như sau:
Bước 1: Xác định mục tiêu kiến trúc (Identify Architecture Objectives)
Mục tiêu kiến trúc là những mục tiêu và ràng buộc sẽ giúp xác định và hìnhdạng kiến trúc, quy trình thiết kế, phạm vi thiết kế và xác định thời điểm kếtthúc Các yếu tố sau đây sẽ giúp xác định mục tiêu kiến trúc:
architecture goals at the start): Lượng thời gian ta phải bỏ ra cho mỗi giai
đoạn của thiết kế kiến trúc và thiết kế sẽ phụ thuộc vào các mục tiêu này
Ví dụ làm bản mẫu (prototype) thì chỉ cần vài ngày để thiết kế, trong khithiết kế chi tiết đầy đủ cho một ứng dụng phức tạp có thể cần tới vài tháng
để hoàn thành Mục tiêu này sẽ khác nhau khi thực hiện thiết kế kiến trúctổng quan cho hệ thống lớn ban đầu và thiết kế kiến trúc cho chức nănglớn cụ thể Với hệ thống lớn ban đầu, thiết kế kiến trúc cố gắng chia nhỏ
hệ thống thành các SS và đưa ra các giải pháp có tính định hướng,phương châm thiết kế Dựa vào đó thiết kế kiến trúc cho chức năng lớn
cụ thể sẽ áp dụng và làm chi tiết nhất có thể cho chức năng của mình
ii Sự hiểu biết về đối tượng sẽ sử dụng kiến trúc này: Xác định kiến trúc của
Trang 28ta sẽ được sử dụng bởi đối tượng nào? Các kiến trúc sư, các nhà phát triển
và thử nghiệm hay nhà quản lý Đối tượng sử dụng thiết kế kiến trúc tổngquan thường là các kĩ sư thiết kế chức năng cụ thể Đối tượng sử dụng thiết
kế kiến trúc cụ thể là các người thiết kế chi tiết và lập trình viên
các ràng buộc Ví dụ các ràng buộc về môi trường phát triển, môi trường sẽ triểnkhai phần mềm, ràng buộc về người sử dụng … Hiểu được các ràng buộc, hạn chếlúc đầu giúp ta không lãng phí thời gian hoặc gặp phải những tình huống bất ngờsau này trong quá trình phát triển ứng dụng
Bước 2: Kịch bản chính (Key Scenarios)
Sự hiểu biết về kịch bản chính giúp ta định hình ứng dụng của mình để đápứng những kịch bản sau này, sau đó sử dụng chúng để kiểm tra các lựa chọnkiến trúc Kịch bản chính được coi là quan trọng nhất cho sự thành công củaứng dụng Kịch bản chính có thể được định nghĩa bởi bất kỳ kịch bản nào đápứng một trong các tiêu chuẩn sau đây:
năng
Ví dụ, chiến lược xác thực của ta là một kịch bản quan trọng bởi vì nó là mộtđiểm giao của một thuộc tính chất lượng (an ninh) với chức năng (làm thế nàongười dùng đăng nhập vào hệ thống của chúng ta) Một kịch bản khác chính làyêu cầu bảo mật sẽ ảnh hưởng tới hiệu suất ứng dụng của chúng ta, bởi vì nó đạidiện cho các giao điểm của hai thuộc tính chất lượng
Các ca kiến trúc quan trọng
Trường hợp sử dụng ca kiến trúc quan trọng có tác động trên nhiều khía cạnhcủa thiết kế của chúng ta Những trường hợp sử dụng đặc biệt quan trọng trongviệc định hình sự thành công của ứng dụng gồm:
cao so với các tính năng khác, hoặc ngụ ý sự rủi ro kỹ thuật, công nghệ cao Ví dụvới các hệ thống bán hàng trực tuyến thì xử lý nghiệp vụ liên quan tới thanh toántiền, bảo mật có mức độ quan trọng hơn, sử dụng cao hơn
Trang 29chức năng và thuộc tính chất lượng, hoặc đại diện cho một mối quan tâmxuyên suốt mà có một tác động điểm cuối tới điểm cuối trên lớp ứng dụngcủa chúng ta Ví dụ trong hệ thống bán hàng trực tuyến, chức năng xemsản phẩm rồi chọn sản phẩm vào giỏ hàng có ảnh hưởng cao, vì ảnhhưởng trực tiếp tới quá trình thanh toán sau đó của người dùng Nếu quátrình lưạ chọn rồi lưu trữ sản phẩm vào giỏ hàng không chính xác có thểdẫn tới quá trình thanh toán tiền cũng không chính xác.
Các tình huống người sử dụng, hệ thống và nghiệp vụ
Sử dụng những tình huống từ nhiều quan điểm để giúp tiếp xúc với các kịchbản chính cho hệ thống Tình huống người dùng mô tả cách mà người dùng sẽtương tác với hệ thống Tình huống hệ thống diễn tả hệ thống sẽ làm việc nhưthế nào và tổ chức các chức năng của của chúng Tình huống nghiệp vụ diễn tả
hệ thống sẽ đáp ứng nghiệp vụ cần như thế nào hoặc làm việc theo những ràngbuộc nghiệp vụ
Bước 3: Tổng quan ứng dụng (Application Overview)
Tổng quan về ứng dụng phục vụ khi thiết kế kiến trúc tốt hơn, gắn kết chúngvào ràng buộc thực tế và lựa chọn Tổng quan về ứng dụng bao gồm các bướcnhư sau:
xây dựng Đó có phải là một ứng dụng di động,
ứng dụng web hoặc kết hợp một số loại với nhau?
ứng dụng mà bạn đangứng dụng trên window,
định nó sẽ có những gì tác động vào kiến trúc
dụng trong thiết kế Thường có những kiểu kiến trúc cơ bản trước đó, ta sẽ phântích, đánh giá ưu nhược điểm của từng kiểu kiến trúc rồi lựa chọn xây dựng theokiến trúc cơ bản đó như kiến trúc hướng dịch vụ (Service Oriented Architecture -SOA), khách/chủ (client/server), phân tầng (layered), đường truyền thông điệp(message-bus),… hay kết hợp các kiểu kiến trúc với nhau rồi chỉnh sửa cho phùhợp với ứng dụng của mình
liên quan dựa vào loại ứng dụng của bạn và hạn chế khác, xác định công nghệ sẽtận dụng trong kiến trúc
Tổng quan ứng dụng này được sử dụng nhiều cho quá trình Thiết kế kiến trúc
Trang 30tổng quan vì mang tính chất định hướng, đưa ra các phương châm cho thiết kế sau này
Bước 4: Các điểm nổi bật
Xác định các điểm nổi bật dựa vào một số tiêu chí sau:
thiếu xót Các điểm nổi bật chính có thể được tổ chức xung quanh các thuộc tínhchất lượng và mối quan tâm xuyên suốt
hưởng đến thiết kế của bạn thông qua tầng và lớp Đây cũng là vùng mà các sailầm thiết kế xảy ra Sử dụng khung kiến trúc để xác định các điểm “nóng” trongthiết kế của bạn đòi hỏi sự chú ý bổ sung để có được quyền Bạn có thể sử dụngkhung kiến trúc sau đây để xác định mối quan tâm trong suốt quá trình thiết kế
Khung kiến trúc của các điểm nổi bật được mô tả chi tiết trong bảng 2.4
Bảng 2.4: Khung kiến trúc của các điểm nổi bật [3]
Làm thế nào để lựa chọn một công nghệ bộ nhớ đệmthích hợp
Bộ nhớ đệm và trạng Làm thế nào để xác định những dữ liệu vào bộ nhớ
Làm thế nào để xác định vị trí bộ nhớ đệm chứa dữliệu
Trang 31Làm thế nào để vượt qua các dữ liệu nhạy cảm.
Làm thế nào để lựa chọn một mô hình thành phần giaodiện người dùng
Làm thế nào để xử lý các thông tin liên lạc giữa các
mô đun trong giao diện người dùng
Làm thế nào để xử lý đồng bộ giữa các tiến trình(thread)
nhược điểm
dịch (Concurrency
and Transactions)
Làm thế nào để xử lý các giao dịch phân tán
Làm thế nào để xử lý các giao dịch chạy trong thờigian lâu
Làm thế nào để xác định những thông tin cần phảiđược cấu hình
Quản lý cấu hình
Làm thế nào để xác định vị trí và lưu trữ thông tin cấu
Management)
Trang 32Làm thế nào để bảo vệ thông tin cấu hình nhạy cảm.Làm thế nào để xử lý thông tin cấu hình trong một
Trang 33Làm thế nào để quản lý các kết nối CSDL.
(Data Access)
Làm thế nào để cải thiện hiệu suất
Làm thế nào để xử lý các đối tƣợng nhị phân lớn
Management)
Làm thế nào để cung cấp thông báo khi có yêu cầu.Làm thế nào để xác định thông tin ghi lại
Quá trình ghi lỗi và
Làm thế nào để tạo cấu hình cho quá trình ghi lỗi
đo đạc (Logging and
thiết
Làm thế nào để nâng cao hiệu quả công việc
Trang 34Làm thế nào để cải thiện cách nhìn và cảm nhận.