Biểu đồ lớp khái niệm tổng quát

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Phương pháp hình thức trong việc phát triển hệ thống hướng đối tượng (Trang 52)

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

ClassRelationship.

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, StudentTeacher (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ó APP2APP1

- 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: APP3APP2

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 - - - teacherID rank department : string : string : string + PrintInfo () : string Seminar - - - - startTime endTime timeInWeek topic : int : int : string : string + SetTeacher () : void

Hình 24.Đặc tảđược chuyển sang công cụ Power Designer

Nội dung file XML theo chuẩn XMI được xuất ra từ FM Tool trong Case Study này được trình bày trong phần phụ lục.

III.6. Hai hướng sử dụng FM Tool

Sau khi có được đặc tả hệ thống cuối cùng, nhà phát triển có thể tiến hành công việc sinh mã nguồn khung chương trình bằng 1 trong 2 cách (hình 25):

- Chuyển đặc tả từ FM Tool sang công cụ CASE khác thông qua XMI.

Phát triển và làm mịn đặc tả với FM Tool

Sinh mã nguồn bằng FM Tool (sẽ phát triển sau) Xuất đặc tả từ FM Tool ra XMI Nhập đặc tả bằng XMI vào công cụ CASE khác Thực hiện một số thao tác với công cụ CASE khác

Sinh mã nguồn bằng công cụ CASE khác

Hình 25.Biểu đồ hoạt động hai phương án sinh mã nguồn sau khi có đặc tả hệ thống trong FM Tool

III.7. Kết luận chương

Việc phát triển công cụ này là một trong những nỗ lực nhằm hiện thực hóa việc phát triển phần mềm hướng đối tượng theo phương pháp hình thức. Chúng tôi đã tiến hành xây dựng và cho ra đời FM Tool – một công cụ bước đầu có thể sử dụng được trong thực tế với một số chức năng khá cơ bản. Sử dụng công cụ ta sẽ thu được một đặc tả thiết kế cuối cùng của hệ thống là một đặc tả lớp thiết kế trong XML. Do cách đặc tả hệ thống rất gần gũi với mô hình lớp thiết kế của UML, nên có thể sử dụng các công cụ có sẵn như Rational Rose để chuyển thiết kế đó sang các ngôn ngữ lập trình hướng đối tượng một cách dễ dàng. Việc chuyển đổi đặc tả sang công cụ khác cũng

Một phần của tài liệu (LUẬN VĂN THẠC SĨ) Phương pháp hình thức trong việc phát triển hệ thống hướng đối tượng (Trang 52)

Tải bản đầy đủ (PDF)

(81 trang)