Property Operation MetaClass Class 0..n 1 0..n 1 0..n 1 0..n 1 0..n 1 0..n 1 Relationship 0..n 1 0..n 1 2 0..n 2 0..n Hình 10. Biểu đồ khái niệm miền lĩnh vực
III.2.3. Xây dựng các mô hình ca sử dụng
III.2.3.1. Mô hình ca sử dụng mức gộp
Hai thao tác chính R1 và R2 trong bảng phân tích yêu cầu tương ứng với hai ca sử dụng mức gộp Manage MetaClass và Refine MetaClass (hình 11).
Hình 11. Biểu đồ ca sử dụng mức gộp
III.2.3.2. Biểu đồ ca sử dụng chi tiết
Ở mức này ta phân rã hai ca sử dụng mức gộp thành 2 gói ca sử dụng: quản lý tệp đặc tả hệ thống(hình 12) và làm mịn một đặc tả hệ thống (hình 13).
Create MetaClass Open MetaClass Save MetaClass User (from ) Export To Standard Format Hình 12.Biểu đồ ca sử dụng quản lý các đặc tả hệ thống
Tại các ca sử dụng đặc tả làm mịn hệ thống, công cụ phải kiểm tra các ràng buộc (được nêu ra trong các luật làm mịn ở phần II.2.2) sau mỗi thao tác người dùng và đưa ra cảnh báo hoặc ngăn cấm các thao tác không hợp lệ. Tuy các thao tác xóa các thành phần đặc tả hệ thống (lớp, phương thức, thuộc tính) không phải là các thao tác làm mịn hệ thống nhưng ở đây công cụ cũng nên hỗ trợ vì nó giúp cho người dùng sửa được các lỗi trong quá trình thao tác.
Hình 13.Biểu đồ ca sử dụng phát triển và làm mịn đặc tả hệ thống
III.2.4. Phát triển các biểu đồ lớp khái niệm
Người dùng tương tác với hệ thống qua các lớp giao diện (Management Boundary, Operation Boundary) để tạo mới, mở, lưu và thực hiện các thao tác làm mịn biểu đồ. Các lớp điều khiển Management Control và Operation control trợ giúp người dùng thực hiện các thao tác trên giao diện người dùng và tiến hành các tác vụ biến đổi bên trong hệ thống đặc tả và lưu các thay đổi này vào lớp thực thể System Specification khi sử dụng các nhân tố từ UML Element và File Management Object (hình 12).
Hình 14.Biểu đồ lớp khái niệm tổng quát
III.3. Thiết kế hệ thống
III.3.1. Biểu đồ lớp thiết kế
Từ biểu đồ lớp khái niệm và các phân tích ta đi đến biểu đồ lớp thiết kế cho hệ thống.
Bằng thao tác tổng quát hóa, ta có lớp Element là lớp trừu tượng cha của hai lớp
Class và Relationship.
Sau đó ta thêm các thuộc tính và phương thức cho các lớp thiết kế. Để phục vụ cho việc thể hiện trực quan biểu đồ, lớp MetaClass có phương thức Draw() để vẽ toàn bộ biểu đồ bằng cách gọi phương thức Draw() của các thành phần trong biểu đồ. Mẫu thiết kế FactoryMethod [11] được dùng tổng quát hóa công việc vẽ các thành phần biểu đồ.
Nhằm lưu biểu đồ lớp thành các file, phương thức SaveToFile() được thêm vào lớp MetaClass. Ngược lại phương thức static LoadToFile() dùng để mở biểu đồ từ file XML đã lưu từ phiên làm việc trước.
Để đơn giản hóa việc quản lý menu lệnh, thanh công cụ của hệ thống và hỗ trợ chức năng Undo – Redo cho các thao tác chúng tôi sử dụng mẫu thiết kế Command
Các phương thức: MetaClass:AddClass, MetaClass:AddRelationship, Class:Rename, Class:ChangeVisibility, Class:AddProperty, Class:RemoveProperty, Class:AddOperation, Class:RemoveOperation, Property:ChangeVisibitlity, Operation: ChangeVisibility được thực hiện theo các thuật toán làm mịn mô hình lớp được nêu ở các phần trên (hình 15).
1..1 0..* 1..1 0..* 1..1 0..* * 2 0..1 0..* MetaClass - Elements : Element + + + + + + + AddClass () AddRelationship () RemoveClass () RemoveRelationship () LoadFromFile () SaveToFile () Draw () : void : void : int : int : MetaClass : String : void Element {abstract} - - ElementID Name : string : string + Draw () : void Class - - - - Properties Operations Visibility Bound : System.Array : System.Array : String : Rectangle + + + + + + + <<Override>> Rename () ChangeVisibility () AddProperty (Property pro) RemoveProperty ()
AddOperation (Operation op) RemoveOperation () Draw () : void : void : void : int : void : int : void Relationship - - - RelT ype ClassA ClassB : int : Class : Class + + <<Override>> ChangeType () Draw () : int : void Property - - - Visibility Name DataType : String : String : String
+ ChangeVisibility (string newVisibility) : void
Operation - - - - Name Visibility ReturnType Parameters : String : String : String : System.Array
+ ChangeVisibility (String newVisibility) : void
Parameter - - DataType Name : String : String Hình 15. Biểu đồ lớp thiết kế của hệ thống
III.3.2. Biểu diễn thông tin đặc tả hệ thống
III.3.2.1. Yêu cầu
Việc biểu diễn thông tin đặc tả hệ thống là một trong những vấn đề cơ bản của việc xây dựng công cụ. Cần có cơ chế cho việc biểu diễn, đọc và lưu các đặc tả hệ thống một cách thuận tiện, tức là làm sao để chuyển đặc tả hệ thống từ dạng các đối tượng trong bộ nhớ thành cấu trúc dữ liệu file ngoài để tiện cho việc lưu trữ, trao đổi. Ngoài ra, cũng cần quan tâm đến các chuẩn của các công cụ CASE hiện nay để có thể chuyển dữ liệu từ công cụ xây dựng sang các công cụ phổ biến hiện nay như Rational Rose, PowerDesinger…
III.3.2.2. XML và XMI
a) Ngôn ngữ XML
Ngôn ngữ XML vốn là một ngôn ngữ được thiết nhằm mô tả dữ liệu, hơn nữa lại có sự tương đồng về cách định nghĩa XML và UML (hình 16) cho nên ta hoàn toàn có khả năng biểu diễn thông tin đặc tả của hệ thống hướng đối tượng bằng XML [25].
Một văn bản XML tuân thủ đúng cấu trúc cú pháp mới chỉ là văn bản XML đúng định dạng (well-formed XML document), để một văn bản XML tuân thủ theo cấu trúc mong muốn và mang những thông tin ngữ nghĩa cần thiết để tiện trong việc trao đổi thông tin thì văn bản XML đó cần phải hợp lệ tức là phải có định dạng và ngữ nghĩa theo ý muốn. Theo W3C, để quy định cấu trúc, nội dung và ngữ nghĩa của một tài liệu XML có thể dùng DTD hoặc XML schema (lược đồ XML). XML schema bản thân nó cũng là một tài liệu XML nhưng mục đích nó là mô tả tài liệu XML khác do đó người ta gọi XML schema là một tài liệu siêu dữ liệu (dữ liệu mô tả dữ liệu). Một tài liệu XML đúng định dạng mà tuân thủ theo thông tin mô tả nó trong lược đồ XML thì gọi là tài liệu XML hợp lệ (validity XML document).
b) Chuẩn XMI
XMI (XML Metadata Interchange) là một chuẩn của OMG ùng để trao đổi thông tin siêu dữ liệu thông qua XML [25]. XMI được dùng cho các siêu dữ liệu mà siêu mô hình của nó có thể được biểu diễn bằng Meta-Object Facility (MOF). XMI thường được dùng để làm chuẩn trao đổi thông tin của các mô hình UML và để tuần tự hóa (serialize – biến đối tượng thành một dãy bit hoặc dãy ký tự) các đối tượng.
Tư tưởng thiết kế đặc tả các mô hình của OMG là chia dữ liệu thành các mức mô hình trừu tượng và thực. Mô hình trừu tượng biểu diễn thông tin ngữ nghĩa trong khi đó mô hình thực biểu diễn các biểu đồ trực quan. Các mô hình trừu tượng là các thể hiện của các ngôn ngữ mô hình tùy ý dựa trên MOF như UML hay SysML.
Một mục đích của XMI là cho phép chuyển đổi dễ dàng siêu dữ liệu giữa các công cụ mô hình hóa dựa trên UML, trên các kho dữ liệu chuẩn MOF trong các môi trường phân tán không đồng nhất.
Hiện nay các công cụ UML nổi tiếng trên thị trường đều hỗ trợ XMI do đó chúng có thể trao đổi dữ liệu với nhau qua các file XMI, có thể kể ra ở đây Rational Rose [17], PowerDesigner, Enterprise Architect…
III.3.2.3. Lựa chọn phương án
Từ yêu cầu về quản lý file đặc tả chứa toàn bộ thông tin về đặc tả hệ thống và các ký pháp đồ họa UML nên tôi đã chọn phương án lưu và đọc thông tin toàn bộ đặc tả hệ thống bằng một file duy nhất. Các thao tác lưu và đọc này được thực hiện bằng việc tuần tự hóa và khôi phục (tức là lưu một đối tượng thành file, file này có thể dùng để khôi phục lại thông tin đối tượng).
Để công cụ được xây dựng, tạm đặt tên FM Tool có thể trao đổi dữ liệu đặc tả với các công cụ CASE khác hiện có thì chuẩn XMI được lựa chọn. Theo đó, FM Tool có chức năng xuất thông tin đặc tả ra một file XML theo chuẩn XMI. File này có thể được công cụ đọc và khôi phục lại toàn bộ thông tin về đặc tả hệ thống, từ đó có thể dùng các công cụ này để thực hiện một số thao tác khác như: tiếp tục biến đổi, làm tài liệu, sinh mã khung chuơng trình tự động…
Hiện nay các công cụ CASE nổi tiếng trên thị trường hầu hết đều làm theo cách này: lưu thông tin đặc tả mô hình thành một file định dạng riêng, bên cạnh đó có chức năng nhập/xuất (import/export) đặc tả từ các công cụ khác bằng XMI. Do đó phương án được chúng tôi lựa chọn ở đây hoàn toàn tuân theo các chuẩn và xu hướng chung.
III.4. Cài đặt thử nghiệm
III.4.1. Môi trường và công cụ
Việc phát triên công cụ FM Tool được tiến hành theo tiến trình RUP. Công cụ CASE được sử dụng ở đây là Rational Rose. Sản phẩm của các pha và các giai đoạn phân tích thiết kế đã được trình bày ở phần trên.
Trong bước lập trình, với mục đích thử nghiệm và do nhu cầu về thời phát triển cần nhanh chúng chúng tôi đã chọn ngôn ngữ Visual C# chạy trên nền Microsoft .NET 2005 – một khung làm việc (framework) hỗ trợ khá tốt cho các hệ thống hướng đối tượng và các ứng dụng winform.
Ngoài ra, chúng tôi còn sử dụng thư viện DocToolkit để thực hiện các thao tác với thanh công cụ và thực đơn.
III.4.2. Công cụ FM Tool
Hình 17.Giao diện công cụ FM Tool
Tiến hành quy trình theo các phần được trình bày ở trên, chúng tôi đã xây dựng thành công công cụ FM Tool (hình 17) có các chức năng theo mô tả ở phần III.2.1.
Quản lý đặc tả hệ thống a)
Giao diện của FM Tool được thiết kế khá đơn giản và dễ sử dụng. Menu và thanh công cụ đều rất quen thuộc với người dùng vì thế các thao tác tạo, lưu và mở tệp hệ thống được thực hiện dễ dàng:
Tạo tệp hệ thống mới: chọn menu File
- Æ New hoặc ấn nút New ở thanh công
cụ.
Lưu tệp hệ thống: chọn menu File
- Æ Save hoặc ấn nút Save ở thanh công cụ.
Mở tệp hệ thống đã có: chọn menu File
- Æ Open hoặc ấn nút Open ở thanh
- Để xuất đặc tả hệ thống ra XMI có thể chọn từ menu FileÆ Export to XMI
hoặc ấn nút Export to XMI trên thanh công cụ.
b) Phát triển và làm mịn đặc tả hệ thống
Sử dụng FM Tool, người dùng có thể thực hiện các thao tác để có thể phát triển một hệ thống phần mềm hướng đối tượng:
- Để thêm các thành phần như lớp, quan hệ giữa các lớp vào đặc tả hệ thống, người dùng click vào thanh công cụ và vẽ các đối tượng tương ứng vào phần thể hiện ký pháp đồ họa.
- Để thay đổi vị trí, kích thước của các ký pháp đồ họa, cũng như trong các công cụ CASE khác, trong FM Tool người dùng chỉ cần thực hiện các thao tác kéo thả khá đơn giản.
- Các thành phần, thuộc tính của lớp có thể được sửa đồi bằng cách click phải chuột vào thành phần đó và chọn Properties từ menu popup (hình 18), chương trình sẽ hiển thị form sửa đổi (hình 19).
- Để xóa một thành phần: click phải chuột vào thành phần và chọn Delete hoặc ấn phím Delete.
Trong biểu diễn ký pháp đồ họa về tầm nhìn (visibility) của các thuộc tính và phương thức của lớp, chúng tôi thống nhất như sau: private được thể hiện bằng dấu trừ (-), protected được thể hiện bằng dấu thắng (#) còn public được thể hiện bằng dấu cộng (+) ngay phía trước thuộc tính và phương thức đó (hình 17).
Hình 18. Sửa đồi đối tượng bằng cách nhấn phải chuột và chọn Properties
III.5. Tiến hành một case study với FM Tool
Một trường đại học tổ chức các seminar về các vấn đề chuyên môn cho sinh viên. Có nhiều nhóm sinh viên tham gia seminar, mỗi nhóm có một chủ đề lớn (ví dụ công nghệ phần mềm, mạng máy tính…) và có một giảng viên phụ trách. Các nhóm Seminar diễn ra trong một khoảng thời gian nhất định và có lịch cố định vào các tuần. Yêu cầu của nhà trường là có một ứng dụng để quản lý công tác thực hiện seminar này: tạo các nhóm seminar, chỉ định giáo viên phụ trách, công bố thông tin về seminar cho sinh viên và cho sinh viên đăng ký tham dự.
Trong phần này, chúng tôi thực hiện quá trình xây dựng hệ thống trên theo quy trình đã trình bày ở phần II.2.1 bằng các luật và thuật toán làm mịn, các thao tác được thực hiện trên FM Tool. Các thao tác nếu vi phạm các luật làm mịn sẽ bị công cụ đưa ra thông báo và không cho phép thực hiện. Do mục đích của case study này là để thử nghiệm các lý thuyết và công cụ ở trên nên chúng tôi chỉ thực hiện công việc xây dựng các chức năng cơ bản và đơn giản nhất có thể.
III.5.1. Khởi tạo hệ thống
Dựa trên tiến trình RUP, khi thực hiện việc phân tích bài toán, từ mô hình nghiệp vụ, đặc biệt là mô hình khái niệm miền lĩnh vực của bài toán trên ta có hệ thống khởi tạo ban đầu APP0gồm các lớp Seminar, Student và Teacher (hình 20).
APP0 = {Seminar[], Student[], Teacher[], RELATIONSHIP}
RELATIONSHIP = { relation(association, join, Student, Seminar, 1..*, 0..*), relation(association, supervise, Teacher, Seminar, 1..1, 0..*)}
Hình 20.Khởi tạo hệ thống cho đặc tả APP0
III.5.2. Bổ sung các thuộc tính
Các lớp trong APP0 chưa có thuộc tính nào, qua phân tích nghiệp vụ ta thấy cần
bổ sung các thuộc tính sau:
- Lớp Seminar:
o Private DateTime startTime //thời gian bắt thực hiện đầu nhóm seminar này
o Private DateTime endTime //thời gian kết thúc nhóm seminar này
o Private String timeInWeek //mô tả thời gian định kỳ hàng tuần
o Private String topic //tên chủ đề của seminar
- Lớp Teacher:
o Private String TeacherID
o Private String name
o Private String rank //chức danh khoa học
o Private String department //bộ môn hoặc phòng ban trực thuộc
- Lớp Student:
o Private String StudentID
o Private String name
⊑
APP1 APP0
Theo thuật toán ở phần II.2.2.2.c thì (hình 21).
Hình 21.Mô hình UML tương ứng với APP1
III.5.3. Bổ sung các phương thức
Từ đặc tả APP1 ta thêm các phương thức vào các lớp để thu được APP2 (hình
22). Ta có APP2⊑ APP1
- Lớp Seminar:
o Public SetTeacher(Teacher t)
- Lớp Teacher:
o Public PrintInfo() //In thông tin giáo viên ra màn hình
- Lớp Student:
o Public PrintInfo() //In thông tin sinh viên ra màn hình
Hình 22.Mô hình UML tương ứng với APP2
III.5.4. Tổng quát hóa
Qua nhận xét thấy hai lớp Teacher và Student có cùng thuộc tính name và phương thức PrinInfo(), hơn nữa trong thực tế vẫn có thể tổng quát hóa hai thực thể này tương ứng này bằng danh từ “Person” nên ta thêm lớp Person vào hệ thống và tạo các quan hệ tổng quát hóa từ lớp Teacher và Student đến lớp Person. Thêm vào đó ta chuyển thuộc tính name của hai lớp này lên lớp cha Person.
Làm mịn hệ thống theo định hướng mẫu thiết kế là một tư tưởng tốt và làm cho hệ thống được cấu trúc tốt hơn. Áp dụng mẫu Stategy [20] vào đây, ta có thể thực hiện thao tác chuyển phương thức PrintInfo() của các lớp Teacher và Student lên lớp cha. Thực tế là trong mẫu Stategy, tính đa hình của hướng đối tượng được thể hiện rất rõ và các thuật toán MoveMethod, Polymorphism được áp dụng vào đây. Sau bước này ta thu được đặc tả hệ thống APP3 (hình 23) được làm mịn từ APP2: APP3 ⊑APP2
Hình 23.Mô hình UML tương ứng với APP3
III.5.5. Chuyển đặc tả sang công cụ CASE khác
Dùng chức năng xuất ra XMI của FM Tool, đặc tả APP3 được chuyển sang công cụ PowerDesigner rất chính xác
0..* 1..* 0..* 1..1 Person # name : string + PrintInfo() () : string Student - - studentID class : string : string + + PrintInfo () RegisterSeminar () : string : void Teacher