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 - - - 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 được thực hiện tự động qua hai bước: xuất đặc tả theo chuẩn XMI ra file XML và sau đó nhập đặc tả vào các công cụ khác từ file xuất ra của FM Tool.
Tuy nhiên công cụ chúng tôi mới chỉ hỗ trợ các phép biến đổi cơ bản, còn nhiều phép biến đổi phức tạp và tinh tế khác chúng tôi chưa đề cập đến như: hiện thực hóa một giao diện, các phép biến đổi trên các phương thức,… Trong tương lai chúng tôi sẽ tiếp tục nghiên cứu xây dựng các thuật toán khác và xây dựng bổ sung chúng vào công cụ. Chúng tôi cũng sẽ tích hợp chức năng sinh mã lập trình mô hình thiết kế cuối cùng để giúp người sử dụng tự động hóa việc sinh khung mã chương trình trong các ngôn ngữ lập trình hướng đối tượng hiện đại như Java, C#...
KẾT LUẬN
Tiếp cận hướng đối tượng là một phương pháp phát triển phần mềm đã và đang mạng lại nhiều ưu điểm lớn và ngày càng trở nên phổ biến. Tiến trình phát triển phần mềm hướng đối tượng phổ biến nhất hiện nay là RUP, trong tiến trình này, UML được sử dụng để đặc tả, làm trực quan và làm tài liệu cho các sản phẩm (hay còn gọi là chế tác) tại các bước khác nhau của tiến trình. Tuy nhiên RUP gặp phải một số khó khăn trong đó có việc phải đảm báo tính nhất quán ngang và dọc của mô hình phát triển. Một tiến trình mới trong dựa trên RUP trong đó tập trung vào khung nhìn lớp sẽ giải quyết những khó khăn đó. Trong tiến trình này sau khi khởi tạo đặc tả hệ thống với các lớp khái niệm, chúng ta thực hiện làm mịn mô hình qua các phép biến đổi đúng đắn để thu được hệ thống cuối cùng.
Để mô hình hóa đặc tả hệ thống và các phép biến đổi làm cơ sở cho các chứng minh toán học chặt chẽ chính xác cần áp dụng các phương pháp hình thức vào việc chứng minh lý thuyết hệ thống. Trong luận văn này, rCOS một phương pháp hình thức dựa trên đại số quan hệ và UTP đã được sử dụng để đặc tả và kiểm chứng các phép biến đổi hệ thống.
Những kết quả của luận văn bao gồm:
- Nghiên cứu phương pháp phát triển phần mềm hướng đối tượng và phương pháp hình thức trong phát triển phần mềm cũng như mối quan hệ giữa chúng.
- Nghiên cứu mô hình quan hệ của hệ thống hướng đối tượng rCOS để đưa ra luật và thuật toán thêm các mối quan hệ vào đặc tả hệ thống hướng đối tượng.
- Phát triển một công cụ trợ giúp cho quá trình phát triển phần mềm hướng đối tượng trong đó tập trung vào khung nhìn biểu đồ lớp. Các cơ sở lý thuyết và các thao tác kiểm chứng trong công cụ là kết quả của những nghiên cứu của các tác giả trước và thuật toán thêm mối quan hệ trong luận văn này. Hiện tại công cụ đã thực hiện được các thao tác cơ bản sau: thao tác với lớp (thêm mới và xóa lớp, sửa đổi tên lớp), thêm, xóa, sửa các thuộc tính và phương thức của lớp, thao tác với các quan hệ giữa các lớp (kế thừa, phụ thuộc, liên kết, kết tập, cấu thành). Mỗi thao tác đó đều được công cụ kiểm tra tính đúng đắn của các ràng buộc được trình bày trong phần lý thuyết các phép biến đổi (phần II.2.2). Ngoài ra công cụ còn có chức năng xuất đặc tả hệ thống ra file XML theo chuẩn XMI để có thể trao đổi tương tác với các công cụ CASE khác. Chức năng này tạo cơ sở để sử dụng công cụ sẵn có dịch đặc tả sang mã nguồn.
Do hạn chế về thời gian và điều kiện nghiên cứu nên luận văn mới dừng lại ở mức nghiên cứu và đưa ra và chứng minh một số phép biến đổi cơ bản, còn nhiều phép biến đổi phức tạp cần được tiếp tục nghiên cứu và chứng minh. Hướng nghiên cứu tiếp theo của đề tài này là:
- Bổ sung thêm các thuật toán làm mịn, đặc biệt là các thao tác phức tạp liên quan đến đa thừa kế, gói mô hình để hoàn thiện quy trình phát triển hệ thống hướng đối tượng cho đa số lớp bài toán gặp phải.
- Hoàn thiện công cụ với các thao tác được mô tả trong các thuật toán sẽ được bổ sung, thêm các chức năng dịch xuôi và dịch ngược mô hình sang mã nguồn, nhập (import) file XMI từ các công cụ khác để kiểm chứng tính đúng đắn của đặc tả hệ thống và tính hợp lệ của phép biến đổi giữa các bước làm mịn.
DANH MỤC CÁC CÔNG TRÌNH CỦA TÁC GIẢ
[CT1] Nguyễn Hoàng Hà, Nguyễn Văn Vỵ (2007), Xây dựng công cụ trợ giúp
đặc tả hình thức hóa một hệ thống phần mềm hướng đối tượng, Báo cáo hội thảo quốc gia “Một số vấn đề chọn lọc của công nghệ thông tin 2007”, Đại Lải – Vĩnh Phúc 9/2007.
[CT2] Nguyen Hoang Ha, Nguyen Viet Ha, Truong Ninh Thuan and Tran Thi Mai Thuong (2007), Verifying the compatibility of Components’ Ports upon specification, Japan–Vietnam workshop on Software Engineering 2007, Hanoi.
TÀI LIỆU THAM KHẢO
Tiếng Việt
[1] Đặng Văn Đức, Nguyễn Mạnh Đức, Nguyễn Văn Vỵ (2006), Phương pháp hình thức phát triển hệ thống hướng đối tượng dựa trên quan hệđại số, Báo cáo hội thảo quốc gia: “Một số vấn đề chọn lọc của công nghệ thông tin và truyền thông”, Đà Lạt.
[2] Đặng Văn Đức (2002), Phân tích thiết kế hệ thống hướng đối tượng bằng UML, Nhà xuất bản Giáo Dục, Hà Nội.
[3] Nguyễn Mạnh Đức (2007), Ứng dụng phân tích thiết kế hướng đối tượng vào xây dựng hệ thống thông tin phức tạp. Luận án tiến sỹ, viện Khoa học và Công nghệ Việt Nam, Hà Nội.
[4] Nguyễn Hoàng Hà, Nguyễn Văn Vỵ (2007), Xây dựng công cụ trợ giúp đặc tả hình thức hóa một hệ thống phần mềm hướng đối tượng, Báo cáo hội thảo quốc gia: “Một số vấn đề chọn lọc của công nghệ thông tin và truyền thông 2007”, Đại Lải - Vĩnh Phúc.
[5] Nguyễn Văn Vỵ (2002), Phân tích thiết kế hệ thống thông tin hiện đại - Hướng cấu trúc và hướng đối tượng, NXB Thống kê, Hà Nội.
[6] Nguyễn Văn Vỵ (2004), Bài giảng “Phân tích thiết kế hệ thống phần mềm theo hướng đối tượng”, Trường Đại học Công nghệ - ĐHQG Hà Nội.
Tiếng Anh
[7] P. Andre, A. Romanczuk, J.C. Royer and A. Vasconcelos (2000), Checking the consistency of UML class diagrams using Larch Prove. In Proc. ROOM’2000, York, UK.
[8] Booch, G., Rumbaugh, J. and Jacobson (1999), The Unified Modeling Language User Guide, Addison-Wesley.
[9] Zhengbang Chen, Abel Hakim Hannousse and some fellow-workers at UNU/IIST (2007), Modelling with Relation Calculus of Object and Component System – rCOS, Technical report UNU/IIST No.328, UNU/IIST: International Institute for software technology, the United Nations University, Macau, Septermber 2007.
[10] Martin Fowler (2000), Refactoring, improving the design of existing code,
Addison-Wesley.
[11] Erich Gamma, Richard Helm, Jalph Johnson and John Vlissides (1998),
Design patterns: Elements of reusable object-oriented software, Addison Wesley
[12] Jifeng He, Li Xiaohan and Zhiming Liu (May 2002), Towards a Refinenment Calculus for Object System, Technical report UNU/IIST No.251, UNU/IIST: International Institute for software technology, the United Nations University, Macau, May 2002.
[13] Jifeng He, Li Xiaohan Zhiming Liu and Jing Liu (2003), Unifying Views of UML, Technical report UNU/IIST No.288, UNU/IIST: International Institute for software technology, the United Nations University, Macau, October 2003.
[14] Jifeng He, Li Xiaohan, Zhiming Liu and S.Qin (2004), A relational model for object-oriented designs. In Pro APLA’2004 LNCS 3302, Taiwan, Springer. [15] J. He, X. Li and Z. Liu (2006), rCOS: A Refinement Calculus of Object
[16] C.A.R. Hoare and He Jifeng (1998), Unifying Theories of Programming,
Prentice Hall.
[17] IBM Corp (2007), Rational Rose website
http://www.306.ibm.com/software/rational/
[18] Ivar Jacobson, Gray Booch and James Rumbaugh (2000), The Unified Software Development Process, Addision-Wesley.
[19] Ivar Jacobson, Magnus Christerson, Patrick Jonsson, Gunnar Overgaard (2000), Object-Oriented Software Engineering, Use case Drive Approach,
ISBN 0-210-54435-0, Addision-Wesley.
[20] Joshua Kerievsky (2004), Refactoring to patterns, Addison-Wesley.
[21] P. Kuchten(2000), The Rational Unified Process – An Introduction, Addison- Wesley.
[22] Graig Larman (2001), Applying UML and patterns, Prentice-Hall International.
[23] Quan Long, He Jifeng, Zhiming Liu (2005), Refactoring and pattern-directed refactoring: A formal perspective, Technical report UNU/IIST No.318, UNU/IIST: International Institute for software technology, the United Nations University, Macau, January 2005.
[24] Microsoft Corp (2005). MSDN Library 2005 DVD. [25] OMG (2005), MOF 2.0/XMI Mapping Specification, v2.1
[26] OMG (February 2007), Unified Modeling Language: Superstructure, version 2.1.1.
[27] OMG (2007), UML 2.1.1 Infrastructure Specification.
[28] Roger S.Pressman (2001), Software Engineering, a Practitioner’s Approach. 5th Edition, McGraw Hill.
[29] Steve Schneider (2001), The B-Method: An Introduction, ISBN 0-333-79284- X, Palgrave New York.
[30] Ian Sommerville (2004), Software Engineering. 7th Edition, ISBN 0-321- 21062-3, Addison-Wasley.
[31] Truong Ninh Thuan (2006), Introduction to Formal Method, Slides of Formal methods Curriculum, College of technology – VNU, Hanoi.
PHỤ LỤC
Nội dung file XML theo chuẩn XMI của phần III.5.3
1. Cấu trúc chính
<?xml version="1.0"?>
<XMI xmi.version="1.1" xmlns:UML="//org.omg/UML/1.3"> <XMI.header>
<XMI.documentation>
<XMI.exporter>FM tool - Nguyen Hoang Ha</XMI.exporter> <XMI.exporterVersion>1.0</XMI.exporterVersion>
</XMI.documentation> </XMI.header>
<XMI.content>
<UML:Model xmi.id="647e9caa-f726-4559-9dc5-30f4ba6b4c43"> <UML:Namespace.ownedElement>
<!--Phần mô tả lớp Person--> <!--Phần mô tả lớp Student--> <!--Phần mô tả lớp Teacher--> <!--Phần mô tả lớp Seminar-->
<!--Phần mô tả các mối quan hệ giữa các lớp--> </UML:Namespace.ownedElement>
</UML:Model>
<UML:DataType name="Person" xmi.id="dataRef8" /> <UML:DataType name="string" xmi.id="dataRef1" /> <UML:DataType name="Seminar" xmi.id="dataRef11" /> <UML:DataType name="long" xmi.id="dataRef5" /> <UML:DataType name="double" xmi.id="dataRef4" /> <UML:DataType name="Student" xmi.id="dataRef9" /> <UML:DataType name="Teacher" xmi.id="dataRef10" /> <UML:DataType name="byte" xmi.id="dataRef3" /> <UML:DataType name="int" xmi.id="dataRef" /> <UML:DataType name="float" xmi.id="dataRef6" /> <UML:DataType name="char" xmi.id="dataRef0" /> <UML:DataType name="bool" xmi.id="dataRef2" /> </XMI.content>
2. Phần mô tả lớp Person
<UML:Class name="Person" xmi.id="e9815153-8974-4d9b-ab15-ae742509a429"
isLeaf="false" isAbstract="false" visibility="public"> <UML:Classifier.feature>
<UML:Attribute name="name" xmi.id="49d1cd59-4f0f-4e8e-a95a- d433589d6576" ownerScope="instance" isAbstract="false"
visibility="protected">