Sau khi đã có thiết kế kiến trúc tổng thể cho hệ thống, chúng tôi đi vào thiết kế kiến trúc cho các chức năng lớn của các SS. Giai đoạn thiết kế kiến trúc cho các chức năng lớn này cũng tuân thủ theo năm bƣớc nhƣ thiết kế kiến trúc tổng quan nhƣng trong từng bƣớc sẽ có sự phân tích khác biệt so với thiết kế kiến trúc tổng quan. Sau đây sẽ trình bày thiết kế kiến trúc cho một chức năng lớn cụ thể trong SS QA là chức năng kết nối các ảnh thành phần.
Xác định mục tiêu kiến trúc
Chức năng này đảm nhiệm công việc cụ thể là xử lý và hiển thị ảnh, cho phép ngƣời dùng thực hiện kết nối các ảnh thành phần thành một ảnh duy nhất theo một trong hai cách là thủ công hoặc tự động. Mục tiêu của thiết kế kiến trúc là cần đảm bảo đầy đủ, hỗ trợ tốt nhất cho quá trình làm thiết kế chi tiết. Giai đoạn này phải đƣa ra đƣợc các thành phần cụ thể là các tên các dự án, các gói sẽ phát triển trên C#, C++, cách thức chúng làm tƣơng tác, gửi nhận thông điệp cho nhau.
Đối tƣợng sử dụng chủ yếu Thiết kế kiến trúc này là ngƣời thực hiện thiết kế chi tiết và viết mã nguồn nên có thể sử dụng ngôn ngữ liên quan tới lập trình nhƣ dự án, thƣ viện, phƣơng thức… hoặc liên quan tới các biểu đồ trong UML nhƣ biểu đồ hoạt động, biểu đồ cộng tác…
Kịch bản chính
Đây là một chức năng cho phép ngƣời dùng thực hiện kết nối các ảnh thành phầ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 quá trình xử lý và hiển thị các ảnh thành phần lên màn hình diễn ra trong thời gian nhanh hay chậm, ảnh thành phần có đƣợc hiển thị đúng vị trí, chất lƣợng ảnh có tốt không. Việc này sẽ phụ thuộc vào quá trình thiết kế các thành phần sao cho hợp lý đảm bảo quá trình xử lý và hiển thị nhanh, chính xác.
Quá trình kết nối sẽ diễn ra thế nào, các ảnh thành phần sẽ đƣợc kết nối với nhau theo cách thức nào, các thành phần nào sẽ tham gia trong quá trình đó. Vấn đề này đƣợc làm rõ trong thiết kế kiến trúc này.
Đây là chức năng có sự thao tác tƣơng tác trực tiếp của ngƣời dùng nên các tình huống ngƣời dùng rất quan trọng, trong thiết kế kiến trúc cần phải liệt kê tất cả các tình huống này và có các phƣơng pháp xử lý phù hợp, tƣơng thích với các tình huống đó. Một số tình huống ngƣời dùng điển hình là: ngƣời dùng mở chức năng nhƣ thế nào, sau khi mở màn hình lên ngƣời dùng sẽ thực hiện thao tác trên các ảnh thành phần đó ra sao, và họ kết nối các ảnh đó nhƣ thế nào. Tƣơng ứng với các tình huống ngƣời dùng đó sẽ có các tình huống nghiệp vụ, tình huống nghiệp vụ tƣơng ứng. Trên thực tế khi làm, chúng tôi sẽ vẽ biểu đồ hoạt động cho từng tình huống ngƣời dùng một, và sẽ vẽ các tình huống hệ thống, nghiệp vụ đi cùng nếu có. Sau đây sẽ trình bày một tình huống ngƣời dùng cụ thể để mình họa, đó là khi màn hình kết nối ảnh đã đƣợc mở, ảnh thành phần đã đƣợc hiển thị, tình huống ngƣời dùng sẽ đƣợc mô tả qua biểu đồ hoạt động nhƣ hình 4.3 dƣới đây.
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.
Tổng quan về ứng dụng
Ứng dụng này đƣợc phát triển trên hai nền tảng môi trƣờng khác nhau: Giao diện ngƣời dùng đƣợc phát triển bằng Visual C# để tận dụng thế mạnh về đồ họa, môi trƣờng phát triển thuận tiện. Khi xử lý ảnh thì xử lý bằng C++, tận dụng lợi
act UserActionsOnCombineScreen Nguoi dung He thong Nguoi dung Nghiep vu Nguoi dung Nghiep vu Bắt đầu 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ướctheo 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
Kết thúc
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 Đánh dấu chế độ 2 điểm kết hợp Đánh dấu chế độ di chuyển một ảnh thành phần Đánh dấu chế độ di chuyển tất cả ảnh thành phần
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 [False] [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.
Các lớp trong thành phần của C++ chỉ cho bên ngoài thấy một số phƣơng thức chính để có thể gọi tới. Chỉ làm việc theo một chiều từ C# gọi tới C++, không có chiều ngƣợc lại.
Các điểm nổi bật
Cơ chế làm việc, quản lý tài nguyên giữa C# và C++ là khác nhau. Nên chúng tôi phải chú ý tới việc quản lý, cấp phát, thu hồi bộ nhớ dƣới C++ hay cơ chế hiển thị giao diện trên C# để đảm bảo có ứng dụng sẽ có giao diện phù hợp với nhiều loại màn hình có kích thƣớc khác nhau.
Chƣơng trình xử lý phức tạp, khi đƣa vào môi trƣờng phát triển khi có lỗi xảy phải khoanh vùng nhanh vùng bị lỗi. Để làm điều đó thì quá trình ghi lỗi phải đƣợc làm cẩn thận. Quá trình ghi lại lỗi này phải làm theo phƣơng châm đã đƣợc đƣa ra trong phần Thiết kế kiến trúc tổng quát.
Lựa chọn giải pháp (adsbygoogle = window.adsbygoogle || []).push({});
i. Chức năng đƣợc thiết kế thành nhóm thành phần chính: Các thành phần liên quan tới giao diện ngƣời dùng thì dùng C#. Các thành phần xử lý và hiển thị ảnh thì dùng C++. Các thành phần của C# gọi tới các thành phần của C++.
ii. Dựa vào các tình huống ngƣời dùng, tình huống nghiệp vụ, tình huống hệ thống trong phần kịch bản chính, ta sẽ thiết kế đƣợc các thành phần, giao diện tƣơng ứng. Hình dƣới đây mình họa các thành phần đƣợc xác định khi dựa vào tình huống ngƣời dùng, tình huống nghiệp vụ, tình huống hệ thống khi mở chức năng.
Kết quả của thiết kế kiến trúc khi dựa vào tình huống ngƣời dùng, tình huống nghiệp vụ, tình huống hệ thống trong trƣờng hợp mở màn hình đƣợc mô tả trong hình 4.4.
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ụ, hệ thống khi mở màn hình kết nối.
Đặc điểm của các thành phần trên hình 4.4 đƣợ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)
Thành phần Là các dự án, gói của C# và C++. Nhƣ hình vẽ trên ta có các thành phần gồm:
o MainScreen: Một dự án viết bằng C#, là màn hình
chính của chƣơng trình
o CombineSreen: Một dự án viết bằng C#, là màn hình
kết nối ảnh các ảnh thành phần thành một ảnh
o StitchImageView: Một dự án (component) viết bằng
thị ảnh.
o ImgPrm: Một dự án viết bằng C++, viết dƣới dạng
thƣ viện dùng chung cho nhiều dự án C++ khác. Dự án này thực hiện đọc thông tin liên quan tới ảnh nhƣ: đƣờng dẫn tới ảnh, loại ảnh
o ImageProcessor: Một dự án viết bằng C++, viết dƣới
dạng thƣ viện dùng chung cho nhiều dự án C++ khác. Dự án này thực hiện đọc thông tin về ảnh và xử lý ả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
CHƢƠNG5:CÀIĐẶTKIẾNTRÚCPHẦNMỀM 5.1Cách thức cài đặt kiến trúc phần mềm
Với hệ thống nhỏ, không quá phức tạp, khi có SAD, ta có thể bỏ qua giai đoạn làm SDD mà thực hiện luôn việc viết mã nguồn. Ví dụ nhƣ các website, lập trình viên đã rất quen với các công việc này, khi đó họ chỉ cần biết tới kiến trúc, mô hình ví dụ theo mô hình MVC (Model View Control) chẳng hạn, cách tổ chức mã nguồn là có thể thực hiện cài đặt môt cách dễ dàng. Mặt khác nếu hệ thống nhỏ thiên về các xử lý logic, thuật toán phức tạp thì có thể không cần tới SAD, có thể tiến hành xây dựng SDD và thực hiện cài đặt theo SDD đó.
Với các hệ thống xử lý lớn, phức tạp, SAD khi đó chỉ cho ngƣời ta cái nhìn ở mức độ tổng quát liên kết, cách thức làm việc giữa các thành phần với nhau, chứ chƣa biết đƣợc thực tế các thành phần đó chi tiết làm việc với nhau nhƣ thế nào, logic làm việc cụ thể ra sao, phải lựa chọn cách làm, công nghệ nào cho phù hợp, hạn chế rủi ro. Khi đó SAD sẽ là đầu vào tốt nhất cho giai đoạn làm SDD.
5.2 Phƣơng pháp đi từ thiết kế kiến trúc tới thiết kế chi tiết
Với SAD tổng quan, hệ thống lớn đƣợc thiết kế thành các hệ thống nhỏ. Khi đó thành phần là các SS. Từ SAD tổng quan rất khó có thể đi tới thiết kế SDD, mà phải tiếp tục cần thiết kế SAD cho các SS đó. Câu hỏi đặt ra là vậy khi nào sẽ dừng lại? Từ thực tế cho thấy khi các thành phần sẽ tƣơng ứng với các dự án hoặc gói thì có thể dừng lại để thiết kế SDD. Trong SAD có các thành phần chính là: thành phần, kết nối, giao diện, cấu hình. Còn trong SDD thì quan tâm tới các thành phần chính là: lớp (class), phƣơng thức (method), giao diện, biểu đồ lớp (class diagram), biểu đồ trình tự (sequence diagram), biểu đồ họat động (activity diagram). Khi có tài liệu SAD thì quá trình làm SDD sẽ trở lên dễ dàng hơn rất nhiều. Sẽ có một quá trình ánh xạ từ các thành phần trong SAD vào các thành phần trong SDD.
Bảng 5.1: Ánh xạ các thành phần trong SAD với SDD
STT SAD SDD Ánh xạ
1 Component Project, (adsbygoogle = window.adsbygoogle || []).push({});
Package, Class
Từ một thành phần thƣờng ánh xạ sang một hoặc nhiều dự án hoặc gói. Mỗi dự án đảm nhiệm những chức năng chuyên biệt chung nào đó.Trong mỗi dự án đó sẽ chứa một hoặc nhiều lớp. Ví dụ dự án đảm nhiệm công việc thao tác với các file dữ
liệu khác nhau nhƣ: *.txt file, *.xml file… Khi đó dự án này sẽ đƣợc thiết kế sao cho việc đọc, ghi dữ liệu vào các loại file một cách dễ dàng, tiện lợi nhất.
Khi biết đƣợc chức năng chung của dự án đó, ta sẽ thiết kế các lớp trong đó sao cho hợp lý, hiệu quả. Ta có thể dựa vào một số nguyên lý thiết kế trong hƣớng đối tƣợng để thiết kế các lớp này nhƣ sau [1]:
o Nguyên lý đóng mở (The Open
Close Principle): Một module cần “mở” đối với việc phát triển thêm tính năng nhƣng phải “đóng” (hạn chế hoặc không cho phép) đối với việc sửa đổi mã nguồn. Ý nghĩa của nguyên lý này là: Chúng ta có thể thêm hoặc mở rộng tính năng của một lớp mà không cần quan tâm đến những thay đổi bên trong bản thân lớp. Tất cả các kỹ thuật này đều chủ yếu dựa vào sự trừu tƣợng hóa (abstraction) trong lập trình hƣớng đối tƣợng. Khi áp dụng nguyên lý này sẽ giảm thiểu đƣợc việc phải thay đổi các đoạn mã nguồn có sẵn khi thêm các tính năng mới vào phần mềm. Nhờ đó hệ thống không bị phá vỡ.
o Nguyên lý thay thế Liskov (The
Liskov Substitution Principle): Các lớp cơ sở đều có thể thay thế đƣợc bằng các lớp con (lớp kế thừa). Ý nghĩa của nguyên lý trên là các chức năng của hệ thống vẫn thực hiện đúng đắn nếu ta thay bất kì một lớp đối tƣợng nào bằng đối tƣợng kế thừa.
o Nguyên lý nghịch đảo phụ (The
thuộc vào mức trừu tƣợng. Không phụ thuộc vào mức chi tiết. Nguyên lý này phát biểu rằng, các module không nên phụ thuộc vào cài đặt mà chỉ nên phụ thuộc vào sự trừu tƣợng của các lớp đối tƣợng. Hay nói cách khác, chúng ta không nên để các lớp chi tiết phụ thuộc nhau mà để sự phụ thuộc đó xảy ra tại lớp trừu tƣợng.
o Nguyên lý ISP (The Interface
Segregation Principle): Nên có nhiều giao diện đặc thù với bên ngoài hơn là chỉ có một giao diện dùng chung cho một mục đích. Nguyên lý này phát biểu rằng, thay vì chúng ta dồn hết các chức năng vào trong lớp đối tƣợng đó thì chúng ta sẽ phân loại các chức năng ứng với nhu cầu của từng client.
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. Khi các dự án đƣợc chia nhỏ thành các lớp thì kết nối sẽ thể hiện giao tiếp làm việc giữa các lớp này. Mỗi loại kết nối khác nhau sẽ thể hiện lời gọi hàm, cách trao đổi thông điệp giữa các đối tƣợng là khác nhau. Việc này sẽ thể hiện vào sơ đồ lớp và sơ đồ tuần tự trong SDD.
3 Interface Interface,
method
Giao diện trong SAD thể hiện mức tổng quát việc gửi nhận thông điệp, tƣơng tác giữa các thành phần ra sao. Mỗi kiểu kiến trúc sẽ giao diện khác nhau. Còn trong SDD thì phải mô tả rõ chi tiết ý nghĩa của từng tham số, đầu vào, đầu ra của các giao diện, phƣơng thức này. Từ một giao diện trong SAD có thể sẽ phải chia nhỏ ra thành nhiều giao diện, phƣơng thức trong SDD để phù hợp với thiết kế. Ví dụ với kiểu
kiến trúc là Message-bus thì giao diện chỉ nói chung chung đầu vào là thông điệp dƣới định dạng là xml, còn đầu ra là mã lỗi. Nhƣng vào SDD thì phải xác định rõ ràng cấu trúc của xml gồm những phần tử nào, ý nghĩa của từng phần tử đó ra sao. Mã lỗi trả về phải có xác định rõ ràng ý nghĩa của lỗi ứng với giá trị của mã lỗi. Khi đó có thể ta phải xây dựng một phƣơng thức để đọc, phân tích xml, lấy ra giá trị cần thiết. Khi đó phƣơng thức này cũng phải xác định rõ ràng đầu vào là gì, đầu ra là gì. 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, phục thuộc giữa các thành phần. Trong SDD phải làm chi tiết sự phụ thuộc này. Điều này sẽ thể hiện số lƣợng các dự án, lớp trong sơ đồ lớp và logic xử lý trong biểu đồ tuần tự. Ví dụ dữ liệu của hệ thống đƣợc lƣu trữ ở các loại CSDL khác nhau nhƣ SQL Server, Access, hoặc ở dƣới dạng các file xml. Tùy thuộc vào cấu hình của ngƣời dùng mà hệ thống sẽ phải lấy dữ liệu từ một trong các nơi đó. Khi đó sẽ xuất hiện thêm các lớp, phƣơng thức để xử lý chuyên biệt với từng loại dữ liệu đó. Đồng thời khi xử lý phải mô tả rõ khi nào thì dùng loại dữ liệu nào (có thể quy định dựa vào giá trị nào đó), và sẽ phải gọi tới phƣơng thức nào đó cho phù hợp.
5.3 So sánh SAD và SDD
Bảng 5.2: So sánh SAD với SDD
Tiêu chí SAD SDD
Thành phần chính
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