MỞ ĐẦU Phát triển phần mềm ngày càng trở nên phức tạp. Thay đổi giao diện từ các xâu ký tự sang giao diện đồ họa xu thế sự kiện; kiến trúc hệ thống đa tầng khách/chủ; cơ sở dữ liệu (CSDL) phân tán; Internet … làm tăng độ phức tạp của hệ thống phần mềm. Thách thức trong hai mƣơi năm tới của xây dựng hệ thống phần mềm không phải là tốc độ thực hiện chƣơng trình, kinh phí hay sức mạnh của nó mà vấn đề sẽ là độ phức tạp (Sun Microsystem). Kẻ thù của chúng ta là độ phức tạp, ta phải loại bỏ chúng (Jan Bean).
Vậy, loại bỏ độ phức tạp bằng cách nào? Các phƣơng pháp tiếp cận hƣớng cấu trúc, tiệm cận hƣớng logic, tiếp cận hƣớng hƣớng đối tƣợng và tiếp cận hƣớng tác tử để có thể giải quyết vấn đề này nhƣng ở mức độ khác nhau. Tổng quát thì việc xây dựng phần mềm phải quan tâm đến tổ chức, các quan hệ và cấu trúc để hình thành đƣợc các hành vi phức tạp của hệ thống. Mọi việc khảo sát hệ thống phải đƣợc thực hiện với mức độ trừu tƣợng khác nhau, từ các chi tiết đến tổ chức tổng thể. Do vậy, xây dựng phần mềm là thực hiện dãy tƣơng tác chia nhỏ và hợp nhất.
Chia nhỏ để hiểu rõ vấn đề và hợp nhất để xây dựng hệ thống. Tiến trình chia nhỏ (tách) đã có truyền thống và tuân thủ các tiêu chí chức năng. Các chức năng của hệ thống đƣợc nhận diện, sau đó chúng đƣợc tách thành các chức năng con. Tiến trình này đƣợc thực hiện lặp đi lặp lại cho đến khi có đƣợc các thành phần đơn giản đến mức chúng đƣợc biểu diễn trực tiếp bằng các hàm hay thủ tục của ngôn ngữ lập trình (hình 1.
Cách tiếp cận này đƣợc gọi là tiếp cận hƣớng chức năng (hay còn gọi là thủ tục, truyền thống). Ngƣời phát triển phần mềm sẽ tập trung vào các nhiệm vụ điều khiển và tách thuật toán lớn thành các thuật toán nhỏ. Khối chính để hình thành phần mềm ở đây là các hàm hay thủ tục. Chức năng chính Chức năng con 1 Chức năng con 2 Chức Chức Chức Chức năng năng con năng con năng con con 1.1 Tiếp cận hướng chức năng Kiến trúc phần mềm đƣợc cài đặt theo cách tiếp cận vừa mô tả trên sẽ phản ảnh các chức năng hệ thống.
Tiếp cận trên cơ sở chức năng và cơ chế phân cấp chỉ cho lại kết quả mong muốn khi các chức năng đƣợc nhận biết đầy đủ và nó không đƣợc thay đổi theo thời gian. Thực tế lại không đúng nhƣ vậy vì trong rất nhiều trƣờng hợp, phát triển phần mềm không bao giờ kết thúc hoàn toàn, luôn có cái gì đó phải sửa đổi, nâng cấp. Sửa đổi hay mở rộng hệ thống quá nhiều làm cho chƣơng trình khác xa quan niệm ban đầu. Do đó cần phải có phƣơng pháp mới cho khả năng làm chủ đƣợc độ phức tạp, giúp quản lý đƣợc chất lƣợng, độ tin cậy phần mềm ngày cả khi cấu trúc bị tách ra hay tiến hóa.
Phát triển phần mềm bằng UML trang | 8 Mở Cửa Phong thang may Lên tầng 2 Bật đen Đèn Công t ắc Hình 1.2 Tiếp cận hướng đối tượng Quan điểm hƣớng đối tƣợng hình thành trên cơ sở tiếp cận hƣớng hệ thống, nó coi hệ thống nhƣ thực thể đƣợc tổ chức từ các thành phần mà chỉ đƣợc xác định khi nó thừa nhận và có quan hệ với các thành phần khác. Phƣơng pháp tách vần đề đang giải quyết để hiểu chúng ở đây không chỉ dựa trên cơ sở cái hệ thống làm mà còn dựa trên việc tích hợp hệ thống là cái gì với hệ thống làm gì. Thí dụ trên hình 1.2 mô tả các đối tƣợng và các quan hệ giữa các đối tƣợng của hệ thống thang máy. Theo cách tiếp cận này thì các chức năng hệ thống đƣợc biểu diễn thông qua cộng tác của các đối tƣợng; việc thay đổi, tiến hóa chức năng sẽ không ảnh hƣởng đến cấu trúc tĩnh của phần mềm.
Sức mạnh của tiếp cận hƣớng đối tƣợng là việc tách (chia) và nhập (thống nhất) đƣợc thực hiện nhờ tập phong phú các cơ chế tích hợp của chúng; khả năng thống nhất cao những cái nó đã đƣợc tách ra để xây dựng các thực thể phức tạp từ các thực thể đơn giản. Tiếp cận hƣớng đối tƣợng đã tỏ rõ lợi thế khi lập trình các hệ thống phức tạp. Những ngƣời phát triển phần mềm nhận thấy rằng phát triển phần mềm hƣớng đối tƣợng sẽ cho lại phần mềm thƣơng mại chất lƣợng cao: tin cậy, dễ mở rộng và dễ sử dụng lại, chạy trơn tru, phù hợp với yêu cầu ngƣời dùng đang mong đợi. Chúng còn cho khả năng hoàn thành phần mềm đúng kỳ hạn và không vƣợt quá khinh phí dự kiến ban đầu.
Ngoài phƣơng pháp cấu trúc và phƣơng pháp hƣớng đối tƣợng vừa đề cập trên đây, ngƣời ta còn thấy một số phƣơng pháp khác đƣợc các nhà tin học đề xuất cho công nghệ phần mềm nhƣ tiếp cận hƣớng logic, tiếp cận hƣớng tác tử (agent)… Phƣơng pháp tiếp cận hƣớng logic mô tả quan hệ “logic” giữa tính chất và thuộc tính của các sự kiện nhờ các cơ sở lập luận và luật suy diễn biểu diễn bởi những gợi ý trƣớc. Tiếp cận này hình thành trên cơ sở ngôn ngữ lập trình Prolog. Phƣơng pháp tiếp cận tác tử là kiểu mở rộng của tiếp cận hƣớng đối tƣợng. Gần đây nó đƣợc giới công nghiệp rất quan tâm.
Các đơn vị cơ sở để phát triển hệ thống ở đây là các tác tử, nó là modun phần mềm. Đối tƣợng đƣợc khởi động khi nhận thông điệp từ bên ngoài và tác tử tích cực làm việc hay không phụ thuộc vào môi trƣờng chứa nó. Tuy nhiên, phƣơng pháp hƣớng đối tƣợng đang ngày cành đƣợc nhiều ngƣời sử dụng hơn cả. Phát triển phần mềm bằng UML trang | 9 1.1 LỊCH SỬ HƢỚNG ĐỐI TƢỢNG Khái niệm hƣớng đối tƣợng hình thành từ ngôn ngữ lập trình Simula, nhƣng nó chỉ trở nên quen thuộc khi xuất hiện ngôn ngữ C++ và SmallTalk vào cuối những năm 80 của thế kỳ XX.3 chỉ ra thời gian xuất hiện và quan hện của các ngôn ngữ lập trình [OES00].
Trong hình vuông với góc tròn là tên các ngôn ngữ lập trình hƣớng đối tƣợng.3 Các ngôn ngữ lập trình Khi các ngôn ngữ hƣớng đối tƣợng đƣợc sử dụng rộng rãi thì nhu cầu có phƣơng pháp phát triển phần mềm hƣớng đối tƣợng trở nên cấp bách. Vào đầu những năm 90 của thế kỷ XX đã xuất hiện các phƣơng pháp hƣớng đối tƣợng sau đây: Phƣơng pháp Booch, OMT (Object Modeling Technique), OOSE (Object Oriented Software Engineering)/Objectory, Fusion và Coad/Yourdon. Mỗi phƣơng pháp có ký pháp, tiến trình và công cụ hỗ trợ riêng. Chúng đều có ƣu điểm và nhƣợc điểm riêng.
Ngƣời sử dụng rất khó khăn để chọn cho mình một phƣơng pháp phù hợp. Do nhận biết đƣơc các vấn đề này, vào năm 1994 các tác giả của các phƣơng pháp này đã hợp tác nhằm Phát triển phần mềm bằng UML trang | 10 tạo ra phƣơng pháp mới. Bắt đầu là sự thống nhất phƣơng pháp Booch với OMT-2 của Rumbagh để hình thành Unified Method 0.8 tại Rational Rose Corporation. Tháng 6 năm 1995, Ivar Jacobson (tác giả của OOSE/Objectory) gia nhập với họ.
Từ thời điểm này, nhóm phát triển phƣơng pháp hƣớng đối tƣợng nói trên cho rằng nhiệm vụ của họ là tạo ra ngôn ngữ mô hình hóa thống nhất cho cộng đồng hƣớng đối tƣợng. Do vậy, họ đã đổi tên công việc của mình thành Unified Modeling Language – UML (Ngôn ngữ mô hình hóa thông nhất). Booch, Rumbaugh và Jacobson đã đƣa ra nhiều phiên bản UML, trong đó phiên bản UML 0.9 xuất hiện năm 1995, UML xuất hiện vào năm 1997. Phần lớn UML đƣợc xây dựng trên nền tảng của các phƣơng pháp Booch, OMT và OOSE, nhƣng UML còn bao gồm cả các khái niệm có nguồn gốc từ các phƣơng pháp khác nhƣ David Harel, Gamma – Helm – Johnson – Vlissides và Fusion.
UML còn là kết quả của sự đóng góp từ các hãng lớn nhƣ Digital Equipment Corporation (DEC), Hewlett – Packard (HP), I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software Corporation, Texas Instrument, Taskon, ObjectTime và Unisys. Phiên bản UML 1.1 đã đƣợc đệ trình lên OMG (Object Management tháng 11-1997. Phiên bản UML 1.3 xuất hiện vào năm 1999. Phiên bản UML 1.4 xuất hiện vào tháng 2-2000.2 MỘT SỐ KHÁI NIỆM CƠ BẢN Phần này trình bày một số khái niệm cơ bản áp dụng trong phân tích và thiết kế hƣớng đối tƣợng.
Phƣơng pháp (method). Phƣơng pháp (hay phƣơng thức) là cách thức cấu trúc các suy nghĩ và hành động của con ngƣời. Nó cho biết chúng ta phải làm cái gì, làm nhƣ thế nào, làm khi nào và tại sao phải làm nhƣ vậy để hình thành hệ thông phần mềm. Đối thƣơng (object).
Theo nghĩa thông thƣờng thì đối tƣợng là ngƣời, vật hay hiện tƣợng mà con ngƣời nhằm vào trong suy nghĩ, trong hành động [PHE96]; là bất kỳ cái gì nhìn thầy và sờ mó đƣợc. Trong phƣơng pháp hƣớng đối tƣợng thì đối tƣợng là trừu tƣợng cái gì đó trong lĩnh vực vấn đề hay trong cài đặt của nó; phản ảnh khả năng hệ thống lƣu giữ thông tin về nó và tƣơng tác với nó; gói các giá trị thuộc tính và các dịch vụ (phƣơng thức, phƣơng pháp) [OCAD91]. Theo nghĩa thông thƣờng thì lớp là nhóm của nhiều ngƣời hay vật có tính tƣơng tự nhất định hay đặc điểm chung (từ điển Webster‟s). Trong phƣơng pháp hƣớng đối tƣợng thì lớp là mô tả một hay nhiều đối tƣợng, mô tả tập thống nhất các thuộc tính và phƣơng thức.
Nó còn có thể mô tả cách tạo đối tƣợng mới trong lớp nhƣ thế nào [COAD91]. Trừu tƣợng là nguyên lý bỏ qua những khía cạnh của chủ thể (subject) không liên quan đến mục đích hiện tại để tập trung đầy đủ hơn vào các khía cạnh còn lại. Nhƣ vậy có thể nói rằng trừu tượng là đơn giản hóa thế giới thực một cách thông minh. Trừu tƣợng cho khả năng tổng quát hóa và ý tƣởng hóa vấn đề đang xem xét.
Chúng loại bỏ đi các chi tiết dƣ thừa mà chỉ tập chung và các điểm chính, cơ bản [LIBE98]. Nếu phải xây ngôi nhà thì chắc chắn không làm đơn giản là cứ mua gạch, sắt thép về lắp dần đến khi hình thành nhà ở, mà phải có kế hoạch chi tiết và thiết kế trƣớc. Nói cách khác là phải xây dựng mô hình. Tƣơng tự nhƣ vậy, trong Phát triển phần mềm bằng UML trang | 11 lĩnh vực phần mềm, mô hình là kế hoạch chi tiết của hệ thống, nó giúp ta lập kế hoạch trƣớc khi xây dựng hệ thống.