Thiết kế kiến trúc cho hệ thống sẽ dựa vào năm bƣớc đã đƣợc trình bày chi tiết
trong mục 2.4 Các bước thiết kế kiến trúc phần mềm của chƣơng 2.
Xác định mục tiêu kiến trúc
Đây là hệ thống rất lớn, độ phức tạp cao, có sự trao đổi phối hợp làm việc phức tạp giữa phần cứng, phần mềm nên mục tiêu là cần phân tích một cách tỉ mỉ, kĩ lƣỡng, sau đó thiết kế kiến trúc một cách chi tiết. Giai đoạn này cần phân rã hệ thống lớn thành các hệ thống nhỏ hơn, đảm bảo có cơ chế phù hợp giữa chúng để có thể làm việc hiệu quả. Mặt khác thiết kế kiến trúc trong giai đoạn này cần đƣa ra những quy định, định hƣớng để các các phần thiết kế kiến trúc sau cho hệ thống, chức năng nhỏ hơn có thể làm theo.
Đối tƣợng sử dụng chủ yếu kiến trúc này là các nhà phát triển, các kĩ sƣ thiết kế kiến trúc cho các chức năng cụ thể nên có thể sử dụng nhiều ngôn ngữ liên quan tới nghiệp vụ nhƣ: thực đơn chụp ảnh (chụp vai, cổ, lƣng ...), bệnh nhân… hay các biểu đồ UML nhƣ biểu đồ ca sử dụng, biểu đồ hoạt động, biểu đồ cộng tác… Ngoài ra do đây là hệ thống bao gồm cả nâng cấp và làm mới, mà SRS của dự án cũng không có nhiều nên cần viết một cách chi tiết, dễ hiểu để ngƣời kiểm thử có thể sử dụng tài liệu này để tham khảo cho quá trình tạo ca kiểm thử.
Hệ thống làm việc với nhiều thiết bị phần cứng, yêu cầu đặt ra phải lựa chọn công nghệ hỗ trợ các thiết bị phần cứng một cách dễ dàng cho dù là phần cứng thế hệ cũ hay mới nhất. Ngoài ra hệ thống cần phải đáp ứng việc xử lý một cách nhanh chóng, có hiệu năng tốt, can thiệp sâu vào hệ thống, bộ nhớ nên cần chọn công nghệ phù hợp. Mặt khác cũng cần công nghệ hỗ trợ tốt xử lý giao diện, độ tùy biến cao để dễ dàng cho quá trình phát triển và kết quả có giao diện thân thiện với ngƣời dùng.
Kịch bản chính
Đây là hệ thống quản lý thông tin về bệnh nhân, chụp ảnh, phân tích, đánh giá đƣa ra kết luận về tình trạng sức khỏe của bênh nhân, nên kịch bản chính có thể dựa trên các ca sử dụng nghiệp vụ quan trọng liên quan tới:
i. Quản lý thông tin về bệnh nhân: Thêm mới, tìm kiếm, chỉnh sửa thông tin
về bệnh nhân.
iii.Xử lý và hiển thị ảnh đã chụp trên màn hình, cho phép bác sĩ thực hiện các thao tác với ảnh trên màn hình một cách dễ dàng.
Kết quả ảnh chụp có ảnh hƣởng rất lớn tới quá trình xử lý và hiển thị ảnh sau này nên kịch bản liên quan tới chụp ảnh có ảnh hƣởng cao tới việc thành công của ứng dụng, nên thiết kế kiến trúc cần tập trung nghiên cứu, phân tích đƣa ra giải pháp tối ƣu cho phần chụp ảnh này. Mặt khác ảnh sau khi đƣợc chụp sẽ đƣợc xử lý và hiển thị lên màn hình phục vụ bác sĩ cho quá trình chuẩn đoán bệnh. Kết quả chuẩn đoán của bác sĩ sẽ chính xác hay không phụ thuộc rất lớn vào giai đoạn này, nên đây cũng là nơi mà thiết kế kiến trúc cần làm rõ, đƣa ra giải pháp phù hợp nhất.
Đây là giai đoạn thiết kế tổng quan, nên mọi thứ gần nhƣ là mới mẻ, cần phân tích kĩ lƣỡng. Ban đầu sẽ đi từ tình huống ngƣời sử dụng, chúng ta sẽ tìm hiểu và liệt kê tất tình huống ngƣời sử dụng, ví dụ nhƣ ngƣời dùng mở chƣơng trình ra sao, khi chƣơng trình mở lên phải nhanh hay cho phép một chậm sau một khoảng thời gian. Sau quá trình tìm hiểu, phân tích chúng tôi nhận thấy: ngƣời dùng chấp nhận lần đầu tiên mở chƣơng trình có thể chậm, nhƣng khi chƣơng trình mở lên thì các chức năng phải hoạt động nhanh, có độ trễ nhỏ. Từ đó thiết kế kiến trúc sẽ phân tích và đƣa ra giải pháp phù hợp cho vấn đề này. Và giải pháp đọc tất cả thông tin liên quan tới chƣơng trình nhƣ thông tin về cấu hình, dữ liệu cần thiết từ các file nhƣ Icon, Bitmap… khi mở chƣơng trình đƣợc đƣa ra.
Ngƣời dùng có thể thực hiện tìm kiếm thông tin về bệnh nhân, nhập thông tin về bệnh nhân, kết nối với thiết bị phần cứng để chụp ảnh, thao tác, chỉnh sửa ảnh đã đƣợc xử lý trên màn hình… Từ các tình huống ngƣời dùng này sẽ có sẽ kéo theo các tình huống hệ thống và tình huống nghiệp vụ tƣơng ứng. Các tình huống đó giúp ta có thể nhận ra ba thành phần riêng biệt là: Quản lý thông tin về bệnh nhân, quản lý quá trình kết nối và làm việc với phần cứng, quản lý quá trình xử lý, hiển thị và điều chỉnh ảnh. Khi đó thiết kế kiến trúc cần phân tích ƣu nhƣợc điểm nếu gộp tất cả ba thành phần đó thành một hệ thống lớn, hay tách chung ra thành ba thành hệ thống nhỏ hơn. Hình dƣới đây mô tả lại kịch bản của quá trình chụp ảnh. Khi ngƣời dùng thực hiện chụp ảnh, tình huống ngƣời dùng, hệ thống và nghiệp vụ đƣợc mô tả chi tiết theo luồng xử lý trong hình 4.1 dƣới đây.
Hình 4.1: Kịch bản chụp ảnh. Tổng quan ứng dụng
Ứng dụng này phục vụ cho một hoặc một nhóm bác sĩ trong quá trình chuẩn đoán, khám chữa bệnh. Ứng dụng cần các xử lý nhanh, chính xác, tƣơng tác dễ dàng với các phần cứng. Ngoài ra cần có khả năng xử lý và hiển thị trên 2 màn hình. Nên lựa chọn loại ứng dụng là trên desktop, window-base application.
Ứng dụng đƣợc triển khai trên hệ điều hành window khác nhau nhƣ: Window XP, Window Vista, Window 7. Khi triển khai các ứng dụng thƣờng xuyên phải trao đổi với nhau, các ứng dụng đƣợc yêu cầu nhƣ là các dịch vụ. Chúng đƣợc yêu cầu phải xử lý tốt trên các hệ điều hành khác nhau đó.
Quá trình phân tích chi tiết cho ta thấy các chức năng lớn này có khi hoạt động độc lập, nhƣng có khi lại có sự gọi tới nhau trong quá trình làm việc. Ta có thể thiết kế chúng là các thành phần dƣới dạng các các thƣ viện liên kết động (Dynamic Link Library – DLL), có thể gọi tới nhau khi cần thiết. Điều này sẽ giải quyết vấn đề họat động độc lập nhƣng không thỏa mãn thời gian thực khi
act ChupAnh
Người dùng Hệ thống Nghiệp vụ
Người dùng
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
Lựa chọn kiểu chụp
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
chúng cần làm việc với nhau. Nhƣ ta biết các chức năng lớn này có chứa rất nhiều chức năng nhỏ, mỗi khi khởi động chúng ta mất rất nhiều thời gian. Mặt khác giữa các chức năng lớn này làm việc với nhau là rất thƣờng xuyên, đòi hỏi phải nhanh chóng. Các chức năng lớn này phải đƣợc khởi động khi hệ thống khởi động, và chỉ thực sự kết thúc khi hệ thống kết thúc quá trình làm việc. Nhƣ vậy ở đây ta phải thiết kế các chức năng lớn này dƣới dạng các SS, mỗi SS này họat động dƣới dạng dịch vụ (các file *.exe). Nhƣ vậy kiểu kiến trúc đáp ứng đƣợc yêu cầu này là: Message-bus.
Công nghệ ở đây ta lựa chọn là Microsoft .NET Framework 3.5 (Visual studio 2008). Đây là công nghệ mới có môi trƣờng phát triển tích hợp (Integrated Development Environment – IDE) mạnh hỗ trợ rất tốt cho quá trình phát triển. Công nghệ này có thể làm việc với các thiết bị phần cứng phiên bản cũ, cũng nhƣ phần cứng hiện đại. Chúng còn giúp cho quá trình bảo trì, nâng cấp phiên bản đƣợc dễ dàng. Mặt khác trong đó có hỗ trợ công nghệ mới cho quá trình chuyển, nhận, quản lý thông điệp một cách dễ dàng là WCF (Windows Communication Foundation). Nhƣ vậy công nghệ này dùng với kiểu kiến trúc là đặt ra là rất phù hợp.
Các điểm nổi bật
Giao thức thích hợp để giao tiếp giữa các SS với nhau. Lựa chọn Giao thức truyền nhận thông điệp WCF.
Ứng dụng lớn nên phải có cơ chế quản lý, ghi lỗi cẩn thận để phục vụ tốt nhất cho quá trình điều tra lỗi khi cần.
Các ứng dụng phải độc lập, đƣợc thiết kế lỏng lẻo. Khi đó phân chia ứng dụng lớn thành các SS, mỗi SS phụ trách một số công việc đặc trƣng. Ví dụ SS Recept phụ trách quản lý thông tin liên quan tới bệnh nhân, SS QA phụ trách quản lý xử lý, hiển thị ảnh và cho phép các chỉnh sửa, điều chỉnh của bác sĩ một cách dễ dàng nhất. Các SS họat động dƣới dạng các dịch vụ, độc lập.
Đồng bộ hóa giữa các tiến trình (thread) xử lý. Hệ thống gồm rất nhiều các tiến trình chạy song song, các thể tƣơng tác với nhau. Có thể tiến trình A đang xử lý thì có tiến trình B xen ngang. Ví dụ Tiến trình đang xử lý, hiển thị ảnh hiện tại thì có tiến trình yêu cầu xử lý ảnh mới. Nhƣ vậy cần xây dựng cơ chế quản lý, đồng bộ dữ liệu giữa các tiến trình.
Lựa chọn giải pháp
i. Kiểu kiến trúc: Message-bus.
ii. Tất cả giao diện ngƣời dùng phải tạo bằng C#.
iii.Với mã nguồn đƣợc viết trên hai môi trƣờng phát triển khác nhau là C# và
C++ thì phải dùng kết nối Adaptor.
iv. Phƣơng châm xử lý lỗi nhƣ sau:
o Thực hiện phân cấp mức độ lỗi thành các mức khác nhau: Lỗi nguy
hiểm có thể gây hỏng chƣơng trình, lỗi thiếu tài nguyên…
o Tại nơi phát sinh ra lỗi, thực hiện: ghi lỗi ra file và event log của window, trả lại mã lỗi cho lớp cao hơn.
o Trên giao diện, nơi mà tƣơng tác trực tiếp với ngƣời dùng, phải thực hiện bẫy và bắt lỗi, để tránh trƣờng hợp chƣơng trình bị hỏng khi đang chạy.
v. Công nghệ: Microsoft .NET Framework 3.5 (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:
<<FW>> ASSEMBLE <<SS>> QA <<SS>> Recept <<SS>> Study Connector Component Interface Configuration In: XmlMsg Out: ErrorCode In: XmlMsg Out: ErrorCode E ve nt E ve nt E ve nt 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
Thành phần Là các SS Study, Recept, QA, ASSEMBLE
o Study là một SS làm nhiệm vụ kết nối với phần cứng
và thực hiện chụp ảnh.
o Recept là một SS làm nhiệm vụ quản lý thông tin liên
quan tới bệnh nhân.
o QA là một SS làm nhiệm vụ xử lý, hiển thị ảnh lên màn
hình. Hỗ trợ các chức năng nhƣ: Kết nối các ảnh thành phần thành một ảnh, điều chỉnh độ sáng tối… giúp bác sĩ tốt nhấ trong quá trình chuẩn đoán bệnh.
o ASSEMBLE là SS dƣới dạng dịch vụ nền (framework)
làm nhiệm vụ điều phối làm việc giữa các SS trong hệ thống.
Kết nối Kết nối là các sự kiện. Khi một SS cần yêu cầu một SS khác thực hiện một chức năng nào đó, sẽ tiến phát hành một sự kiện. gửi thông điệp yêu cầu đi.
Giao diện Đầu vào là một chuỗi có định dạng xml chứa thông tin xác định mã SS… Đầu ra sẽ cho biết kiểu lỗi trong quá trình xử lý.
Cấu hình Là các file cấu hình của từng SS, có đuôi mở rộng là *.config.