Nghiên cứu và thiết kế kiến trúc phần mềm cho các hệ thống lớn và phức tạp

Ví dụ giai đoạn thiết kế kiến trúc Architecture Design - AD sẽ thực hiện chuyể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ú

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

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

MỤ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

BẢNG CÁC CHỮ VIẾT TẮT

basic 6.0

thống nhất

DANH 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

DANH 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

CHƯƠ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ần mề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ác nước Trong mô hình phát triển phần mềm hình chữ V, các công việc được chia thà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ện chuyể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ài liệ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 đặt chương trình được dễ dàng, thuận tiện

là một khối mã nguồn rối rắm hoặc nếu có thì cũng chỉ là một chương trình nhỏ

vớ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 ta làm việc có phần chủ quan và mang tính tự phát, nhưng nếu bình tĩnh nghiên cứ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 trong bà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ải quyết, mà có thể đó là những lời giải tối ưu mà trước đó chúng ta không thấy hoặ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 đổi yê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ức nă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ên cứ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ài toán, từ đó cho phép chúng ta chọn được cách thức tốt nhất và con đường ngắn nhấ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ực trong đờ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ện rấ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ữa trị 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ựng chức năng mới cho hệ thống quản lý, xử lý ảnh trong y tế Khi nhận được bài toá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ần rờ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ôi trường lập trình khác nhau Phần giao diện giao tiếp với người dùng được viết bằ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ều cá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ải nâ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

khá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ục nê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ần thuậ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ời rạ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êm tú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ác thà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ểu kiế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ào quá 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ước thiế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ấ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 sau cho hiệu quả

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ày 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

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 ở

chươ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

CHƯƠ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ông phả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ần mề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:

i Kiến trúc hệ thống: Ví dụ các thành phần kiến trúc nên được bố trí và tổng hợp chính xác

ii Hành vi chức năng: Ví dụ tiến trình xử lý dữ liệu, lưu trữ, sự ảo hóa sẽ được thực hiện một cách tuần tự chính xác

iii Sự tương tác: Ví dụ sự giao tiếp bao quanh tất cả các phần tử hệ thống sẽ được phát tỏa chỉ cần dùng một sự kiện thông báo

iv Thuộc tính phi chức năng: Ví dụ sự phụ thuộc hệ thống sẽ được đảm bảo bởi sự nhân bản chức năng xử lý

v Triển khai hệ thống: Ví dụ thành phần giao diện người dùng sẽ được xây 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át triể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ọng trong 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ệnh nhâ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ủa ngườ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

quả cho người dùng Lớp xử lý nghiệp vụ có nhiệm vụ xử lý nghiệp vụ của bài toá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 quan tớ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ếu cầ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ết quả cho lớp xử lý nghiệp vụ

Database (Server 2)

In: PatientInfo Out: ErrorCode

In: PatientInfo Out: ErrorCode

In: PatientInfo Out: ErrorCode

In: PatientInfo Out: ErrorCode

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

Server 2)

kết nối với nhau theo cơ chế truyền thông điệp của lập trình hướng đối tượng Riêng lớp truy cập dữ liệu sẽ kết nối với

CSDL theo cơ chế truy cập dữ liệu để thực hiện truy vấn, cập nhật dữ liệu

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ác phươ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ủa quá trình thêm mới dữ liệu là thành công hay thất bại

động với nhau Cấu hình sẽ được thể hiện một file cấu hình của hệ thống, dựa vào đó lớp truy cập dữ liệu sẽ tương tác vớ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ầu hì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ĩa cá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ống lớn, hoặc các dựa án (project), gói (package) trong một SS

Thủ 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ông qua 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 qua việ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ọi lạ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ạn như 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ô

Default values Keyword parameters Inline parameters Return values

Invocation record Push from L to RPush from R to L

Private Protected Public

Hình 2.2: Không gian tùy chọn của thủ tục gọi kết nối [2]

Kết nối sự kiện (Event Connector)

Tương tự như kết nối thủ tục, kết nối sự kiện tác động lên luồng xử lý giữa các thành phần và cung cấp các dịch vụ phối hợp

Các kết nối sự kiện cũng khác nhau từ các thủ tục gọi trong đó kết nối ảo được hình thành giữa các thành phần quan tâm đến các chủ đề cùng một sự kiện, những kết nối đó có thể xuất hiện và biến mất tự động tùy thuộc vào sự quan tâm thay đổi của các thành phần trong các chủ đề của cùng một sự kiện của các

thà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 trong hình 2.3

Communication

Cardinatily

Producers Observers Event patterns

Best effort Exactly once

At most once Delivery

Outgoing Incoming

Notification

Fan in

Relative Page faults

At least once Priority

Time out Asynchronous Polled

Publish/subscribe Center update Queued dispatch

Mode

Hardware

Software

Interrupts Traps Signals GUI input/output Triggers

Hì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 duy trì bởi thành phần lưu trữ dữ liệu, do đó chúng cung cấp các dịch vụ truyền thô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ột kho 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ặc stack) và thông tin vùng đệm Không gian tùy chọn của kết nối truy

cập dữ liệu đƣợc mô tả chi tiết trong hình 2.4

Communication

Global Accessor Mutator Register Access

Transient

Persistent

Accessibility

Repository access File I/O

Termination

Cache Availability

Dynamic data exchange Database Access Private

Protected Public

DMA Heap Stack

Hình 2.4: Không gian tùy chọn của kết nối truy cập dữ liệu [2]

2.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 trong mộ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 trong

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 (Main program and subroutines) và hướng đối tượng (object-oriented) Hình 2.5 minh họa kiểu kiến trúc gọi – trả lại

Main program

Proc

edur

e ca

ll Pro ced ure

In: none

Out: Ovalue1 Out: OValue2In: IValu2

In: IValue3 Out: OValue3

In: none Out: none

Đặ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

phân rã thành các chức năng con Chương trình gồm một chương trình chính và gọi tới các chương trình con

Dễ sử dụng với các hệ thống vừa và nhỏ, độ phức tạp khô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

Đặ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

lập

trong hệ thống lớn hoặc là các dự án (project) hoặc gói (package) trong hệ thống nhỏ

bằng cách nhóm các chức năng có nhiệm vụ và tính chất giố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ằng cách giảm thiểu phụ thuộc

Khi đã có những ứng dụng trước đó, cung cấp sẵn tình huố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ý ảnh trong 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àng yê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 (Software Architecture Design – SAD) cho phần của mình thì tất cả đều bỡ ngỡ, không biế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

cô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ười biết về vấn đề này, người có kinh nghiệm thì rất ít và đang tham gia các dự án khác nên không thể hỗ trợ Tự thân vận động, chúng tôi cũng thử làm, nhưng kế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 cho chú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ăm sau chúng tôi có sản phẩm SAD hoàn chỉnh, được khách hàng đánh giá cao, rất tin 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 tham gia 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ệm và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 ra thành các mô đun lớn Mỗi SS đều có SAD tổng quan, sau đó mỗi mô đun lớn trong 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ách hà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úng tô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ẩm củ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ôn này thầy Hoàng đã nói về định nghĩa SAD, các kiểu SAD … Chúng tôi tìm tòi tà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àm thự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 tham khả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

mề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ình 2.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ình dạ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ết thúc Các yếu tố sau đây sẽ giúp xác định mục tiêu kiến trúc:

i Sự hiểu biết về mục tiêu kiến trúc tại thời điểm bắt đầu (Understand your 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 khi thiế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úc tổng quan cho hệ thống lớn ban đầu và thiết kế kiến trúc cho chức năng lớ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

ta 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ổng quan 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 iii Sự hiểu về các ràng buộc, hạn chế: Hiểu biết về lựa chọn công nghệ và 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ển khai 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ọn kiế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:

i Kịch bản của một ca sử dụng kiến trúc quan trọng

ii Kịch bản thể hiện cho các giao điểm của thuộc tính chất lượng với chức năng

iii Kịch bản thể hiện sự cân bằng giữa các thuộc tính chất lượ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ào ngườ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ó đại diệ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ạnh của thiết kế của chúng ta Những trường hợp sử dụng đặc biệt quan trọng trong việc định hình sự thành công của ứng dụng gồm:

i Ca sử dụng nghiệp vụ quan trọng là ca sử dụng nghiệp có mức độ sử dụng 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án tiền, bảo mật có mức độ quan trọng hơn, sử dụng cao hơn

ii Trường hợp sử dụng có ảnh hưởng cao là trường hợp giao cắt với cả hai

chức năng và thuộc tính chất lượng, hoặc đại diện cho một mối quan tâm xuyê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ụng của chúng ta Ví dụ trong hệ thống bán hàng trực tuyến, chức năng xem sản phẩm rồi chọn sản phẩm vào giỏ hàng có ảnh hưởng cao, vì ảnh hưở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ịch bả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àng buộ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úng và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ước như sau:

i Xác định loại ứng dụng: Đầu tiên xác định loại ứng dụng mà bạn đang xây dựng Đó có phải là một ứng dụng di động, ứng dụng trên window, ứng dụng web hoặc kết hợp một số loại với nhau?

ii Sự hiểu biết về ràng buộc triển khai: Hiểu môi trường sẽ triển khai và xác định nó sẽ có những gì tác động vào kiến trúc

iii Xác định các kiểu kiến trúc quan trọng: Xác định kiểu kiến trúc bạn sẽ sử 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ân tí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 theo kiế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

iv Xác định công nghệ liên quan: Cuối cùng xác định, lựa chọn công nghệ

có 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

tổ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:

i Xác định các điểm nổi bật trong kiến trúc ứng dụng để hiểu những vùng 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ính chất lượng và mối quan tâm xuyên suốt

ii Khung kiến trúc đại diện cho các mối quan tâm xuyên suốt mà sẽ ảnh 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 sai lầm thiết kế xảy ra Sử dụng khung kiến trúc để xác định các điểm

“nóng” trong thiết kế của bạn đòi hỏi sự chú ý bổ sung để có được quyền Bạn có thể sử dụng khung 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]

Xác thực và ủy quyền

Làm thế nào để lựa chọn một chiến lược xác thực Làm thế nào để lựa chọn một chiến lược ủy quyền Làm thế nào để xác định luồng xử lý thông qua các lớp và tầng

Làm thế nào để lưu trữ danh tính người dùng khi không sử dụng dịch vụ thư mục (Microsoft Active Directory)

Làm thế nào để thiết kế lỏng lẻo qua các lớp

Làm thế nào để thực hiện truyền thông không đồ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ý 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ời gian lâu

Làm thế nào để xác định khi kết nối lỏng là thích hợp giữa các thành phần trong một lớp

Truy cập dữ liệu

(Data Access)

Làm thế nào để quản lý các kết nối CSDL

Làm thế nào để xử lý các trường hợp ngoại lệ

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

Quản lý ngoại lệ

(Exeception

Management)

Làm thế nào để xử lý các trường hợp ngoại lệ

Làm thế nào để ghi lại trường hợp ngoại lệ

Làm thế nào để cung cấp thông báo khi có yêu cầu

Quá trình ghi lỗi và

đo đạc (Logging and

Instrumentation)

Làm thế nào để xác định thông tin ghi lại

Làm thế nào để tạo cấu hình cho quá trình ghi lỗi Làm thế nào để xác định cấp độ của sự đo đạc là cần thiết

Kinh nghiệm người

dùng (User

Experience)

Làm thế nào để nâng cao hiệu quả công việc

Làm thế nào để cải thiện đáp ứng yêu cầu của người dùng

Làm thế nào để cải thiện quyền người dùng

Làm thế nào để cải thiện cách nhìn và cảm nhận

(Validation) hiện xác nhận

Làm thế nào để xác nhận cho chiều dài, phạm vi, định dạng, và thể loại

Làm thế nào để hạn chế và loại bỏ đầu vào

Làm thế nào để làm mịn đầu ra

và các điểm nổi bật

Chúng ta có thể tham khảo các hướng dẫn sau đây:

i Sự hiểu biết về những rủi ro chính và thích ứng với thiết kế để giảm những rủi ro này

ii Lựa chọn giải pháp dựa vào sự tối ưu hóa, giao tiếp hiệu quả

iii Xây dựng kiến trúc với sự linh họat và cấu trúc lại trong cách nghĩ Ta có thể phải thay đổi kiến trúc một số lần, do đó tối ưu hóa xung quanh khả năng này

2.5 Đánh giá ưu nhược điểm của SAD

Ưu điểm

SAD giúp chúng ta hiểu biết về hệ thống, thấy được cấu trúc, các thành phần chính của hệ thống, các ràng buộc liên quan Ngoài ra giúp hiểu rõ hơn về các kịch bản quan trọng của hệ thống

SAD giúp ta có lựa chọn tối ưu cho hệ thống, cho chúng ta góc nhìn rộng hơn, 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 ta nhiều hướng đi, nhiều cách giải quyết trên cùng một bài tóan, từ đó cho phép chúng ta chọn được cách thức tốt nhất và con đường ngắn nhất để đi tới đích Mặt khác cho phép ta tham khảo, kế thừa, phát huy những ưu điểm của những gì đã có trước đó, phát hiện sớm và hạn chế các rủi ro cho phần mềm

Dựa vào mô hình chữ V (V-model) ta thấy SAD là chuyển tiếp của giai đoạn khảo sát, phân tích và là bước chuẩn bị trước khi ta thiết kế chi tiết và xây dựng phần mềm Sau khi tìm hiểu, phân tích yêu cầu các kiến trúc sư sẽ mô hình hóa các yêu cầu đó lên thành các bản vẽ, phác thảo thành các bản vẽ từ tổng quát tới chi tiết Các bản vẽ đó sẽ làm cho người thiết kế chi tiết và người phát triển lập trình sẽ hình dung ra phần mềm mà họ phải thiết kế chi tiết và phát triển Ngoài

ra đây cũng là tài liệu quan trọng, hữu ích cho quá trình tạo các ca kiểm thử và thực hiện các ca kiểm thử đó

SAD là nơi mà ta có thể trả lời câu hỏi: “Liệu phần mềm này có thể chạy được không?”, “Phần mềm có thể đáp ứng được các yêu cầu của khách hàng hay không?” mà không cần phải đợi tới công đoạn phát triển Khi thiết kế SAD tốt chúng ta có thể đánh giá sớm tính khả thi của phần mềm

Giai đoạn khảo sát phân tích thường dựa trên đặc tả yêu cầu người dùng, chỉ hiểu các chức năng chính và ràng buộc dưới góc độ người dùng SAD sẽ phân tích sâu hơn về các ràng buộc, yêu cầu của hệ thống

Có SAD quá trình nâng cấp, bảo trì sẽ dễ dàng hơn Nếu không có thiết kế, chúng ta phải làm lại một chương trình hoàn toàn mới hoặc phải nghiên cứu lại toàn bộ mã nguồn, điều này đồng nghĩa với việc sẽ tiêu tốn của chúng ta khá nhiều thời gian và tiền bạc

Hỗ trợ đắc lực cho quá trình quản lý, giúp người quản lý xem xét quá trình phát triển của hệ thống, đánh giá được mức độ phức tạp của hệ thống sẽ nằm ở đâu, phần rủi ro sẽ nằm ở đâu, từ đó có các giải pháp xử lý, kế hoạch phát triển cho phù hợp