GIỚI THIỆU
Đặt vấn đề
Trong phát triển phần mềm, mô hình chữ V hiện nay được ưa chuộng và cải tiến từ mô hình thác nước Mô hình này chia quá trình phát triển thành các giai đoạn cụ thể, mỗi giai đoạn đảm nhiệm những nhiệm vụ riêng Ví dụ, giai đoạn thiết kế kiến trúc (Architecture Design - AD) 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 thông qua hình vẽ và tài liệu mô tả Kết quả thiết kế kiến trúc này là cơ sở để các nhà thiết kế chi tiết phát triển các bản thiết kế chi tiết cho phần mềm, giúp quá trình cài đặt trở nên dễ dàng và thuận tiện hơn.
Hình 1.1: Mô hình phát triển phần mềm hình chữ V [5]
Dựa vào hình 1.1 ta thấy thiết kế kiến trúc chính là một giai đoạn trong mô hình phát triển phần mềm
Khi phát triển phần mềm, việc tuân thủ đầy đủ các giai đoạn của mô hình phần mềm, đặc biệt là giai đoạn thiết kế, là rất quan trọng để giảm thiểu rủi ro và nâng cao chất lượng sản phẩm Thực tế, nhiều dự án thường thiếu kế hoạch cụ thể, dẫn đến mã nguồn phức tạp và khó bảo trì Bằng cách áp dụng quy trình thiết kế phần mềm một cách có hệ thống, chúng ta có thể khám phá nhiều giải pháp tối ưu mà trước đó có thể đã bị bỏ qua Thiết kế không chỉ giúp tiết kiệm thời gian và chi phí, mà còn cho phép chúng ta kiểm soát tốt hơn quá trình phát triển Nếu không có thiết kế hoặc thiết kế kém, việc thay đổi yêu cầu sẽ dẫn đến việc phải viết lại chương trình hoặc nghiên cứu lại mã nguồn, gây tốn kém về thời gian và tài chính Qua quá trình phân tích và thiết kế, chúng ta có thể xác định được nhiều phương án giải quyết, từ đó chọn ra cách tốt nhất để đạt được mục tiêu.
Sự phát triển nhanh chóng của công nghệ thông tin đã dẫn đến việc tin học hóa nhiều lĩnh vực trong đời sống, từ đó giúp quá trình xử lý công việc trở nên nhanh chóng và đơn giản hơn Điều này không chỉ tiết kiệm thời gian mà còn giảm thiểu chi phí đáng kể.
Với sự phát triển kinh tế, chất lượng cuộc sống của con người đã được cải thiện đáng kể Nhu cầu chăm sóc sức khỏe, khám chữa bệnh, phát hiện và chẩn đoán bệnh sớm ngày càng tăng cao Trong bối cảnh đó, công nghệ thông tin đóng vai trò quan trọng, hỗ trợ hiệu quả cho quá trình này.
Vào năm 2009, trong thời gian 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 từ khách hàng Nhật Bản yêu cầu nâng cấp và xây dựng chức năng mới cho hệ thống quản lý và xử lý ảnh trong y tế Sau khi khảo sát và phân tích, chúng tôi phát hiện hệ thống cũ tồn tại một số hạn chế đáng kể.
Hệ thống hiện tại là một chương trình lớn và phức tạp, nhưng thiếu tài liệu mô tả chi tiết, dẫn đến việc mỗi người chỉ hiểu một phần riêng lẻ Phần mềm được phát triển trên hai công nghệ khác nhau, với giao diện người dùng sử dụng VB6, nhưng do phụ thuộc vào nhiều thư viện bên thứ ba, tính đồng nhất của hệ thống không cao và thường xuyên cần nâng cấp VB6 không còn phù hợp với phần cứng mới và gặp khó khăn trong việc tương thích với các kích thước màn hình khác nhau, khiến việc tùy biến trở nên khó khăn Thêm vào đó, VB6 là ngôn ngữ lập trình hướng thủ tục, dẫn đến khả năng mở rộng kém khi cần thêm chức năng mới Phần xử lý và lưu trữ hình ảnh được viết bằng C++, nhưng các phần này cũng thiếu sự liên kết và tái sử dụng.
Một trong những hạn chế lớn trong việc bảo trì và nâng cấp hệ thống là quy trình thực hiện rất phức tạp Khi mở rộng, cần nhiều công sức và có thể ảnh hưởng đến các chức năng hiện tại, dẫn đến khả năng xử lý sai.
Những khó khăn hiện tại yêu cầu chúng tôi áp dụng phương pháp đánh giá và tiếp cận phù hợp để nâng cấp và xây dựng chức năng mới một cách chính xác Sau thời gian phân tích và đánh giá nghiêm túc, chúng tôi đã xác định được hướng đi đúng đắn, đó là chú trọng vào giai đoạn phân tích và thiết kế, đặc biệt là thiết kế kiến trúc phần mềm.
Nội dung nghiên cứu
Luận văn nghiên cứu lý thuyết thiết kế kiến trúc phần mềm, bao gồm các thành phần chính, đặc điểm của những kiểu kiến trúc tiêu biểu, quy trình thiết kế và đánh giá ưu nhược điểm Tiếp theo, luận văn khảo sát và phân tích hệ thống quản lý, xử lý ảnh trong y tế Dựa trên kết quả phân tích, luận văn trình bày chi tiết quy trình áp dụng thiết kế kiến trúc phần mềm vào bài toán quản lý và xử lý ảnh trong lĩnh vực y tế.
Luận văn trình bày phương pháp cài đặt thiết kế kiến trúc phần mềm, đề xuất các bước từ thiết kế kiến trúc đến thiết kế chi tiết nhằm đạt hiệu quả tối ưu.
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ế
Chương 4 mô 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 đã được trình bày ở chương 2, nhằm thiết kế kiến trúc cho hệ thống quản lý và xử lý ảnh trong y tế.
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.
TỔNG QUAN VỀ THIẾT KẾ KIẾN TRÚC PHẦN MỀM
Định nghĩa về kiến trúc phần mềm
Kiến trúc phần mềm là tập hợp các quyết định thiết kế chính về hệ thống Mỗi ứng dụng đều có một kiến trúc riêng, và ít nhất một kiến trúc sư chịu trách nhiệm cho nó Ngoài ra, kiến trúc không chỉ đơn thuần là một giai đoạn trong quá trình phát triển phần mềm.
Kiến trúc phần mềm là kế hoạch chi tiết cho việc xây dựng và phát triển hệ thống phần mềm Các quyết định thiết kế bao gồm nhiều khía cạnh quan trọng: đầu tiên, kiến trúc hệ thống yêu cầu các thành phần được bố trí và tổng hợp chính xác; thứ hai, hành vi chức năng liên quan đến tiến trình xử lý dữ liệu, lưu trữ và ảo hóa cần được thực hiện tuần tự; thứ ba, sự tương tác giữa các phần tử hệ thống phải được thông báo qua sự kiện; thứ tư, các thuộc tính phi chức năng như sự phụ thuộc hệ thống cần được đảm bảo qua việc nhân bản chức năng xử lý; cuối cùng, việc triển khai hệ thống bao gồm xây dựng giao diện người dùng bằng các công cụ như Java Swing hoặc Visual C#.
Kiến trúc phần mềm là một lĩnh vực rộng lớn, đóng vai trò quan trọng trong toàn bộ quy trình phát triển phần mềm Bài viết này sẽ tập trung vào một yếu tố then chốt trong kiến trúc phần mềm, đó là 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
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ệ thống quản lý thông tin bệnh nhân được thiết kế theo mô hình ba lớp, bao gồm lớp trình diễn, lớp xử lý nghiệp vụ và lớp truy cập dữ liệu Lớp trình diễn giao tiếp với người dùng, nhận yêu cầu và hiển thị kết quả Khi người dùng thêm thông tin bệnh nhân, lớp trình diễn chuyển yêu cầu tới lớp xử lý nghiệp vụ, nơi thực hiện các thao tác cần thiết và gửi yêu cầu tới lớp truy cập dữ liệu để lấy hoặc cập nhật thông tin Lớp truy cập dữ liệu có nhiệm vụ đọc và cập nhật dữ liệu từ các file hoặc cơ sở dữ liệu, sau đó trả kết quả về cho lớp xử lý nghiệp vụ.
D at a A cc es s D at a A cc es s
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,
Lớp trình diễn, lớp xử lý nghiệp vụ và lớp truy cập dữ liệu được kết nối với nhau thông qua cơ chế truyền thông điệp trong lập trình hướng đối tượng Đặc biệt, lớp truy cập dữ liệu sẽ thiết lập 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
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 chứa thông tin về bệnh nhân, bao gồm mã bệnh nhân và tên bệnh nhân Sau khi các phương thức như SaveData thực thi, chúng sẽ trả về mã lỗi tương ứng, giúp các thành phần gọi đến biết được trạng thái của quá trình thêm mới dữ liệu, cho phép xác định liệu quá trình đó có thành công hay không.
Cấu hình đóng vai trò quan trọng trong việc thiết lập các quy định cho sự tương tác giữa các thành phần trong hệ thống Nó được thể hiện qua một file cấu hình, từ đó lớp truy cập dữ liệu có thể tương tác với dữ liệu thuộc về các thành phần cụ thể như Server hoặc 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
Thành phần trong hệ thống bao gồm một tập hợp các chức năng con và dữ liệu, đồng thời hạn chế quyền truy cập tới các thành phần con thông qua việc đị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
Kết nối là phương tiện quan trọng giúp lắp ghép các thành phần và hỗ trợ tương tác giữa chúng Nó cũng đảm nhận vai trò truyền điều khiển và dữ liệu giữa các thành phần này.
Dựa trên cách thức thực hiện dịch vụ tương tác, có tám loại kết nối chính: thủ tục gọi kết nối, sự kiện, truy cập dữ liệu, kết hợp, luồng, phân xử, thích nghi và phân tán Mỗi loại kết nối này đều có những đặc điểm riêng, đóng vai trò quan trọng trong việc hỗ trợ các dịch vụ tương tác hiệu quả Dưới đây sẽ mô tả chi tiết về các kết nối điển hình này.
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, được gọi là tọa độ kết nối Chúng không chỉ thực hiện việc truyền dữ liệu giữa các thành phần tương tác mà còn 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, cũng như sự gọi lại (callback) trong các sự kiện hệ thống, đều minh họa cho cơ chế này.
Các thủ tục gọi thường được sử dụng để thiết lập kết nối hỗn hợp, bao gồm cả các thủ tục gọi từ xa Hình 2.2 mô tả không gian tùy chọn của thủ tục gọi kết nối.
Service Type Dimension Subdimension Value
Default values Keyword parameters Inline parameters Return values
Invocation record Push from L to R
Push from R to L Has table Entry point Multiple
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ó sự khác biệt trong các thủ tục gọi, trong đó kết nối ảo hình thành giữa các thành phần quan tâm đến các chủ đề của cùng một sự kiện Những kết nối này có thể tự động xuất hiện và biến mất tùy thuộc vào sự thay đổi của mối quan tâm giữ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.
Service Type Dimension Subdimension Value
Publish/subscribe Center update Queued dispatch
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 thông tin được duy trì bởi hệ thống lưu trữ dữ liệu, từ đó cung cấp các dịch vụ truyền thông hiệu quả.
Trước khi lưu trữ dữ liệu, cần xem xét cách thức truy cập và dọn dẹp dữ liệu sau khi hoàn tất Dữ liệu có thể được lưu trữ liên tục hoặc tạm thời Truy cập dữ liệu liên tục thường liên quan đến cơ chế truy vấn cơ sở dữ liệu và kho chứa dữ liệu, trong khi truy cập tạm thời bao gồm vùng nhớ như heap hoặc stack và thông tin vùng đệm Không gian tùy chọn cho kết nối truy cập dữ liệu được mô tả chi tiết trong hình 2.4.
Service Type Dimension Subdimension Value
Dynamic data exchange Database Access
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.2.3 Giao diện
Giao diện đóng vai trò quan trọng trong việc kết nối các thành phần với nhau, đồng thời giới hạn quyền truy cập vào các thành phần con thông qua việc cung cấp một số giao diện chính.
Giao diện thể hiện mối liên kết giữa các thành phần trong thiết kế kiến trúc, nơi các nguyên lý hướng đối tượng cho phép các mô đun hoạt động độc lập Tuy nhiên, sự linh động và khả năng tái sử dụng này có thể tạo ra các lớp trừu tượng và phân tầng, dẫn đến giảm hiệu năng và tốc độ hệ thống Do đó, trong thiết kế kiến trúc phần mềm, cần cân nhắc giữa sự linh động và khả năng tái sử dụng với yêu cầu về tốc độ và hiệu năng để đưa ra thiết kế tối ưu nhất.
Cấu hình là một bộ các thiết lập cụ thể giữa các thành phần và kết nối của một hệ thống kiến trúc phần mềm
Một cấu hình có thể đƣợc biểu diễn nhƣ một đồ thị trong đó các nút đại diện cho các thành phần và kết nối.
Một số kiểu kiến trúc điển hình
Kiến trúc phần mềm là tập hợp các quyết định thiết kế áp dụng trong một ngữ cảnh cụ thể, phản ánh các ràng buộc của hệ thống Những quyết định này được đưa ra dựa trên việc cân nhắc lợi ích và chất lượng của các 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,
The article discusses various architectural styles, including Interpreter, Implicit Invocation, Peer-to-Peer, and "Derived" styles It references works [4] and [6], which categorize architectural types into groups based on their distinctive characteristics.
The call-return architecture, encompassing the main program and subroutines, is a traditional programming model that also includes object-oriented approaches This architecture is illustrated in Figure 2.5.
Pr oc ed ure ca ll
P ro ce du re c al l
Pr oc ed ur e ca ll Pro ce du re c all
Pr oc ed ur e ca ll Pro ced ure ca ll
Hình 2.5: Kiến trúc gọi trả lại [2] Đặ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 chương trình và các chương trình con đặc trưng bởi phong cách lập trình hướng thủ tục, trong đó các chức năng lớn được phân chia thành các chức năng nhỏ hơn Một chương trình bao gồm một chương trình chính và thực hiện việc gọi tới các chương trình con để thực hiện các tác vụ cụ thể.
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ạ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
Procedure call Procedure call Procedure call
Hình 2.6: Kiến trúc phân tầng [2] Đặ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
Kiểu kiến trúc Layer Đặ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
Các tầng trong hệ thống có thể được hiểu là các hệ thống con trong một hệ thống lớn, hoặc là các dự án và gói 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 cấu trúc ứng dụng phức tạp là để giảm thiểu sự phức tạp bằng cách nhóm các chức năng tương tự vào cùng một tầng Điều này giúp cải thiện khả năng bảo trì và mở rộng ứng dụng thông qua việc giảm thiểu sự phụ thuộc giữa các thành phần.
Các ứng dụng trước đây đã cung cấp các tình huống xử lý nghiệp vụ thông qua giao diện dịch vụ Để đáp ứng nhu cầu đa dạng, ứng dụng cần hỗ trợ nhiều loại máy khách 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.
Các bước thiết kế kiến trúc phần mềm
Vào đầu năm 2009, tôi tham gia vào một dự án xử lý ảnh y tế cho khách hàng Nhật Bản, với sự hợp tác của nhiều công ty phần mềm từ Nhật Bản, Trung Quốc và Việt Nam Công ty tôi phụ trách một số hệ thống con trong dự án lớn này Khi khách hàng yêu cầu tài liệu thiết kế kiến trúc phần mềm (SAD), chúng tôi gặp khó khăn vì chưa quen với khái niệm này Dù đã tìm kiếm sự hỗ trợ từ tổng công ty, nhưng không có nhiều người có kinh nghiệm Sau một lần thử nghiệm không thành công, chúng tôi đã cử người sang làm việc trực tiếp với khách hàng, một công ty phần mềm lớn của Nhật Bản, để học hỏi Nhờ sự hỗ trợ nhiệt tình và nỗ lực tìm hiểu, sau khoảng một năm, chúng tôi đã hoàn thành sản phẩm SAD và nhận được đánh giá cao từ khách hàng, tạo dựng được sự tin tưởng vào khả năng thành công của dự án.
Trước đây, tôi là lập trình viên chuyên tạo SDD và viết mã nguồn Sau khi được hướng dẫn về SAD và tìm hiểu kỹ các tài liệu liên quan, tôi tham gia vào một hệ thống lớn và phức tạp với nhiều công ty cùng phát triển Hệ thống này được chia thành nhiều SS, mỗi bên phụ trách một phần, và mỗi SS lại được phân chia thành các mô đun lớn, mỗi mô đun đều có SAD riêng dựa trên SAD tổng quan Tôi được giao phụ trách một nhó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, và sau khi hoàn thiện, sản phẩm của chúng tôi được khách hàng đánh giá cao SAD sau đó được chuyển cho nhóm để tạo SDD và viết mã nguồn Kết quả cuối cùng của chúng tôi gặp rất ít lỗi trong quá trình kiểm thử, hoạt động ổn định và đáp ứng tốt các yêu cầu, vượt trên cả mong đợi, đặc biệt vì đây là mô đun lớn và khó nhất trong dự án Sản phẩm đã hoàn thiện vào cuối năm 2010 và đầu năm 2011, được đư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.
Trong lớp cao học, chúng tôi học môn các vấn đề hiện đại trong phát triển phần mềm với thầy Trương Anh Hoàng, nơi thầy đã trình bày về định nghĩa và các kiểu SAD Chúng tôi tích cực tìm kiếm tài liệu tham khảo trên mạng và thảo luận sôi nổi để nắm vững kiến thức Tôi đã cố gắng suy luận và đánh giá mối liên hệ giữa thực tiễn và lý thuyết đã học.
Dựa trên những kinh nghiệm thực tế và tài liệu tham khảo [2] và [3], tôi sẽ tóm tắt và làm rõ các bước thiết kế kiến trúc phần mềm như sau.
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 yếu tố quan trọng giúp xác định hình dạng và quy trình thiết kế, cũng như phạm vi và thời gian hoàn thành dự án Để đạt được điều này, việc hiểu rõ các mục tiêu kiến trúc ngay từ đầu là rất cần thiết, vì thời gian cần thiết cho mỗi giai đoạn thiết kế sẽ phụ thuộc vào những mục tiêu đã đặt ra.
Việc thiết kế bản mẫu (prototype) chỉ mất vài ngày, trong khi thiết kế chi tiết cho ứng dụng phức tạp có thể kéo dài tới vài tháng Mục tiêu thiết kế kiến trúc cho hệ thống lớn ban đầu khác với thiết kế cho chức năng cụ thể; trong giai đoạn đầu, kiến trúc được chia nhỏ thành các thành phần và đưa ra các giải pháp định hướng Thiết kế kiến trúc cho chức năng cụ thể sẽ chi tiết hóa các chức năng đó Đối tượng sử dụng kiến trúc bao gồm kiến trúc sư, nhà phát triển, và các kỹ sư thiết kế chức năng Hiểu rõ các ràng buộc và hạn chế, như công nghệ và môi trường phát triển, là cần thiết để tránh lãng phí thời gian và xử lý các tình huống bất ngờ trong quá trình phát triển ứng dụng.
Bước 2: Kịch bản chính (Key Scenarios)
Hiểu biết về kịch bản chính là yếu tố then chốt giúp định hình ứng dụng để đáp ứng các kịch bản tương lai và kiểm tra các lựa chọn kiến trúc Kịch bản chính được xem là yếu tố quan trọng nhất cho sự thành công của ứng dụng, có thể được xác định qua các tiêu chí sau: kịch bản của một ca sử dụng kiến trúc quan trọng, kịch bản thể hiện giao điểm giữa các thuộc tính chất lượng và chức năng, cũng như kịch bản thể hiện sự cân bằng giữa các thuộc tính chất lượng.
Chiến lược xác thực là một yếu tố quan trọng, kết nối giữa thuộc tính chất lượng (an ninh) và chức năng (quy trình đăng nhập của người dùng) Bên cạnh đó, yêu cầu bảo mật cũng tác động đến hiệu suất ứng dụng, vì nó thể hiện sự giao thoa giữ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 trong kiến trúc phần mềm có ảnh hưởng lớn đến thiết kế ứng dụng Đặc biệt, ca sử dụng nghiệp vụ quan trọng có tần suất sử dụng cao và rủi ro công nghệ lớn, như việc xử lý thanh toán và bảo mật trong hệ thống bán hàng trực tuyến Bên cạnh đó, trường hợp sử dụng có ảnh hưởng cao liên quan đến cả chức năng và chất lượng, như việc xem và chọn sản phẩm vào giỏ hàng, có tác động trực tiếp đến quy trình thanh toán Nếu quá trình này không chính xác, sẽ dẫn đến sai sót trong thanh toán, ảnh hưởng đến trải nghiệm người dùng.
Các tình huống người sử dụng, hệ thống và nghiệp vụ
Sử dụng các tình huống từ nhiều quan điểm giúp tiếp cận các kịch bản chính cho hệ thống Tình huống người dùng mô tả cách tương tác của người dùng với hệ thống, trong khi tình huống hệ thống giải thích cách thức hoạt động và tổ chức các chức năng của nó Cuối cùng, tình huống nghiệp vụ nêu rõ cách hệ thống đáp ứng các yêu cầu nghiệp vụ hoặc làm việc theo các ràng buộc nghiệp vụ.
Bước 3: Tổng quan ứng dụng (Application Overview)
Để thiết kế kiến trúc ứng dụng hiệu quả, cần thực hiện các bước quan trọng sau: Đầu tiên, xác định loại ứng dụng mà bạn đang phát triển, có thể là ứng dụng di động, ứng dụng trên Windows, ứng dụng web hoặc sự kết hợp giữa các loại Tiếp theo, cần hiểu rõ về ràng buộc triển khai, bao gồm môi trường hoạt động và các yếu tố tác động đến kiến trúc Sau đó, xác định kiểu kiến trúc phù hợp, có thể là kiến trúc hướng dịch vụ (SOA), kiến trúc khách/chủ, kiến trúc phân tầng, hoặc kiến trúc đường truyền thông điệp, và phân tích ưu nhược điểm của từng kiểu để lựa chọn Cuối cùng, xác định và lựa chọn công nghệ liên quan, dựa trên loại ứng dụng và các hạn chế khác, để đảm bảo công nghệ được áp dụng phù hợp với kiến trúc thiết kế.
Ứng dụng này đóng vai trò quan trọng trong quá trình thiết kế kiến trúc tổng quan, bởi nó cung cấp định hướng và các phương châm cần thiết cho các giai đoạn thiết kế tiếp theo.
Bước 4: Các điểm nổi bật
Để xác định các điểm nổi bật trong kiến trúc ứng dụng, cần dựa vào những tiêu chí như sau: đầu tiên, cần nhận diện các điểm nổi bật để hiểu rõ những thiếu sót trong thiết kế Các điểm nổi bật này thường đượ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 Thứ hai, khung kiến trúc đóng vai trò quan trọng trong việc thể hiện các mối quan tâm xuyên suốt, ảnh hưởng đến thiết kế qua từng tầng và lớp, đồng thời là nơi dễ xảy ra sai lầm thiết kế Việc sử dụng khung kiến trúc sẽ giúp xác định rõ các điểm nổi bật cần chú ý.
Trong thiết kế của bạn, việc sử dụng yếu tố "nóng" cần được chú ý đặc biệt để đạt được quyền lực Để xác định mối quan tâm này, bạn có thể áp dụng khung kiến trúc dưới đây 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]
Phạm vi Điểm nổi bật
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)
Bộ nhớ đệm và trạng thái
Làm thế nào để lựa chọn một công nghệ bộ nhớ đệm thích hợp
Làm thế nào để xác định những dữ liệu vào bộ nhớ đệm (cache)
Làm thế nào để xác định vị trí bộ nhớ đệm chứa dữ liệu
Làm thế nào để xác định chính sách hết hạn
Làm thế nào để lựa chọn giao thức thích hợp để giao tiếp giữa các lớp và các tầng
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 bộ
Là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 giao diện người dùng
Làm thế nào để tránh sự phụ thuộc giữa các mô đun trong giao diệ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 Đồng nhất và giao dịch (Concurrency and Transactions)
Làm thế nào để xử lý đồng bộ giữa các tiến trình (thread)
Làm thế nào để lựa chọn giữa đồng thời ƣu điểm và nhƣợc điểm
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 những thông tin cần phải đƣợc cấu hình
Làm thế nào để xác định vị trí và lưu trữ thông tin cấu hình
Là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 vùng / cụm
Kết nối và gắn kết (Coupling and Cohesion)
Làm thế nào để lựa chọn một chiến lƣợc thích hợp để tách các mối quan tâm
Làm thế nào để thiết kế các thành phần gắn kết và nhóm chúng trong lớp
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
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
Xác nhận Làm thế nào để xác định nơi và làm thế nào để thực
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
Quy trình làm việc(Workflow)
Làm thế nào để lựa chọn công nghệ, quy trình làm việc thích hợp
Làm thế nào để xử lý các vấn đề đồng thời trong một quy trình làm việc
Làm thế nào để xử lý thất bại của nhiệm vụ trong một quy trình làm việc
Làm thế nào để bố trí quy trình trong một quy trình làm việc
Bước 5: Lựa chọn giải pháp
Sau khi xác định các điểm nổi bật quan trọng, bạn có thể tạo ra các thiết kế đầu tiên và đi vào chi tiết để xây dựng một kiến trúc phù hợp Tiếp theo, hãy quay lại bước trước để xác nhận thiết kế giải pháp ứng viên, xem lại các kịch bản chính và yêu cầu đã xác định Quá trình này nên lặp đi lặp lại để cải tiến thiết kế kiến trúc, nhằm tạo ra một nguyên mẫu thiết kế giúp đánh giá tính khả thi của các phương án Sử dụng các phương pháp nhằm giảm rủi ro và nhanh chóng xác định tính khả thi của các tiếp cận khác nhau, đồng thời kiểm tra kiến trúc xem có phù hợp với các kịch bản chính và điểm nổi bật hay không.
Đánh giá ƣu nhƣợc điểm của SAD
TRONGYTẾ 3.1 Quy trình khám, chữa bệnh
Sau khi tiến hành khảo sát và phân tích thực tế tại các bệnh viện, quy trình chung mà bệnh nhân thực hiện khi đến làm thủ tục khám chữa bệnh đã được mô tả trong hình 3.1.
Hình 3.1: Quy trình khám chữa bệnh
Khi bệnh nhân đến bệnh viện để đăng ký khám chữa bệnh, họ sẽ thực hiện các bước sau: Đầu tiên, bệnh nhân đến quầy lễ tân để làm thủ tục đăng ký, cung cấp thông tin như họ tên, ngày sinh, giới tính và thẻ bảo hiểm Những thông tin này sẽ được nhập vào hệ thống quản lý thông tin bệnh nhân và bệnh nhân nhận sổ khám chữa bệnh Tiếp theo, bệnh nhân mang sổ này đến gặp lễ tân các khoa, cụ thể là khoa ngoại chỉnh hình, để được khám và chẩn đoán bệnh Nếu cần thiết, bác sĩ sẽ đánh giá tình trạng và phát phiếu yêu cầu chụp X-quang.
TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ, XỬ LÝ ẢNH
Quy trình khám, chữa bệnh
Sau khi thực hiện khảo sát và phân tích tại các bệnh viện, quy trình chung khi bệnh nhân đến làm thủ tục khám chữa bệnh đã được mô tả trong hình 3.1.
Hình 3.1: Quy trình khám chữa bệnh
Khi bệnh nhân đến bệnh viện để đăng ký khám chữa bệnh, họ sẽ thực hiện các bước sau: Đầu tiên, bệnh nhân tới quầy lễ tân để đăng ký, cung cấp thông tin như họ tên, ngày sinh, giới tính và thẻ bảo hiểm, sau đó nhận sổ khám chữa bệnh Tiếp theo, bệnh nhân sẽ mang sổ này đến gặp lễ tân các khoa, đặc biệt là khoa ngoại chỉnh hình, để được khám và chẩn đoán bệnh Nếu cần thiết, bác sĩ sẽ phát phiếu yêu cầu chụp X-quang Bệnh nhân mang phiếu yêu cầu đến phòng chụp, nơi bác sĩ sẽ thực hiện chụp X-quang Cuối cùng, thông tin về ảnh X-quang sẽ được ghi ra phim và gửi tới khoa ngoại chỉnh hình, nơi bác sĩ sử dụng phần mềm để phân tích và chẩn đoán chính xác hơn bằng cách điều chỉnh độ tương phản và tập trung vào các vùng quan tâm.
Sau khi quan sát và rút ra kết luận, thông tin bệnh nhân như tên, tuổi và các thông số ảnh X-quang như kích thước dài, rộng cùng đường dẫn tới ảnh thô ban đầu sẽ được lưu trữ trong file DDO (DICOM Data Object) Ảnh X-quang sẽ được lưu dưới dạng file ảnh thô (raw file) với định dạng (*.std, *.hq).
Bước tiếp theo bác sĩ sẽ đưa ra các kết luận cho người bệnh, và quá trình điều trị nếu có
Cuối cùng bệnh nhân sẽ qua quầy lễ tân để thanh toán các chi phí liên quan cho quá trình khám, điều trị bệnh.
Phân tích xử lý nghiệp vụ
Dựa vào quy trình khám chữa bệnh ở hình 3.1 và quá trình phân tích, ta có thể phân chia hệ thống thành các khối chức năng chính sau:
Chức năng quản lý thông tin bệnh nhân (Recept) cho phép nhập và lưu trữ thông tin bệnh nhân vào cơ sở dữ liệu của bệnh viện Sau khi thông tin được lưu, người dùng có thể dễ dàng tìm kiếm thông tin bệnh nhân Ngoài ra, chức năng này còn hỗ trợ xử lý thanh toán dựa trên quá trình khám chữa bệnh của bệnh nhân.
Ngoài ra chức năng này còn gọi tới chức năng chụp ảnh và chức năng quan sát, chuẩn đoán bệnh thông qua hình ảnh
Chi tiết chức năng quản lý thông tin bệnh nhân đƣợc mô tả qua biểu đồ ca sử dụng (use case) ở hình 3.2 dưới đây:
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 Chức năng quản lý quá trình chụp ảnh
Chức năng chụp ảnh X-quang cho phép ghi lại hình ảnh bệnh nhân thông qua các thiết bị phần cứng chuyên dụng Sau khi chụp, thông tin liên quan đến bệnh nhân, kích thước ảnh và tọa độ sẽ được lưu trữ vào ổ cứng trong các file chứa thông tin Dữ liệu ảnh X-quang được lưu dưới các định dạng file như *.std (chuẩn) và *.hq (chất lượng cao).
Sau khi ghi lại các thông tin cần thiết, chức năng này sẽ hiển thị kết quả hình ảnh vừa chụp cho bác sĩ Sau khi hoàn tất quá trình chụp, bác sĩ có thể chuyển sang chức năng quản lý thông tin bệnh nhân (Recept) hoặc chức năng quan sát và chẩn đoán bệnh qua hình ảnh (QA).
Hình 3.3: Sơ đồ ca sử dụng của chức năng quản lý quá trình chụp ảnh uc Recept
Quản lý thông tin bệnh nhân
Hiển thị thông tin bệnh nhân
Thêm mới thông tin bệnh nhân
Sửa thông tin bệnh nhân
Xóa thông tin bệnh nhân
Tìm kiếm thông tin bệnh nhân
Xử lý thanh toán tiền
Chuyển hướng tới chức năng khác
Lưu trữ thông tin bệnh nhân
Lễ tân ôincludeằ ôincludeằ ôincludeằ ôincludeằ ôincludeằ ôincludeằ uc Study
Quản lý quá trình chụp ảnh
Kết nối v ới phần cứng
Ghi thông tin v ề ảnh xuống file
Tạo ảnh (*.std, *.hq) Chuyển hướng tới file chức năng khác
Hiển thị ảnh v ừa chụp
Xử lý ảnh v ừa chụp ôincludeằ ôincludeằ ôincludeằ ôincludeằ ôincludeằ
Chức năng quan sát, thay đổi và chuẩn đoán bệnh thông qua hình ảnh là yếu tố quan trọng nhất của hệ thống, giúp bác sĩ dễ dàng và nhanh chóng chẩn đoán bệnh một cách chính xác Sự phát triển của công nghệ thông tin cùng với các nghiên cứu và thuật toán xử lý ảnh đã được áp dụng triệt để để hỗ trợ bác sĩ hiệu quả Biểu đồ ca sử dụng trong hình 3.4 dưới đây minh họa chi tiết chức năng này.
Hình 3.4: Sơ đồ ca sử dụng của chức năng thao tác với ảnh
Hình 3.4 trình bày các chức năng điển hình của việc quan sát, thay đổi và chẩn đoán bệnh qua hình ảnh Một số chức năng phổ biến khi thao tác với ảnh bao gồm phóng to và thu nhỏ Tuy nhiên, cũng có những chức năng đặc trưng riêng cho xử lý ảnh trong y tế, chẳng hạn như khả năng kết nối các ảnh thành phần, cho phép bác sĩ thực hiện kết nối tự động hoặc thủ công Khi chụp ảnh y tế, do cơ thể con người thường cao và dài hơn khả năng chụp gần của máy, các bộ phận sẽ được chụp thành các phần riêng biệt, ví dụ như vai, lưng và hông.
Thay đổi độ tương phản
Thay đổi thông số của ảnh
Xử lý làm đen Đánh dấu trên ảnh
Xử lý nối các ảnh thành phần
Hiện thị ảnh lên màn hình
Xử lý kết nối ảnh cho phép bác sĩ chụp và quan sát từng ảnh thành phần, sau đó ghép chúng lại thành một ảnh hoàn chỉnh của cơ thể người Chức năng làm đen giúp bác sĩ loại bỏ những phần không quan trọng, tập trung vào các điểm chính, từ đó nâng cao tốc độ và độ chính xác trong quá trình chẩn đoán bệnh.
THIẾT KẾ KIẾN TRÚC CHO HỆ THỐNG QUẢN LÝ, XỬ LÝ ẢNH TRONG Y TẾ
Thiết kế kiến trúc tổng thể cho hệ thống
Thiết kế kiến trúc hệ thống sẽ được thực hiện dựa trên năm bước chi tiết đã được nêu trong mục 2.4 về các bước thiết kế kiến trúc phần mềm trong chương 2.
Mục tiêu kiến trúc là phân tích và thiết kế hệ thống lớn với độ phức tạp cao, đảm bảo sự phối hợp hiệu quả giữa phần cứng và phần mềm Giai đoạn này yêu cầu phân rã hệ thống thành các phần nhỏ hơn, thiết lập cơ chế làm việc phù hợp giữa chúng Đồng thời, cần đưa ra quy định và định hướng cho các phần thiết kế kiến trúc tiếp theo, nhằm hỗ trợ các nhà phát triển và kỹ sư trong việc thiết kế chức năng cụ thể Việc sử dụng các ngôn ngữ nghiệp vụ và biểu đồ UML như biểu đồ ca sử dụng hay biểu đồ hoạt động là cần thiết Do hệ thống bao gồm cả nâng cấp và làm mới, tài liệu cần được viết chi tiết, dễ hiểu để phục vụ cho quá trình kiểm thử.
Hệ thống cần hỗ trợ nhiều thiết bị phần cứng, từ thế hệ cũ đến mới, yêu cầu lựa chọn công nghệ dễ dàng tương thích Để đảm bảo hiệu suất cao và xử lý nhanh chóng, cần chọn công nghệ phù hợp có khả năng can thiệp sâu vào hệ thống và bộ nhớ Đồng thời, công nghệ cũng phải hỗ trợ tốt cho việc xử lý giao diện, đảm bảo độ tùy biến cao nhằm tạo ra trải nghiệm người dùng thân thiện trong quá trình phát triển.
Hệ thống quản lý thông tin bệnh nhân cung cấp chức năng thêm mới, tìm kiếm và chỉnh sửa thông tin bệnh nhân Nó cho phép lựa chọn kiểu chụp và kết nối với phần cứng để thực hiện chụp ảnh Sau khi chụp, hệ thống xử lý và hiển thị ảnh trên màn hình, giúp bác sĩ thực hiện các thao tác với ảnh một cách dễ dàng và hiệu quả.
Kết quả ảnh chụp ảnh hưởng lớn đến quá trình xử lý và hiển thị, do đó kịch bản chụp ảnh cần được thiết kế tối ưu để đảm bảo thành công của ứng dụng Ảnh sau khi chụp sẽ được xử lý và hiển thị cho bác sĩ, ảnh hưởng trực tiếp đến độ chính xác trong chẩn đoán bệnh Giai đoạn thiết kế tổng quan cần phân tích kỹ lưỡng các tình huống người dùng, như cách mở chương trình và tốc độ phản hồi Người dùng chấp nhận thời gian mở chương trình chậm lần đầu, nhưng yêu cầu các chức năng hoạt động nhanh chóng sau đó Từ đó, thiết kế kiến trúc sẽ đưa ra giải pháp phù hợp, bao gồm việc đọc tất cả thông tin cần thiết từ các file như Icon, Bitmap khi mở chương trình.
Người dùng có thể tìm kiếm và nhập thông tin bệnh nhân, kết nối với thiết bị phần cứng để chụp và chỉnh sửa ảnh Những tình huống này tạo ra các tình huống hệ thống và nghiệp vụ tương ứng, giúp nhận diện ba thành phần chính: quản lý thông tin bệnh nhân, quản lý kết nối với phần cứng, và quản lý quá trình xử lý và hiển thị ảnh Thiết kế kiến trúc cần phân tích ưu nhược điểm của việc gộp ba thành phần này thành một hệ thống lớn hay tách ra thành ba hệ thống nhỏ hơn Hình ảnh mô tả kịch bản chụp ảnh, với các tình huống người dùng, hệ thống và nghiệp vụ được thể hiện chi tiết theo luồng xử lý trong hình 4.1.
Hình 4.1: Kịch bản chụp ảnh
Ứng dụng này hỗ trợ bác sĩ trong quá trình chẩn đoán và khám chữa bệnh, yêu cầu xử lý nhanh chóng và chính xác Nó cần tương tác dễ dàng với các thiết bị phần cứng và có khả năng hiển thị trên hai màn hình Để đáp ứng các yêu cầu này, nên lựa chọn ứng dụng dạng desktop, cụ thể là ứng dụng trên nền tảng Windows, có thể triển khai trên các hệ điều hành Windows khác nhau.
Khi triển khai các ứng dụng trên các hệ điều hành như XP, Windows Vista và Windows 7, việc trao đổi giữa các ứng dụng là rất quan trọng Các ứng dụng này cần được tối ưu hóa để hoạt động hiệu quả như các dịch vụ, đảm bảo khả năng tương tác tốt trên các nền tảng khác nhau.
Quá trình phân tích cho thấy các chức năng lớn có thể hoạt động độc lập hoặc tương tác với nhau trong quá trình làm việc Chúng ta có thể thiết kế các chức năng này dưới dạng thư viện liên kết động (Dynamic Link Library – DLL), cho phép gọi lẫn nhau khi cần thiết Giải pháp này giúp khắc phục vấn đề hoạt động độc lập nhưng không đáp ứng yêu cầu thời gian thực khi thực hiện hành động ChupAnh.
Người dùng Hệ thống Nghiệp vụ
Khởi động chức năng chụp ảnh Thực hiện kết nối v ới phần cứng
Thông báo trạng thái sẵn sàng
Nhập thông tin liên quan tới bệnh nhân
Nhấn lên nút [chup ảnh] Thực hiện kiểm tra thông tin
Xác thực thông tin bệnh nhân
Yêu cầu thông tin về bệnh nhân:
- Mã bênh nhân: Không được phép trống và chưa tồn tại trong CSDL
- Tên bệnh nhân không được phép trống
- Các thông tin là tùy chọn
Xác định loại ống chụp dựa v ào kiểu chụp Thực hiện chụp ảnh
Thực hiện lưu trữ dữ liệu v ề ảnh v ào ổ cứng
Hiển thị ảnh được chụp lên màn hình
Thông báo quá trình chụp ảnh thành công
Để hệ thống hoạt động hiệu quả, các chức năng lớn cần phối hợp chặt chẽ với nhau Mỗi chức năng lớn bao gồm nhiều chức năng nhỏ, và việc khởi động chúng thường tốn nhiều thời gian Sự tương tác giữa các chức năng lớn diễn ra thường xuyên và yêu cầu tính nhanh nhạy Các chức năng lớn này phải được khởi động cùng lúc với hệ thống và chỉ kết thúc khi hệ thống hoàn tất quá trình làm việc Do đó, việc thiết kế các chức năng lớn dưới dạng các dịch vụ (các file *.exe) là cần thiết, và kiến trúc phù hợp cho yêu cầu này là Message-bus.
Công nghệ được lựa chọn trong bài viết này là Microsoft NET Framework 3.5 (Visual Studio 2008), một môi trường phát triển tích hợp (IDE) mạnh mẽ hỗ trợ tốt cho quá trình phát triển ứng dụng Nó tương thích với cả thiết bị phần cứng cũ và hiện đại, giúp đơn giản hóa việc bảo trì và nâng cấp phiên bản Đặc biệt, công nghệ này tích hợp WCF (Windows Communication Foundation), hỗ trợ hiệu quả cho việc chuyển, nhận và quản lý thông điệp Do đó, kiến trúc của công nghệ này rất phù hợp cho các ứng dụng hiện đại.
Giao thức phù hợp cho việc giao tiếp giữa các dịch vụ (SS) là rất quan trọng WCF là lựa chọn tối ưu cho việc truyền nhận thông điệp Đối với các ứng dụng lớn, cần thiết phải có cơ chế quản lý và ghi lỗi chặt chẽ để hỗ trợ hiệu quả cho quá trình điều tra lỗi khi cần thiết.
Các ứng dụng cần được thiết kế độc lập và lỏng lẻo, với việc phân chia thành các SS (dịch vụ) đảm nhiệm những công việc cụ thể Chẳng hạn, SS Recept quản lý thông tin bệnh nhân, trong khi SS QA xử lý và hiển thị ảnh, đồng thời cho phép bác sĩ thực hiện các chỉnh sửa dễ dàng Các SS hoạt động như những dịch vụ độc lập, yêu cầu có cơ chế đồng bộ hóa giữa các tiến trình (thread) để quản lý dữ liệu hiệu quả Hệ thống có nhiều tiến trình chạy song song và tương tác lẫn nhau, ví dụ, khi tiến trình A đang hiển thị ảnh, tiến trình B có thể yêu cầu xử lý ảnh mới, đòi hỏi một cơ chế quản lý và đồng bộ dữ liệu giữa các tiến trình.
Trong việc lựa chọn giải pháp phát triển phần mềm, kiến trúc Message-bus được ưu tiên, đồng thời tất cả giao diện người dùng phải được xây dựng bằng C# Đối với mã nguồn viết trên hai môi trường C# và C++, cần sử dụng kết nối Adaptor Phương châm xử lý lỗi bao gồm việc phân cấp mức độ lỗi, ghi lại lỗi vào file và event log của Windows, cũng như trả mã lỗi cho lớp cao hơn Đặc biệt, trên giao diện người dùng, cần thực hiện bẫy và bắt lỗi để tránh tình trạng chương trình bị hỏng trong quá trình hoạt động Công nghệ sử dụng là Microsoft NET Framework 3.5 với Visual Studio 2008.
Kết quả của thiết kế kiến trúc được mô tả theo hình 4.2 dưới đây:
Hình 4.2: Kiến trúc tổng thể của hệ thống Đặc điểm của thiết kế kiến trúc tổng thể trong hình 4.2 đƣợc mô tả chi tiết trong bảng 4.1
Bảng 4.1: Đặc điểm của thiết kế kiến trúc tổng thể
Kiểu kiến trúc Message-bus
Trong hệ thống, các thành phần chính bao gồm Study, Recept, QA và ASSEMBLE Study là thành phần kết nối với phần cứng và thực hiện chụp ảnh Recept quản lý thông tin liên quan đến bệnh nhân QA xử lý và hiển thị ảnh trên màn hình, hỗ trợ bác sĩ bằng cách kết nối các ảnh thành phần, điều chỉnh độ sáng tối để nâng cao quá trình chẩn đoán ASSEMBLE hoạt động như một dịch vụ nền, điều phối công việc giữa các thành phần trong hệ thống.
Thiết kế cho chức năng lớn trong hệ thống
Sau khi hoàn thiện thiết kế kiến trúc tổng thể cho hệ thống, chúng tôi tiến hành thiết kế kiến trúc cho các chức năng lớn của các SS Giai đoạn này tuân thủ năm bước như thiết kế kiến trúc tổng quan, nhưng có sự phân tích khác biệt cho từng chức năng Bài viết này sẽ trình bày chi tiết thiết kế kiến trúc cho chức năng kết nối các ảnh thành phần trong SS QA.
Xác định mục tiêu kiến trúc
Chức năng này xử lý và hiển thị ảnh, cho phép người dùng kết nối các ảnh thành phần thành một ảnh duy nhất theo cách thủ công hoặc tự động Thiết kế kiến trúc cần đảm bảo đầy đủ để hỗ trợ quá trình thiết kế chi tiết, đưa ra các thành phần cụ thể như tên dự án và gói phát triển trên C#, C++ Đối tượng sử dụng chính là người thực hiện thiết kế chi tiết và viết mã nguồn, do đó cần sử dụng ngôn ngữ lập trình liên quan như dự án, thư viện, phương thức, cùng với các biểu đồ trong UML như biểu đồ hoạt động và biểu đồ cộng tác.
Kịch bản chính cho phép người dùng kết nối các ảnh thành phần, dựa trên các ca sử dụng nghiệp vụ quan trọng trong quá trình xử lý và hiển thị ảnh Thời gian xử lý nhanh hay chậm, cùng với việc ảnh thành phần được hiển thị đúng vị trí và chất lượng ảnh tốt hay không, đều phụ thuộc vào thiết kế hợp lý của các thành phần, nhằm đảm bảo hiệu suất xử lý và hiển thị chính xác.
Quá trình kết nối giữa các ảnh thành phần sẽ được thiết kế rõ ràng trong kiến trúc, nhấn mạnh tầm quan trọng của các tình huống người dùng Việc liệt kê và xử lý các tình huống này là cần thiết để đảm bảo tính tương thích và hiệu quả trong thiết kế Các tình huống điển hình bao gồm cách người dùng mở chức năng, thực hiện thao tác trên các ảnh thành phần và kết nối chúng với nhau Mỗi tình huống người dùng sẽ tương ứng với các tình huống nghiệp vụ, và để mô tả chi tiết, chúng tôi sẽ vẽ biểu đồ hoạt động cho từng tình huống Một ví dụ cụ thể sẽ được trình bày khi màn hình kết nối ảnh đã mở và các ảnh thành phần được hiển thị, minh họa qua biểu đồ hoạt động.
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
Ứng dụng này được xây dựng trên hai nền tảng khác nhau, với giao diện người dùng được phát triển bằng Visual C# để tối ưu hóa khả năng đồ họa và tạo ra môi trường phát triển thuận tiện Trong khi đó, việc xử lý ảnh được thực hiện bằng C++ nhằm tận dụng hiệu suất cao trong việc xử lý dữ liệu hình ảnh.
Hành động của người dùng
Lựa chọn cách hiển thị ảnh
Hiển thị kích thước phù hợp HIểu thị kích thước theo pixel
Hiển thị theo kích thước ảnh thật
Xét chế độ hiển thị
Vẽ lại tất cả ảnh thành phần
Hành động người dùng thay đổi vị trí ảnh thành phần
Chỉ định 2 điểm kết hợp
Chọn một điểm trên ảnh thứ nhất Điều chỉnh vị trí nhỏ cho ảnh một ảnh thành phần
Kiểm tra vị trí các ảnh phù hợp không?
Vị trí không phù hợp?
Hiển thị thông điệp lỗi Kết nối 2 ảnh thành phần
Quay trở lại hành động trước đó
Chọn chức năng quay lại thao tác gần nhất
Di chuột thay đổi vị trí một ảnh thành phần
Thứ tự từ trên xuống Thứ tự từ dưới lên
Lưu trữ chế độ sắp xếp
Chọn một điểm trên ảnh thứ hai để điều chỉnh vị trí cho tất cả ảnh thành phần Sử dụng chế độ 2 điểm kết hợp để đánh dấu và chuyển động một ảnh thành phần Cuối cùng, áp dụng chế độ di chuyển để điều chỉnh tất cả ảnh thành phần một cách đồng bộ.
Di chuyển chuột thay đổi vị trí tất cả các ảnh thành phần
Người dùng nhấn lên nut [Undo]
Xử lý quay lại hành động gần nhất
Sắp xếp trình tự hiển thị các ảnh thành phần
[True] thế của C++ Khi thiết kế kiến trúc chúng tôi tập trung phân tích giải quyết để chúng làm việc hài hòa, ổn định
Trong C++, các lớp chỉ cung cấp một số phương thức nhất định để bên ngoài có thể truy cập Giao tiếp chỉ diễn ra từ C# sang C++, mà không có khả năng gọi ngược lại.
Cơ chế làm việc và quản lý tài nguyên giữa C# và C++ có sự khác biệt rõ rệt Do đó, việc quản lý, cấp phát và thu hồi bộ nhớ trong C++ cần được chú trọng, trong khi C# yêu cầu chú ý đến cơ chế hiển thị giao diện Điều này đảm bảo rằng ứng dụng có giao diện tương thích với nhiều loại màn hình có kích thước khác nhau.
Trong chương trình xử lý phức tạp, việc xác định nhanh chóng vùng bị lỗi trong môi trường phát triển là rất quan trọng Để thực hiện điều này, quá trình ghi lỗi cần phải được thực hiện một cách cẩn thận và chính xác Quy trình ghi lại lỗi này phải tuân theo các nguyên tắc đã được nêu trong phần Thiết kế kiến trúc tổng quát.
Để lựa chọn giải pháp, chúng ta thiết kế chức năng thành các nhóm thành phần chính: các thành phần giao diện người dùng sử dụng C#, trong khi các thành phần xử lý và hiển thị ảnh sử dụng C++ Các thành phần C# sẽ gọi tới các thành phần C++ Dựa vào các tình huống người dùng, tình huống nghiệp vụ và tình huống hệ thống trong kịch bản chính, chúng ta có thể thiết kế các thành phần và giao diện tương ứng Hình minh họa dưới đây thể hiện các thành phần được xác định dựa trên các tình huống này khi mở chức năng.
Kết quả thiết kế kiến trúc phụ thuộc vào các tình huống người dùng, tình huống nghiệp vụ và tình huống hệ thống, như được thể hiện trong hình 4.4.
Thiết kế kiến trúc dựa trên tình huống người dùng, nghiệp vụ và hệ thống khi mở màn hình kết nối được thể hiện trong Hình 4.4 Các thành phần trong hình này được mô tả chi tiết trong Bảng 4.2.
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
Kiểu kiến trúc Program and Subroutines (object-oriented)
Các thành phần của dự án bao gồm nhiều gói viết bằng C# và C++ Cụ thể, MainScreen là dự án C# đảm nhiệm vai trò màn hình chính của chương trình CombineScreen, cũng viết bằng C#, là màn hình dùng để kết nối các ảnh thành một bức ảnh hoàn chỉnh StitchImageView là một dự án C++ thực hiện việc điều phối quá trình xử lý và hiển thị ảnh ImgPrm là thư viện C++ chung, có chức năng đọc thông tin liên quan đến ảnh như đường dẫn và loại ảnh Cuối cùng, ImageProcessor, cũng là một thư viện C++, đảm nhận việc đọc và xử lý thông tin ảnh.
Kết nối Các thông điệp, phương thức
Giao diện Dự án CombineSreen sử dụng giao diện
PreviewImageFPD() của dự án StitchImageView
Dự án StitchImageView sử dụng giao diện ACCModImgProcGetter() của dự án ImgPrm
Dự án StitchImageView sử dụng giao diện FCDModImgProc() của dự án ImageProcessor
CÀI ĐẶT KIẾN TRÚC PHẦN MỀM
Cách thức cài đặt kiến trúc phần mềm
Khi làm việc với hệ thống nhỏ và không quá phức tạp, chúng ta có thể bỏ qua giai đoạn phân tích hệ thống (SAD) và tiến thẳng vào việc viết mã nguồn Đối với các website, lập trình viên thường quen thuộc với kiến trúc và mô hình như MVC (Model View Control), giúp họ dễ dàng tổ chức mã nguồn và thực hiện cài đặt Tuy nhiên, nếu hệ thống nhỏ tập trung vào các xử lý logic hoặc thuật toán phức tạp, việc xây dựng tài liệu thiết kế hệ thống (SDD) sẽ là cần thiết trước khi tiến hành cài đặt.
Trong các hệ thống xử lý lớn và phức tạp, SAD chỉ cung cấp cái nhìn tổng quát về sự liên kết và cách thức hoạt động giữa các thành phần, mà chưa đi sâu vào chi tiết cách thức làm việc cụ thể và logic hoạt động Điều này đặt ra thách thức trong việc lựa chọn phương pháp và công nghệ phù hợp để hạn chế rủi ro Do đó, SAD trở thành đầu vào quan trọng cho giai đoạn thiết kế hệ thống (SDD).
Phương pháp đi từ thiết kế kiến trúc tới thiết kế chi tiết
Trong thiết kế hệ thống, SAD tổng quan chia nhỏ hệ thống lớn thành các hệ thống nhỏ hơn, với các thành phần là các SS Để tiến tới thiết kế SDD, cần thiết kế SAD cho từng SS, và thường dừng lại khi các thành phần tương ứng với các dự án hoặc gói Các thành phần chính trong SAD bao gồm thành phần, kết nối, giao diện và cấu hình, trong khi SDD tập trung vào lớp, phương thức, giao diện, biểu đồ lớp, biểu đồ trình tự và biểu đồ hoạt động Tài liệu SAD giúp quá trình tạo SDD trở nên dễ dàng hơn thông qua việc ánh xạ các thành phần từ SAD sang SDD.
Bảng 5.1: Ánh xạ các thành phần trong SAD với SDD
STT SAD SDD Ánh xạ
Mỗi thành phần trong hệ thống thường được ánh xạ tới một hoặc nhiều dự án hoặc gói, với mỗi dự án đảm nhiệm các chức năng chuyên biệt Trong từng dự án, sẽ có một hoặc nhiều lớp được thiết kế để xử lý các loại file dữ liệu khác nhau như *.txt hay *.xml Mục tiêu là tối ưu hóa quá trình đọc và ghi dữ liệu vào các loại file này một cách dễ dàng và tiện lợi.
Khi thiết kế các lớp trong dự án, việc hiểu chức năng chung là rất quan trọng để đạt hiệu quả tối ưu Các nguyên lý thiết kế hướng đối tượng như Nguyên lý đóng mở (Open Close Principle) cho phép mở rộng tính năng mà không cần sửa đổi mã nguồn, giúp hệ thống ổn định hơn Nguyên lý thay thế Liskov (Liskov Substitution Principle) đảm bảo rằng các lớp con có thể thay thế lớp cơ sở mà không làm ảnh hưởng đến chức năng hệ thống Nguyên lý nghịch đảo phụ (Dependency Inversion Principle) nhấn mạnh rằng các module nên phụ thuộc vào trừu tượng thay vì chi tiết, tạo ra sự linh hoạt trong thiết kế Cuối cùng, Nguyên lý ISP (Interface Segregation Principle) khuyến khích việc tạo ra nhiều giao diện chuyên biệt cho từng nhu cầu của client, thay vì sử dụng một giao diện chung.
2 Connector Lời gọi hàm, cách trao đổi thông điệp giữa các đối tƣợng
Cầu nối giữa các dự án đóng vai trò quan trọng trong việc kết nối các lớp của dự án Khi các dự án được chia nhỏ, sự giao tiếp giữa các lớp sẽ được thể hiện qua các loại kết nối khác nhau, phản ánh cách gọi hàm và trao đổi thông điệp giữa các đối tượng Điều này sẽ được minh họa trong sơ đồ lớp và sơ đồ tuần tự trong tài liệu thiết kế hệ thống (SDD).
Giao diện trong SAD thể hiện tổng quát việc gửi nhận thông điệp và tương tác giữa các thành phần, với mỗi kiểu kiến trúc có giao diện riêng Trong SDD, cần mô tả chi tiết ý nghĩa của từng tham số, đầu vào và đầu ra của các giao diện và phương thức Một giao diện trong SAD có thể cần được chia nhỏ thành nhiều giao diện và phương thức trong SDD để phù hợp với thiết kế Ví dụ, với kiến trúc Message-bus, giao diện chỉ nêu chung đầu vào là thông điệp định dạng XML và đầu ra là mã lỗi, nhưng trong SDD, cần xác định rõ cấu trúc XML, bao gồm các phần tử và ý nghĩa của chúng.
Mã lỗi trả về cần phải thể hiện rõ ràng ý nghĩa của lỗi tương ứng với giá trị của mã Để thực hiện điều này, chúng ta cần xây dựng một phương thức để đọc và phân tích XML, nhằm lấy ra các giá trị cần thiết Phương thức này cũng cần xác định rõ đầu vào và đầu ra của nó.
4 Configurati on Đối tƣợng tham gia vào quá trình tương tác, xử lý
Logic xử lý trong biểu đồ trình tự
Các thành phần tham gia trong sơ đồ lớp
Cấu hình trong SAD thể hiện sự tương tác và phụ thuộc giữa các thành phần, trong khi SDD cần chi tiết hóa sự phụ thuộc này Điều này bao gồm số lượng dự án, lớp trong sơ đồ lớp và logic xử lý trong biểu đồ tuần tự Hệ thống lưu trữ dữ liệu ở các loại CSDL khác nhau như SQL Server, Access, hoặc file XML, và tùy thuộc vào cấu hình người dùng, dữ liệu sẽ được truy xuất từ một trong các nguồn này Do đó, cần có thêm lớp và phương thức để xử lý chuyên biệt cho từng loại dữ liệu, đồng thời mô tả rõ ràng thời điểm sử dụng loại dữ liệu nào, có thể dựa trên giá trị nhất định, và gọi phương thức phù hợp.
So sánh SAD và SDD
Bảng 5.2 sau đây là một số tiêu chí so sánh giữa SAD và SDD
Bảng 5.2: So sánh SAD với SDD
Các thành phần, kết nối, giao diện, cấu hình
Các lớp, sự phụ thuộc giữa các đối tượng, logic xử lý, phương thức
Tương tác Giữa các thành phần Giữa đối tượng của các lớp thuộc các gói khác nhau hoặc trong cùng gói
Mô tả Mô tả chung, có tính phác thảo, định hướng, chưa quan tâm tới chi tiết cài đặt
Mô tả chi tiết tới từng đơn vị nhỏ nhất của lập trình như các phương thức, có thể sử dụng để cài đặt luôn
Phạm vi Phạm vi lớn, gần nhƣ toàn bộ hệ thống
Phạm vi thường nhỏ gọn bên trong các gói
Kiến thức yêu cầu người có kinh nghiệm và hiểu biết sâu rộng về hệ thống, trong khi yêu cầu đơn giản hơn chỉ cần người có kỹ năng công nghệ phát triển đang được lựa chọn Đầu vào chủ yếu là SRS, cùng với một số tài liệu mô tả mức cao về hệ thống.
SAD, SRS Đầu ra Tài liệu thiết kế kiến trúc cho hệ thống, làm đầu vào cho giai đoạn làm SDD (hoặc cài đặt), và kiểm thử tích hợp
Tài liệu thiết kế chi tiết bao gồm mã nguồn, khung lớp và các phương thức sử dụng công cụ thiết kế UML Tài liệu này rất quan trọng trong giai đoạn cài đặt và kiểm thử đơn vị (Unit testing).
Vị trí Là một giai đoạn trong phát triển phần mềm
Cũng là một giai đoạn trong phát triển phần mềm.