GIÁO TRÌNH PHÁT TRIỂN PHẦM MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI

Chia sẻ: Trần Văn Nam | Ngày: | Loại File: PDF | Số trang:0

Thêm vào BST

Báo xấu

108
lượt xem 17
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

tài liệu tham khảo dành cho sinh viên đại học cao đẳng chuyên về phần mềm. Tài liệu được biên soạn bởi thầy Nguyễn Văn Vị

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: GIÁO TRÌNH PHÁT TRIỂN PHẦM MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI

TRƯỜNG ĐẠI HOC CÔNG NGHỆ BỘ MÔN CÔNG NGHỆ PHẦN MỀM NGUYỄN VĂN VỴ BÀI GIẢNG PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI HA NỘI – 2008
Chương I NGÔN NGỮ MÔ HÌNH HÓA THỐNG NHÂT (Unified Modeling Laguage - UML) UML là một ngôn ngữ mô hình hoá chuẩn để giúp tạo ra các sản phẩm đặc tả khác nhau trong quá trình phát triển một hệ thống phần mềm hướng đối tượng, trong đó đặc biệt là các bản thiết kế phần mềm. Nó được hợp nhất từ nhiều thành tựu và kinh nghiệm trong việc nghiên cứu và triển khai thuộc lĩnh vực công nghệ thông tin của các nhà khoa học, những chuyên gia nghiên cứu và triển khai, trong đó nổi bật nhất là Grady Booch và Ivar Jacobson (với Object-Oriented Software Engineering - OOSE), James Rumbaugh (với Object Modeling Technique -OMT). Lịch sử phát triển của UML được mô tả như ở hình 1.1. Superstructure, OMG phát hành 10/04 UML 2.0 Infrastructure Specifycation OMG phát hành 9/01 UML 1.4 UML Metamodel , MOF & CORBA UML 1.3 three books Nhóm RTF OMG duyệt, fát hành cuối 99 - User Guide - Reference Manual UML 1.1 9/97 trình lên OMG, 11/97 thông qua 1/97 trình lên OMG , 7/97 duyệt UML 1.0 Phiên bản Beta OOPSLA ´96 WWW chỉ đặc tả, UML 0.9 lập tài liệu WWW – 6/96 OOPSLA 10/95 Unified Method 0.8 Rumbaughh - Objectory Phương pháp Booch –Jacobson OMT khác OOSE Hình 1.1. Lịch sử phát triển của UML
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 4 UML thích hợp cho việc mô hình hoá các hệ thống, từ các hệ thống thông tin xí nghiệp đến các ứng dụng phân tán dựa trên Web và cả các hệ thống nhúng thời gian thực. Nó là ngôn ngữ biểu diễn đặc tả đề cập được mọi khung nhìn cần thiết cho việc phát triển và sau đó là triển khai các hệ thống nói trên. UML chỉ là một ngôn ngữ và vì vậy nó cần phải là một phần của phương pháp phát triển phần mềm. UML là một ngôn ngữ độc lập với quá trình phát triển, mặc dù vậy, tốt hơn cả là nó cần được sử dụng trong một tiến trình phát triển. 1.1. Khái niệm về mô hình hóa 1.1.1. Mô hình và mô hình hóa Một mô hình (model) là một sự mô tả đơn giản hoá đối tượng của thế giới thực. Có thể xem mô hình là “hình ảnh” của đối tượng được nhìn nhận theo những góc nhìn nào đó. Mô hình hóa là quá trình mô tả đối tượng bằng những mô hình khác nhau. Phương pháp mô hình hóa [Vy2002] là phương pháp nghiên cứu đối tượng thông qua việc nghiên cứu các mô hình của chúng. Mô hình hoá là một phần trung tâm của tất cả các hoạt động dẫn đến việc triển khai một phần mềm tốt. Chúng ta xây dựng mô hình để truyền đạt một cấu trúc và hành vi mong muốn của hệ thống. Chúng ta xây dựng mô hình để trực quan hoá và kiểm soát kiến trúc của hệ thống. Chúng ta xây dựng mô hình để hiểu rõ hơn hệ thống mà chúng ta đang xây dựng, và thường làm lộ ra những cơ hội để đơn giản hoá và để sử dụng lại. Chúng ta xây dựng các mô hình để chế ngự rủi ro khi phát triển hệ thống. 1.1.2. Các nguyên tắc mô hình hoá Việc sử dụng mô hình hoá đã có một lịch sử phong phú trong mọi ngành kỹ nghệ. Kinh nghiệm đó đã nêu ra bốn nguyên tắc cơ bản của việc mô hình hoá. Thứ nhất: Việc lựa chọn mô hình nào để xây dựng là quan trọng. Nó ảnh hưởng sâu sắc đến vấn đề sẽ được giải quyết như thế nào, một giải pháp tốt sẽ được thành hình ra sao. Các mô hình đúng sẽ giải thích một cách sáng suốt các vấn đề rắc rối nhất của sự phát triển, nó đem lại sự hiểu biết sâu sắc và đơn giản mà không thể nhận được bằng một cách khác. Những mô hình sai sẽ làm ta nhầm lẫn, khiến sự việc trở nên khó hiểu và làm ta chú ý đến những vấn đề không quan trọng hoặc chẳng liên quan gì. Thứ hai: Mỗi mô hình có thể được diễn tả ở các mức độ chính xác khác nhau
5 Chương I Ngôn ngữ mô hình hóa thống nhất Một mô hình có thể thực hiện nhanh và đơn giản chỉ qua giao diện người dùng, chính là cái mà chúng ta cần. Nhưng lần khác, chúng ta phải khổ ải với các bit, như khi đặc tả các giao diện giữa các hệ thống dựa trên máy tính hoặc vật lộn với những tắc nghẽn của một mạng. Trong bất kỳ trường hợp nào, loại mô hình tốt nhất chính là loại cho phép ta chọn cấp độ chi tiết tuỳ thuộc vào việc ai đang là người lập khung nhìn, và vì sao họ lại cần khung nhìn đó. Một nhà phân tích hoặc một người dùng ở mức cuối sẽ muốn tập trung vào các vấn đề về “cái gì”. Một nhà phát triển lại muốn tập trung vào vấn đề “như thế nào”. Cả hai người này đều mong có được hệ thống ở những mức độ chi tiết khác nhau tại các thời điểm khác nhau. Thứ ba: Các mô hình tốt nhất luôn gắn với thực tế Mô hình một toà nhà cao tầng không có giải pháp đúng với các vật liệu sử dụng thì mô hình đó chỉ có giá trị hạn chế. Một mô hình toán học của một máy bay mà chỉ giả thiết với các điều kiện lý tưởng và sự chế tạo hoàn hảo, có thể che đi những đặc trưng thảm họa tiềm tàng của chiếc máy bay thực. Điều tốt nhất là cần có các mô hình gắn bó chặt chẽ với thực tế, và ở đâu mà sự gắn bó này là yếu kém thì cần biết chắc rằng các mô hình đã tách rời thế giới thực như thế nào. Mọi mô hình đều làm đơn giản hóa thực tế; vấn đề mấu chốt là làm sao để đảm bảo rằng, các sự đơn giản hoá đó không che đi bất kỳ một chi tiết quan trọng nào của thực tế. Trong phần mềm, gót chân Asin của các kỹ thuật phân tích đã được cấu trúc, đó là sự tách rời quan trọng giữa mô hình phân tích và mô hình thiết kế các hệ thống. Không khắc phục được khoảng cách này thì hệ thống theo nhận thức và hệ thống được xây dựng càng xa rời nhau theo thời gian. Thứ tư: Không có mô hình đơn lẻ nào là đầy đủ. Mọi hệ thống không tầm thường đều được tiếp cận tốt nhất bằng một tập các mô hình tương đối độc lập với nhau. “Tương đối độc lập” ở đây có nghĩa là, các mô hình có thể được xây dựng và nghiên cứu tách rời nhau nhưng vẫn có quan hệ với nhau. Để hiểu được kiến trúc một hệ thống, ta cần một số khung nhìn bổ sung và xen cài vào nhau: một khung nhìn theo ca sử dụng (trình bày các yêu cầu của hệ thống), một khung nhìn thiết kế (nắm bắt từ vựng của không gian vấn đề và không gian các giải pháp), một khung nhìn tiến trình (mô tả trình tự các chuỗi hoạt động diễn ra và các chuỗi khác nhau của hệ thống). một khung nhìn thực thi (nhằm vào sự thực hiện thực tế cho hệ thống), và một khung nhìn triển khai (tập trung vào các vấn đề kỹ nghệ của hệ thống). Mỗi một khung nhìn này có thể bao hàm cả khía Biên soạn: Nguyên Văn Vỵ
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 6 cạnh cấu trúc và khía cạnh hành vi. Khi kết hợp lại với nhau, chúng cho ta một thể hiện cho các bản vẽ thiết kế của phần mềm. Tuỳ thuộc vào bản chất của hệ thống, một vài mô hình có thể quan trọng hơn các mô hình khác. Chẳng hạn, trong các hệ thống dùng nhiều dữ liệu, các mô hình nhằm vào các khung nhìn thiết kế tĩnh sẽ chiếm ưu thế. Trong các hệ thống dùng nhiều giao diện đồ hoạ người dùng thì các khung nhìn ca sử dụng tĩnh và động là quan trọng hơn. Trong các hệ thống thời gian thực, các khung nhìn tiến trình động có trở nên quan trọng hơn. Cuối cùng, trong các hệ thống được phân loại, như ta thấy trong các ứng dụng dùng nhiều trang Web, các mô hình thực thi và triển khai là quan trọng nhất. 1.2. Các đặc trưng và khả năng UML 1.2.1. UML là một ngôn ngữ mô hình đồ họa Một ngôn ngữ nói chung phải cung cấp một bảng từ vựng và các nguyên tắc để tổ hợp các từ vựng với mục đích tạo nên những khối từ vựng có ngữ nghĩa để giao tiếp. Một ngôn ngữ mô hình hoá là một ngôn ngữ mà các từ vựng và các nguyên tắc của nó tập trụng vào biểu diễn bằng mô hình các khái niệm và các thể hiện vật lý của một hệ thống. UML là một ngôn ngữ mô hình hoá chuẩn để tạo ra các thiết kế phần mềm với các biểu diễn bằng mô hình. Bảng từ vựng và các quy tắc của một ngôn ngữ như UML cho ta biết cách làm thế nào để tạo ra và đọc những mô hình được xây dựng tốt, nhưng nó không bảo ta phải xây dựng những mô hình gì và khi nào phải xây dựng chúng. Những nội dung cuối cùng này thuộc vai trò của phương pháp luận phát triển phần mềm. Mô hình hoá giúp ta hiểu được một hệ thống. Không một mô hình nào là đầy đủ mãi. Vì thế, ta thường cần nhiều mô hình gắn kết với nhau để hiểu được mọi thứ của một hệ thống phức tạp. Đối với những hệ thống phần mềm chuyên sâu, việc này đòi hỏi có một ngôn ngữ đề cập đến các cách nhìn khác nhau về kiến trúc của một hệ thống khi nó tiến hoá trong suốt vòng đời phát triển phần mềm. Các biểu diễn mô hình trong UML sử dụng các ký pháp đồ hoạ. Sau mỗi biểu tượng của UML là một ngữ nghĩa hoàn toàn xác định. Nhờ vậy, một nhà phát triển có thể đặc tả thiết kế một hệ thống phần mềm bằng các mô hình trong UML, một nhà phát triển khác hay một công cụ khác có thể dịch nó sang một dạng biểu diễn khác một cách chính xác, không nhầm lẫn. Tất cả những gì được biểu diễn tốt nhất bằng đồ họa thì cũng được thực hiện tương tự trong UML, và những gì được thể hiện tốt bằng văn bản trong các ngôn ngữ lập trình hay trong cách mô tả khác thì
7 Chương I Ngôn ngữ mô hình hóa thống nhất cũng được thực hiện tốt bằng văn bản ở đây. Vì vậy, UML có những mặt mạnh của cả ngôn ngữ đồ hoạ và ngôn ngữ văn bản. 1.2.2. UML là một ngôn ngữ làm trực quan Đối với nhiều nhà lập trình, khoảng cách từ việc suy nghĩ để triển khai đến việc chuyển nó thành mã nguồn gần như là bằng 0. Anh ta nghĩ về nó và mã hoá nó. Trong những trường hợp này, lập trình viên vẫn phải làm một việc mô hình hóa nào đó mặc dù chỉ là nghĩ trong óc. Anh ta có thể phác hoạ một vài ý tưởng trên bảng đen hay khăn ăn. Tuy nhiên có những vấn đề nảy sinh với cách làm này. Thứ nhất:việc trao đổi các mô hình khái niệm này với người khác có thể bị sai lệch trừ khi người được trao đổi nói cùng một ngôn ngữ, có cùng cách nghĩ. Thứ hai: có những vấn đề trong các hệ thống phần mềm mà ta không thể hiểu được trừ khi xây dựng được mô hình mô tả nó có khả năng biểu diễn vượt xa ngôn ngữ lập trình dạng văn bản. Thứ ba: nếu người phát triển cắt bỏ mã mà không ghi lại các mô hình có ở trong đầu mình thì thông tin này sẽ biến mất vĩnh viễn hoặc chỉ được tái tạo lại từng phần từ việc thực thi, mỗi khi mà nhà phát triển tiến hành từng bước một. Việc viết các mô hình bằng UML là hướng vào giải quyết những vấn đề trên đây. Một mô hình tường minh sẽ tạo thuận lợi cho việc hình dung và giao tiếp. Một số sự vật được mô hình hoá tốt nhất bằng văn bản. Những sự vật khác lại được mô hình hoá tốt nhất bằng đồ họa. Bằng các ký pháp đồ họa và các biểu diễn bằng sơ đồ với các giải thích văn bản đi kèm, UML cho ta nhìn thấy được tất cả những điều suy nghĩ và hình dung một cách đầy đủ về một hệ thống cần xây dựng như nó sẽ tồn tại trong thế giới thực khi nhìn từ các khung nhìn khác nhau. 1.1.3. UML là một ngôn ngữ đặc tả, có cấu trúc Đặc tả có nghĩa là mô tả đối tượng một cách đặc biệt, cụ thể là xây dựng lên các mô hình cho đối tượng để mô tả nó một cách chính xác, không mù mờ và đầy đủ. Trên thực tế, UML hướng đến đặc tả tất cả những sản phẩm phân tích, thiết kế và các quyết định triển khai quan trọng mà cần phải làm khi phát triển một hệ thống phần mềm chuyên sâu. UML không phải là một ngôn ngữ lập trình trực quan, nhưng các mô hình của nó có thể ánh xạ vào một ngôn ngữ lập trình như C++, Visual Basic và Java hoặc các bảng trong một cơ sở dữ liệu quan hệ hoặc kho chứa của một cơ sở dữ liệu hướng đối tượng. Việc ánh xạ này cho phép thúc đẩy sự tiến bộ của kỹ nghệ: từ mô hình UML có thể sinh mã nguồn trong một ngôn ngữ lập trình (dịch xuôi) hay xây Biên soạn: Nguyên Văn Vỵ
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 8 dựng lại một mô hình UML từ một chương trình thực thi (dịch ngược). Khi kết hợp cả hai quá trình dịch xuôi tạo mã và dịch ngược để có mô hình ta thu được "kỹ nghệ đi-về" trong phát triển phần mềm, nghĩa là khả năng làm việc ở cả dạng văn bản hoặc dạng đồ họa, đảm bảo được sự nhất quán giữa hai dạng biểu diễn của hệ thống: thiết kế và mã nguồn. Với sự ánh xạ trực tiếp này, UML đủ để diễn tả một cách trực quan, rõ ràng, cho phép thực hiện trực tiếp các mô hình, mô phỏng hệ thống và bố trí công cụ cho hệ thống. 1.1.4. UML là ngôn ngữ làm tài liệu Một tổ chức sản xuất phần mền mạnh thường tạo ra tất cả các loại chế tác khác nhau đi kèm với chương trình thực hiện. Các chế tác này thường bao gồm: Các yêu cầu, các kiến trúc, các thiết kế, các chương trình nguồn, kế hoạch dự án, kế hoạch và kết quả kiểm thử, các bản mẫu và cái ra, các hướng dẫn sử dụng,... UML hướng đến việc làm tài liệu cho tất cả các sản phẩm đó của phần mềm. UML cũng cung cấp một ngôn ngữ để in ấn yêu cầu và kiểm thử. Cuối cùng, UML cung cấp một ngôn ngữ để mô hình hoá các hoạt động lập kế hoạch dự án và giải phóng nhiều lao động quản lý khác nhau. Với tất cả các đặc trưng trên, UML có những khả năng to lớn sau: 1. Là một công cụ dành cho việc thiết kế các hệ thống phần mềm chuyên sâu. Nó cũng được sử dụng hiệu quả để thiết kế cho các lĩnh vực khác như: Các hệ thống thông tin xí nghiệp, các dịch vụ tài chính và ngân hàng, viễn thông, giao thông vận tải, quốc phòng.., các dịch vụ phân tán trên web. 2. UML không hạn chế trong việc mô hình hoá phần mềm. Thực tế nó biểu diễn khá tốt mô hình hoá các hệ thống không phải phần mềm như luồng công việc trong hệ thống pháp luật, cấu trúc và hành vi của hệ thống sức khoẻ bệnh nhân, các thiết kế phần cứng.. . Riêng đối với các phần mềm hướng đối tương, UML đặc biệt có các khả năng sau: − Cho phép mô tả hầu như toàn bộ các sản phẩm của quá trình phát triển. − Trợ giúp việc tự động hoá quá trình phân tích và thiết kế trên máy tính. − Trợ giúp việc dịch xuôi và dịch ngược các thiết kế sang mã nguồn của ngôn ngữ lập trình và cơ sở dữ liệu. 1.3. Kiến trúc trong UML Kiến trúc phần mềm cho ta một cái nhìn khái quát nhất về hệ thống phần mềm ở các góc độ khác nhau. Kiến trúc là một tập các quyết định quan trọng về :
9 Chương I Ngôn ngữ mô hình hóa thống nhất − Tổ chức của một hệ thống phần mềm. − Sự lựa chọn các phần tử cấu trúc và các giao diện của chúng, nhờ đó mà hệ thống được hình thành. − Các hành vi của hệ thống sẽ được đặc tả thông qua sự cộng tác giữa các phần tử của nó. − Sự kết hợp các phần tử cấu trúc và phần tử hành vi này vào các hệ con ngày một lớn dần lên trong quá trình phát triển. Như minh hoạ ở hình 1.2, kiến trúc của hệ thống phần mềm chuyên sâu thường được mô tả tốt nhất bằng năm loại khung nhìn tương tác với nhau. Mỗi khung nhìn phản ánh một khía cạnh của tổ chức và cấu trúc của hệ thống mà tập trung vào từng mặt cụ thể giúp cho ta hiểu và sử dụng hệ thống tốt nhất. khung nhìn thiết kế khung nhìn triển khai khung nhìn ca sử dụng khung nhìn tiến trình khung nhìn bố trí Hình 1.2. Mô hình hoá kiến trúc hệ thống − Khung nhìn ca sử dụng (use case view) bao gồm các tác nhân, các ca sử dụng và mối quan hệ giữa chúng. Nó cho ta cách sử dụng chức năng (thể hiện bằng ca sử dụng) để mô tả hành vi của hệ thống khi nhìn nhận hệ thống dưới góc độ của người dùng cuối cùng, của nhà phân tích và người kiểm thử. − Khung nhìn thiết kế (design view) bao gồm các lớp, các giao diện, các sự cộng tác tạo nên từ vựng để đặc tả các vấn đề đặt ra và các giải pháp cho nó. Khung nhìn này hỗ trợ việc xác định các yêu cầu chức năng của hệ thống, nghĩa là các dịch vụ mà hệ thống sẽ cung cấp cho người dùng cuối cùng. − Khung nhìn tiến trình (process view) của hệ thống chứa đựng các luồng và tiến trình công việc tạo nên cơ chế hoạt động tương tranh và đồng bộ của hệ thống. Khung nhìn này chủ yếu hướng vào biểu diễn hiệu năng, quy mô và năng lực xử lý của toàn hệ thống. − Khung nhìn triển khai (implemetation view) của hệ thống bao gồm các thành phần và các file được kết hợp lại và đưa ra các mô tả về hệ thống vật lý. Khung nhìn này trước hết hướng vào việc quản lí cấu hình qua các đợt phát hành hệ thống, được tạo ra từ các thành phần độc lập và các tệp mà chúng có thể được Biên soạn: Nguyên Văn Vỵ
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 10 tập hợp lại theo nhiều cách khác nhau để xuất ra một hệ thống vận hành cho khách. − Khung nhìn cài đặt-bố trí (deployment view) bao gồm các nút của hệ thống tạo nên kết cấu phần cứng mà trên đó hệ thống phần mềm vận hành. Khung nhìn này chủ yếu hướng đến sự bố trí, phân tán và cài đặt cụ thể của hệ thống. Kiến trúc của phần mềm được dùng để quản lí các cách nhìn khác nhau này và như vậy để điều khiển sự phát triển lặp lại và tăng dần của một hệ thống trong suốt vòng đời của nó. 1.4. Mô hình khái niệm của UML Mô hình khái niêm (conceptual model) của UML gồm ba khối chính: các khối xây dựng cơ bản, các quy tắc ngữ nghĩa và một số cơ chế chung được áp dụng cho việc mô hình hoá (hình 1.3). (Từ vựng) Các khối xây dựng Sự vật Biểu đồ Quan hệ Phụ thuộc Ca sử dụng Sự vật Sự vật cấu Sự vật Sự vật Liên kết Lớp trúc hành vi chú thích nhóm gộp Tổng quát Đối tượng hoá Tuần tự Ca sử dụng Thực hiện Cộng tác Ghi Tương tác Gói Lớp Trạng thái chú Máy trạng Mô hình Lớp hoạt động Hoạt động thái Hệ thống Giao diện Thành phần con Thành phần Bố trí Khung làm Sự cộng tác việc Nút Hình 1.3. Cấu trúc các thành phần của UML 1.3.1. Các khối xây dựng (building blocks) Các khối xây dựng bao gồm: các sự vật, các mối quan hệ và các biểu đồ. Các sự vật (things) là các trừu tượng hoá (sự vật hay khái niệm của thế giới thực) và là những phần tử đầu tiên (những viên gạch) để xây dựng lên các mô hình trong UML. Các quan hệ (relationships) gắn kết các sự vật lại với nhau; và các biểu đồ
11 Chương I Ngôn ngữ mô hình hóa thống nhất (diagrams) nhóm các sự vật được quan tâm lại cùng với các quan hệ giữa chúng tạo nên ngữ nghĩa riêng của nó (cho một mô hình). 1.4.1.1. Các sự vật cấu trúc (structural things) a. Lớp (class) Một lớp mô tả một tập hợp các đối tượng có chung các thuộc tính (attribute), các tác vụ (operation), các mối quan hệ và ngữ nghĩa. Một lớp có trách nhiệm thực hiện một hay nhiều giao diện. Một lớp được biểu diễn bằng một hình chữ nhật chia làm ba phần: phần trên là tên, phần giữa là các thuộc tính và phần cuối là các tác vụ (hình 1.4). Một lớp khái niệm có thể chỉ có tên hay có thêm thuộc tính. Trong trương hợp đầy đủ nhất, lớp có thêm phần thứ tư dưới cùng để đặc tả các ràng buộc của lớp. Window tên origin thuộc tính size open() tác vụ close() move() display() Hình 1.4. Lớp b. Giao diện (interface) Một giao diện là một tập hợp các tác vụ đặc tả một hay một số dịch vụ mà một lớp hoặc một thành phần cung cấp (thực hiên). Nó thường được biểu diễn bằng một hình tròn có tên đi kèm (xem hình 1.5). Dãy các trách nhiệm ISpelling Hình 1.5. Sự cộng tác Hình 1.5. Giao diện c. Sự cộng tác (collaboration) Sự công tác xác định các hoạt động bên trong hệ thống và là một tập các phần tử với các nguyên tắc khác nhau cùng làm việc để cung cấp một hành vi hợp tác lớn hơn tổng (đơn thuần) các hành vi của tất cả các phần tử. Một sự cộng tác được ký hiệu bằng một hình elip với đường đứt nét và thường chỉ gồm có tên (hình 1.5.). Biên soạn: Nguyên Văn Vỵ
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 12 d. Ca sử dụng (use case) Một ca sử dụng mô tả một tập các dãy hành động mà hệ thống thực hiện để đáp lại tác động của tác nhân và kết thúc sẽ cho kết quả có thể quan sát được và có giá trị đối với một tác nhân của nó. Một ca sử dụng được ký hiệu bằng một hình elíp nét liền, thường chỉ bao gồm có tên (hình 1.7). Orderform.java Đặt đơn hàng Hình 1.7. Ca sử dụng Hình 1.8. Thành phần e. Thành phần (component) Thành phần là một bộ phận vật lý có thể thay thế được (độc lâp) của một hệ thống được làm phù hợp với những điều kiện cụ thể để cung cấp phương tiện (tác vụ) thực hiện một tập các giao diện. Một thành phần biểu diễn một gói vật lý các phần tử lôgic khác nhau như các lớp, các giao diện và sự cộng tác. Nó được ký hiệu bằng một hình chữ nhật với các bảng nhô ra và thường bao gồm chỉ có tên của nó (xem hình 1.8). Một thành phần có thể xem như một hộp đen, và sự tương tác của nó với các đối tượng khác chỉ thông qua giao diện. g. Lớp hoạt động (active class) Một lớp hoạt động là một lớp mà các đối tượng của nó sở hữu một hay một số tiến trình hoặc các dãy thao tác. Bởi vậy, nó có thể khởi động hoạt động điều khiển tiến trình. Một lớp hoạt động được ký hiệu như một lớp nhưng có đường viền đậm (hình 1.9). EventManager Máy dịch vụ supend() fluhs() Hình 1.10. Nút Hình 1.9. Lớp hoạt động h. Nút (node)
13 Chương I Ngôn ngữ mô hình hóa thống nhất Một nút là một phần tử vật lý tồn tại trong thời gian thực và biểu diễn một nguồn lực tính toán, thường có ít nhất bộ nhớ và một năng lực xử lý. Một nút ký hiệu bằng một hình hộp thường bao gồm tên của nó (xem hình 1.10). 1.4.1.2. Các sự vật hành vi (behavioral things) Các sự vật hành vi là những bộ phận động của các mô hình UML mô tả hành vi của hệ thống theo thời gian và không gian. Có hai loại hành vi sơ cấp của sự vât: a. Sự tương tác (Interaction) Sự tương tác là một hành vi bao gồm một tập các thông báo được trao đổi giữa một tập các đối tượng trong một khung cảnh cụ thể nhằm thực hiện một mục tiêu xác định. Một thông báo được kí hiệu bằng một đường thẳng có hướng, gồm tên của tác vụ (xem hình 1.11.) hiển thị chờ Hình 1.11 : Thông báo Hình 1.12 : Trạng thái b. Máy trạng thái (State machine) Một máy trạng thái gồm một số các phần tử biểu diễn các trạng thái, các chuyển dịch (từ một trạng thái sang một trạng thái khác) và các sự kiện (các sự vật kích hoạt sự chuyển dịch). Một trạng thái được kí hiệu bằng một hình chữ nhật góc tròn trong đó có tên trạng thái và các trạng thái con của nó (nếu có) (hình 1.12). 1.4.1.3. Các sự vật nhóm gộp (grouping things) Có một loại sự vật nhóm gộp duy nhất là gói (package). Nó là công cụ để tổ chức các thành phần của một mô hình thành các nhóm: Một mô hình có thể được phân chia (một cách khái niệm) vào trong các gói nhằm mô tả một bộ phận của hệ thống. Một gói đơn thuần là một khái niệm. Một gói được kí hiệu như một bảng thường chỉ gồm có tên, và đôi khi có nội dung của nó (Hình 1.13) Các quy tắc trả lại bản sao nghiệp vụ Hình 1.13 : Gói Hình 1.14 : Chú thích Biên soạn: Nguyên Văn Vỵ
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 14 1.4.1.4. Sự vật giải thích (annontional thing) Sự vật giải thích là phần giải thích của mô hình UML. Nó có thể sử dụng để mô tả, giải thích và đánh dấu một phần tử bất kì trong một mô hình. Nó thể hiện ra như một ghi chú (note) và được kí hiệu bằng một hình chữ nhật có góc gấp cùng với một lời bình luận, một sự mô tả bằng văn bản hay đồ thị ở bên trong (hình 1.14.). 1.4.1.5. Các quan hệ (relationships) a. Sự phụ thuộc (dependency) Sự phụ thuộc là một mối quan hệ ngữ nghĩa giữa hai sự vật, trong đó sự thay đổi của một sự vật (sự vật độc lập) có thể tác động đến ngữ nghĩa của một sự vật khác (sự vật phụ thuộc). Sự phụ thuộc được kí hiệu bằng một đường nét đứt, có thể có hướng và tuỳ trường hợp có thể có nhãn ghi ở bên (hình 1.15). 0..1 * Người thuê Nhân viên Hình 1.15 : Quan hệ phụ thuộc Hình 1.16 : Liên kết b. Sự liên kết (association) Sự liên kết là một mối quan hệ cấu trúc mô tả một tập các sự gắn kết giữa một số các đối tượng. Sự liên kết được kí hiệu bằng đường liền nét, có thể có hướng bao gồm một nhãn và thường chứa các bài trí khác nhau giải thích vai trò của đối tượng tham gia vào liên kết và các bản số (số các đối tượng tham gia liên kết) của chúng (hình 1.16). c. Tổng quát hoá (generalization) Tổng quát hoá là một mối quan hệ tổng quát hoá hay cá biệt hoá mà trong đó các đối tượng của phần tử cá biệt hoá (con) có thể thay thế được cho các đối tượng của phần tử được tổng quát hoá (cha). Mối quan hệ tổng quát hoá được kí hiệu bằng đường nét liền với mũi tên rỗng chỉ về phía cha. (hình 1.17) con cha Hình 1.18 : Sự thực hiện Hình 1.17 : Tổng quát hoá d. Sự thực hiện (realization)
15 Chương I Ngôn ngữ mô hình hóa thống nhất Sự thực hiện là một mối quan hệ ngữ nghĩa giữa các phân lớp, trong đó xác định một hợp đồng sao cho những phân lớp khác nhau đảm nhiệm thực hiện những trách nhiệm khác nhau. Mối quan hệ thực hiện được đưa vào hai vị trí: giữa các giao diện và các lớp hoặc các thành phần thực hiện nó. Một mối quan hệ thực hiện được xem như mối quan hệ nằm giữa mối quan hệ tổng quát và mối quan hệ phụ thuộc, và vì thế được kí hiệu bằng một đường nét đứt có mũi tên trống, như trong hình 1.18. Bốn mối quan hệ này mô tả các sự vật quan hệ cơ bản trong UML. Có thể có những biến thể khác của chúng, chẳng hạn như làm mịn (refinement), lần vết (trace), bao hàm (include) hay mở rộng (extend) (cũng là những mối quan hệ phụ thuộc). 1.5. Các biểu đồ trong UML Một biểu đồ là một biểu diễn đồ thị của một tập các phần tử (các từ vựng) thường được thể hiện như một đồ thị liên thông với các đỉnh (là các sự vật) và các cung (là các mối quan hệ) dùng để mô tả về một sự vật nào đó cho một ngữ nghĩa xác định. 1.5.1. Biểu đồ lớp Biểu đồ lớp (class diagram) chỉ một tập các lớp, các giao diện và các sự công tác và các mối quan hệ của chúng (hình 1.18). Ta sử dụng biểu đồ lớp để mô hình hoá khung nhìn thiết kế tĩnh của hệ thống. Ta thường sử dụng biểu đồ lớp để: − Mô hình hoá bảng từ vựng của hệ thống − Mô hình hoá các sự cộng tác đơn giản. − Mô hình hoá cơ sở dữ liệu logic. 1 * PathAgent ConllisionSensor Responsibilities 1 1 Drive --seek path --avoid obstacles 1 1 MainMotor SteeringMotor Motor move (d :Direction, s: Speed) stop() Status() Biên soạn: Nguyên Văn Vỵ Integer distantce()
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 16 Các mối quan hệ trong biểu đồ lớp 1. Liên kết 3. Kết hợp 2. Phụ thuộc 4. Kết tập 3. Kế thừa 15.2. Biểu đồ đối tượng c: Company d1 : Department d2 : Department name = "Sales" name = "R&D" đối tượng Giá trị thuộc tính d3 : Department Liên link t kế name: "US Sales" đối tượng ẩn tên : ContactInformation p : Person address= "1472 Miller St" name = "Erin" title = "VP of Sales employeeID = 4362 Hình 1.19: Biểu đồ đối tượng Biểu đồ đối tượng (object diagram) mô hình hoá các thể hiện của các sự vật trong một biểu đồ lớp. Một biểu đồ đối tượng đưa ra một tập các đối tượng và các mối quan hệ giữa chúng tại một thời điểm (hình 1.19). Ta sử dụng biểu đồ đối tượng để mô hình hoá các khía cạnh thiết kế tĩnh hoặc các khía cạnh tiến trình tĩnh của hệ thống. Nó cũng được sử dụng để mô hình hoá cấu trúc của đối tượng. 1.5.3. Biểu đồ ca sử dụng Biểu đồ ca sử dụng (use case diagram) để mô hình hoá các khía cạnh động của hệ thống. Nó là trung tâm để mô hình hoá hành vi của hệ thống, một hệ thống
17 Chương I Ngôn ngữ mô hình hóa thống nhất con, một lớp. Mỗi biểu đồ chỉ ra một tập các ca sử dụng, các tác nhân và các mối quan hệ giữa chúng. Biểu đồ ca sử dụng mô tả cách nhìn từ bên ngoài để thấy được bối cảnh mà trong đó hệ thống đang tồn tại và những mối quan hệ giữa nó và môi trường, mô tả hoạt động của hệ thống từ bên ngoài không lệ thuộc vào việc nó thực hiện những hoạt động đó như thế nào (hình 1.20). Vì vậy, mô hình ca sử dụng là phương tiện để mô tả các yêu cầu của hệ thống. Ta sử dụng biểu đồ ca sử dụng để: − Mô hình hoá ngữ cảnh của hệ thống − Mô hình hoá các yêu cầu của một hệ thống. Gửi tiền Rút tiền khách hàng ngân hàng Chuyển tiền Hình 1.20. Mô hình ca sử dụng hệ thống giao dịch tín dụng Các mối quan hệ trong biểu đồ ca sử dụng 1. Phụ thuộc 3. Sử dụng / mở rộng 2. Kế thừa 4. Hiển thi 1.5.4. Biểu đồ tương tác Biểu đồ tương tác (interaction diagram) gồm hai loại là biểu đồ tuần tự (sequence diagram) và biểu đồ cộng tác (collaboration diagram) (hình 1.21). Chúng dùng để mô hình hoá các khía cạnh động của hệ thống. Nó bao gồm một tập các đối tượng và các mối quan hệ truyền thông báo giữa chúng. Biểu đồ tuần tự nhấn mạnh tới trình tự thời gian của các thông báo; còn biểu đồ cộng tác nhấn mạnh tới tổ chức cấu trúc của các đối tượng gửi và nhận thông báo. Ta có thể sử dụng hai biểu đồ tương tác thay thể cho nhau và dùng để: Biên soạn: Nguyên Văn Vỵ
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 18 c:Client Đối tượng p:ODBCProxy :Transaction thông điệp setAction(a,d,o) setValue(d,3,4) setValue(a,”CO”) commited Đường sống Hình 1.21.a. Biểu đồ tuần tự c:Client 1: 2: setAction(a,d,o) liên kết 3: thông điệp :Transaction p:ODBCProxy 2.1: setValue(d,3,4) 2.2: setValue(a,”CO”) Hình 1.21.b. Biểu đồ cộng tác − Mô hình hoá các luồng điều khiển (sự kiện) theo trình tự thời gian − Mô hình hoá các luồng điều khiển của tổ chức. 1.5.4. Biểu đồ sơ đồ trạng thái Biểu đồ trạng thái (statechart diagram) biểu diễn một máy trạng thái. Nó biểu diễn dòng điều khiển từ trạng thái này tới trạng thái khác. Nó nhấn mạnh dòng điều khiển từ hoạt động này đến hoạt động khác đang xảy ra bên trong một máy trạng thái (hình 1.22).
19 Chương I Ngôn ngữ mô hình hóa thống nhất Hình 1.22. Biểu đồ trạng thái 1.5.5. Biểu đồ hoạt động Biểu đồ hoạt động (activity diagram) là trường hợp đặc biệt của biểu đồ trạng thái. Nó chỉ dòng điều khiển chính từ hoạt động này đến hoạt động khác, nó cũng bao gồm việc mô hình hóa các bước tuần tự (có thể là đồng thời) trong một tiến trình xử lý. Biểu đồ trạng thái và biểu đồ hoạt động biểu diễn khía cạnh động của hệ thống. Chúng có thể dùng cho việc mô hình hoá vòng đời của một đối tượng. Ta sẽ dùng biểu đồ hoạt động để: Mô hình hoá luồng công việc( có thể có rẽ nhánh, phân nhánh, sát nhập) Mô hình hoá một tác vụ (một thủ tục tính toán) (hình 1.23) Prepare for speech phân nhánh Decompress Gesture() Stream audio() Synch mouth() sát nhập cleanup Hình 1.23 : Biểu đồ hoạt động có phân nhánh và sát nhập Biên soạn: Nguyên Văn Vỵ
PHÁT TRIỂN PHẦN MỀM HƯỚNG ĐỐI TƯỢNG VÀ SỬ DỤNG LẠI 20 1.5.6. Biểu đồ thành phần Các biểu đồ thành phần (component diagram) sử dụng để mô hình hoá mặt vật lý của các hệ thống hướngđối tượng. Nó cho ta cách nhìn việc bố trí và thực thi tĩnh của một hệ thống (hình 1.24). Ta sử dụng biểu đồ thành phần để: f i l e thùc thi tr ang f i nd.htm l fin d .e x e i ndex .htm l dbacs.dl l nateng.dl l thµnh phÇn th- v i Ön H × 15.22: M ét bi Ó ®å thµnh phÇn nh u Hình 1.24. Mộ số biểu đồ thành phần − Mô hình hoá mã nguồn − Mô hình hoá xuất phẩm có thể thực hiện được − Mô hình hoá các cơ sở dữ liệu vật lý − Mô hình hoá các hệ thống có thể làm thích ứng được 1.5.7. Biểu đồ bố trí Biểu đồ bố trí (deployment diagram) mô hình hoá các khía cạnh vật lý của một hệ thống hướng đối tượng. Nó biểu diễn cấu hình các nút xử lý đang vận hành và các thành phần hoạt động ở trên chúng (hình 1.25). Nó có thể còn bao gồm các nút và các ràng buộc. Nó cũng hướng vào việc mô hình hoá sự phân tán, gửi đi và cài đặt các phần tạo nên hệ thống vật lý. Ta sẽ sử dụng các biểu đồ bố trí để: − Mô hình hoá các hệ thống nhúng − Mô hình hoá các hệ thống máy khách/ máy dịch vụ − Mô hình hoá các hệ thống phần tán đầy đủ Mặc dù chín biểu đồ trên đã vượt xa nhu cầu chung nhất mà ta thường gặp trong thực tế phát triển phần mềm hướng đối tượng. Tuy nhiên, UML còn cung cấp những loại biểu đồ khác cho phép mô hình hoá những trường hợp tinh tế hơn [2].