I. Giới thiệu mô hình hoàn chỉnh cho quy trình xây dựng phần mềm dựa trên
2. Thiết kế kiến trúc phần mềm GTS trong UML – RT
2.1 Kiến trúc GTS trong UML-RT
Để mô tả kiến trúc phần mềm của ứng dụng GTS sử dụng UML-RT, chúng ta sử dụng gói Rational Rose thời gian thực bao gồm UML-RT ký pháp chuẩn được đề nghị bởi Bran Selic1. Bằng UML chuẩn công nghiệp, các thiết kế thời gian thực, sinh mã, và khả năng thực thi mô hình (industry-standard Uni_ed Modeling Language (UML), real-time design constructs, code generation, and model execution capabilities) Rational Rose thời gian thực đề cập tới việc hoàn thành vòng đời của một dự án sớm từ việc phân tích cho đến thiết kế, cài đặt và kiểm thử. Tuy nhiên, chúng ta chỉ sử dụng công cụ này để mô tả cỏc yêu cầu kiến trúc bằng phương pháp đồ họa ( graphical way).
Chú ý chúng ta tập trung vào GTS component mà không quan tâm đến các components còn lại. Hình 2.17 biểu diễn mô hình UML-RT cho kiến trúc phần mềm GTS đã được giới thiệu ở trên. Trong mô hình UML-RT có một khái niệm về “capsules” yêu cầu chúng ta cũng cần biết. Như chúng ta thấy ở đây, một capsule được sử dụng để mô tả toàn bộ kiến trúc phần mềm. Một UML-RT capsule có thể được tạo ra bằng cách sử dụng 1 hay nhiều capsules.
Chú ý là trong hỡnh vớ dụ về UML-RT sử dụng các quy tắc của GTS thì capsule về kiến trúc phần mềm GTS biểu diễn các capsules thành phần phần mềm GTS. Cổng Prov:ProtTrans~ (hộp mầu trắng nhỏ trong thành phần phần mềm GTS) biểu diễn đương biên để các thành phần gửi và nhận có thể liên lạc với phần bên trong của GTS capsule. Cổng này kết nối trực tiếp với cổng kép +/translator:ProtTrans~ (là một phần của thành phầnTranslator.
Hình 2.17. Kiến trúc phần mềm GTS trong UML-RT
Theo Figure 2.17 , kiến trúc phần mềm GTS bao gồm 6 components (i.e.,capsules). Component chính là /trans:Translator, cỏi yờu cầu với 4 components nữa:
(a) Một bộ nén file đặt tên là /fC:FileCompressor;
(b) Một bộ chuyển ảnh không gian là /iT:ImageTranslator;
(c) Một component để biểu diễn trung gian của dữ liệu là /xDR:XDR; (d) Và một buffer đặt tên là /xmlBuf:XMLBuffer.
Ngoài ra, hệ thống con GTS yêu cầu hai giao diện(dịch vụ) của DOM là
Document và Element, chúng được sử dụng bởi các components XDR và
XMLBuffer để sử dụng được khuôn dạng XML. Các dịch vụ này đều có sẵn trong gói phần mềm của IBM XML4J hoặc Sun JAXP. Như vậy kiến trúc GTS là một ví dụ cho việc sử dụng component DOM, trong đó cả 2 dịch vụ Document và Element đều xử lý các components /xDR:XDR và /xmlBuf:XMLBuffer
2.2 Mapping UML-RT GTS tới chuẩn UML.
Các phần tử UML-RT của kiến trúc phần mềm GTS có thể được nhìn nhận như là các phần tử UML truyền thống. Hình 2.18 chỉ ra lược đồ lớp UML trong đó chứa tất cả các phần tử được cung cấp bới kiến trúc phần mềm UML-RT. Chú ý là các phần tử kiến trúc UML-RT như là capsules, cổng hay giao thức được thể hiện như là các phần UML mở rộng (UML extensions) sử dụng mẫu <<capsule>>, <<port>> and <<protocol>>. Lược đồ bao gồm 12 lớp (6 capsules và 6 cổng).
Các lớp được thể hiện bằng các ký hiệu trong góc trên cùng bên phải. Một lớp capsule chứa một vùng mới (ngoài cỏc vựng, cỏc thuộc tính, và các hoạt động cơ bản), chỉ ra các giao diện được yêu cầu và giao diện được cung, và được thể hiện bằng các hộp nhỏ đen, Trong một cách tương tự, một lớp giao thức đưa ra một thông điệp (ví dụ các hoạt động) được hỗ trợ bởi cổng tương ứng. Ví dụ, lớp giao thức ProtComp có 2 thông điệp zip() và unzip() được sử dụng bởi lớp và Translator capsule lớp FileCompressor capsule. Ngoài ra, các cổng sử dụng cỏc liờn kết kết cấu (composition relations), cái kết nối các lớp giao thức và capsule.
2.3 Chuyển các thông tin vào các capsules
Trong vấn đề này, chúng ta đã định nghĩa kiến trúc phần mềm của GTS sử dụng UML-RT. Tuy nhiờn, cú vài thông tin quan trọng phải được tìm hiểu bên trong một a capsule. Thông tin này liên quan tới tài liệu đặc tả cho một COTS cho việc đặc tả các thành phần của COTS. Vì vậym để mô ta một thành phần trong kiến trúc phần mềm, chúng ta cần cân nhắc các loại thông tin sau cho một tài liệu đặc của COTS:
(a) Functional information (ví dụ: giao diện, hành vi, giao thức); (b) Non-functional information, (được mô tả như là thuộc tính); (c) Deployment và implementation information;
(d) Marketing information.
Để mô tả loại thông tin này, chúng ta sử dụng UML notes và tagged values bên trong một capsule. Ví dụ, hình 10 chỉ ra cỏc yờu cầu trong của một vài thành phần của kiến trúc phần mềm GTS. Để đơn giản, chỉ mức kí hiệu (signature level) của giao diện và non-functional information được mô tả trong capsules, nhưng vẫn tồn tài thông tin của một tài liệu đặc tả COTS có thể được biểu diễn bằng cách tương tự. Mức kí hiệu của giao diện có thể được biểu diễn bằng vài IDL đặc biệt. Đặc biệt trong ví dụ này, chúng ta sử dụng một ký pháp CORBA IDL để mô tả giao diện. Mô tả này được gói gọn bên trong một thẻ UML và được kết nối tới cổng tương ứng. Bên cạnh đó, một external tagged value được kết nối với IDL note xác định lại ký pháp để mô tả giao diện mức kí hiệu. Ví dụ, capsules sử dụng một kớ phỏp tagged value fnotation="CORBA IDL" được kết nối với các thẻ IDL.
Hình 2.19. Mô tả UML-RT của tất cả các components trong kiến trúc phần mềm GTS
Các thuộc tính cũng được mô tả trong một thẻ riêng biệt. Một mô tả thuộc tính bắt đầu với tên của mẫu <<property>>. Tiếp theo, mô tả thuộc tính sẽ sử dụng một ký pháp đặc biệt. Tương tự với giao diện của thẻ (interface notes) mô tả kớ pháp được thể hiện sử dụng một external tagged value. Ví dụ, thẻ how ImageTranslator capsule describes three properties in separate
notes, và sử dụng một external tagged value fnotation=OCL được kết nối với mỗi thuộc tính của thẻ.
Chú ý với mục đích từ kiến trúc phần mềm có thể sinh ra các đặc tả XML cho các compoenntss, chúng ta có thể sử dụng một tiến trỡnh cú khả năng phân tích cú pháp files (RTMDL) được xây dựng bởi Rational Rose RealTime. Đồng thời, cần có một “ generic tool” xử lý file XML và xuất ra các mẫu “COTScomponent”. Điều này được đề cập ở phần công nghệ liên quan.