BÀI 1: GIỚI THIỆU UML UML là viết tắt của Unified Modeling Language (ngôn ngữ mô hình hóa thống nhất). Đó là một trong các công cụ nổi bật nhất trong việc phát triển hệ thống ngày nay. Tại sao vậy? UML cho phép người xây dựng hệ thống không chỉ tạo ra các bản thiết kế chứa đựng những cái nhìn/nhận thức của họ theo một cách dễ hiểu và chuẩn xác mà còn có thể truyền đạt với nhau về chúng. Nội dung chính trong bài học: + Tại sao UML là cần thiết + UML hình thành như thế nào + Các loại sơ đồ (diagram) khác nhau của UML + Tại sao cần thiết phải sử dụng nhiều loại diagram khác nhau Thuật ngữ: trong giáo trình này, hệ thống (system) được xem là sự kết hợp giữa phần mềm (software) và phần cứng (hardware) nhằm cung cấp một giải pháp cho một vấn đề. Phát triển hệ thống (system development) là việc tạo ra một hệ thống cho khách hàng, người có vấn đề cần giải quyết. Một phân tích viên (analyst) tài liệu hóa vấn đề của khách hàng và chuyển nó sang người phát triển (developer), lập trình viên (programmer) để xây dựng phần mềm giải quyết vấn đề và triển khai phần mềm trên phần cứng máy tính. UML hình thành như thế nào UML là sản phẩm trí óc của Grady Booch, James Rumbaugh và Ivar Jacobson. Trong những năm từ 80 đến 90, mỗi người trên làm việc tại những tổ chức khác nhau và phát minh phương pháp phân tích thiết kế hướng đối tượng riêng của mình. Những phương pháp của họ đạt được tính ưu việt hơn so với nhiều phương pháp khác. Đến giữa những năm 90, họ bắt đầu mượn ý tưởng của nhau và dần tiến đến hợp tác cùng nhau. Năm 1994, Rumbaugh gia nhập Rational Rose Corporation cùng với Booch và sau đó một năm thì Jacobson cũng cùng gia nhập. Phiên bản khởi đầu của UML bắt đầu được truyền bá khắp ngành công nghiệp phần mềm và đem lại những thay đổi đáng kể. Nhiều công ty phần mềm cảm thấy rằng UML đáp ứng được mục tiêu chiến lược của họ, do vậy một liên minh tạm thời được dựng lên. Các thành viên của liên minh gồm EDC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational và một số khác. Đến năm 1997, liên minh cho ra đời version 1.0 của UML và đệ trình nó lên Tổ chức quản lý đối tượng (Object Management Group – OMG) để trở thành ngôn ngữ mô hình hóa chuẩn. Liên minh tiếp tục cho ra version 1.1 và đưa nó đến OMG cuối năm 1997. Vào 1998, có thêm 2 version nữa của UML được tạo ra. UML trở thành một tiêu chuẩn trong công nghiệp phần mềm và nó không ngừng phát triển. Các thành phần của của UML UML bao gồm một số thành phần đồ họa kết hợp với nhau hình thành nên các sơ đồ (diagram). Do là một ngôn ngữ, UML có những qui tắc cho việc kết hợp các thành phần này. Việc giới thiệu cho tiết về các thành phần cũng như các qui tắc sẽ thực hiện sau, chúng ta cùng hiểu sơ qua về các diagram bởi chúng sẽ được dùng cho phân tích hệ thống. Thuật ngữ: Mục tiêu của các diagram là trình bày những cái nhìn (view) khác nhau về một hệ thống và tập hợp các view được gọi là mô hình (model). Một mô hình UML của một hệ thống. Chú ý rằng UML mô tả những cái mà một hệ thống được giả định thực hiện. Nó không cho biết cách thức thực hiện hệ thống. Sơ đồ đối tượng (Object Diagram) Thuật ngữ: Các vật được phân chia một cách tự nhiên thành các nhóm (automobile, furniture, washing machines, …). Chúng ta gọi các nhóm này là lớp (class). Một class là một nhóm các vật có cùng thuộc tính (attribute) và hành vi (behavior). Ví dụ, Bất cứ máy giặt nào thuộc lớp “washing machines” đều có các thuộc tính như tên hiệu, model, số serial, và sức chứa. Hành vi của chúng gồm “add clothes”, “add detergent”, “turn on” và “remove clothes”. Hình 1.1 Biểu tượng class của UML Tại sao cần bận tâm về các class và các thuộc tính, hành vi của chúng? Để tương tác với thế giới phức tạp của chúng ta, các phần mềm hiện nay cần mô phỏng một số khía cạnh của thế giới thực. Class diagram trợ giúp về mặt phân tích. Chúng cho phép các phân tích viên nói chuyện với khách hàng với những ngôn từ của họ và từ đó khuyến khích khách hàng trình bày các chi tiết quan trọng của vấn đề họ gặp phải. Sơ đồ đối tượng (Object diagram) Thuật ngữ: Một đối tượng (object) là một thể hiện của một class - một vật cụ thể có các giá trị cụ thể cho các thuộc tính và hành vi. Ví dụ, cái máy giặt của bạn có nhãn hiệu là “Laundatorium”, tên đời là “Washmeister”, số serial là GL57774 và sức chứa là 16 kg. Đó chính là một đối tượng. Hình 1.2 cho thấy UML biểu diễn một object. Chú ý rằng biểu tượng là một hình chữ nhật như biểu tượng class, nhưng tên gạch dưới. Tên của một thể hiện cụ thể nằm bên trái dấu :, còn tên class nằm bên phải. Hình 1.2 Biểu tượng object của UML Sơ đồ tình huống ứng dụng (Use Case Diagram) Thuật ngữ: Một tình huống ứng dụng (use case) là một mô tả về một hành vi của hệ thống từ quan điểm người dùng. Đối với người phát triển hệ thống, đây là một công cụ có giá trị: nó là một kỹ thuật thử-và-đúng (tried-and-true technique) cho việc thu thập yêu cầu hệ thống từ quan điểm người dùng. Điều đó rất quan trọng nếu mục tiêu là xây dựng một hệ thống mà con người thực có thể sử dụng. Chúng ta sẽ tìm hiểu sâu hơn về use case sau này. Bây giờ, hãy xem ví dụ hình 1.3, chúng ta dùng máy giặt rõ ràng để giặt áo quần. Hình 1.3 Sơ đồ use case của UML Thuật ngữ: Hình nhân (stick) nhỏ tượng trưng cho người dùng máy giặt được gọi là tác nhân (actor). Hình ellipse biểu diễn use case. Chú ý rằng actor–thực thể kích hoạt use case– có thể là con người hoặc một hệ thống khác. Sơ đồ trạng thái (State Diagram) Tại thời điểm nào thì một object cũng phải có một trạng thái xác định. Một người có thể là sơ sinh, đứa bé còn ẵm ngửa, trẻ em, thiếu niên hoặc trưởng thành. Một thang máy có thể đang đi lên, đi xuống hoặc đứng yên. Một máy giặt có thể đang ngâm (soak), giặt (wash), giũ (rinse), vắt (spin) hoặc không hoạt động. Sơ đồ trạng thái hình 1.4 cho thấy máy giặt dịch chuyển giữa các trạng thái. Biểu tượng tại đầu diagram là trạng thái bắt đầu (start state) còn ở cuối là trạng thái kết thúc (end state). Hình 1.4 Sơ đồ trạng thái của UML Sơ đồ trình tự (Sequence Diagram) Class diagram và object diagram biểu diễn thông tin tĩnh. Trong một hệ thống chức năng, các object luôn tương tác lẫn nhau. Sơ đồ trình tự của UML (sequence diagram) biểu diễn sự tương tác theo thời gian. Tiếp tục với ví dụ máy giặt, các thành phần của máy gồm một ống cấp nước (cấp nước sạch), một trống giặt (chứa áo quần) và một ống thoát. Chúng dĩ nhiên cũng là các object. Điều gì xảy ra khi ta kích hoạt use case “wash clothes”? Giả sử ta đã hoàn tất các hoạt động “add clothes”, “add detergent” và “turn on”, chuỗi các bước tiến hành sẽ như sau: 1. Nước vào trống thông qua ống cấp 2. Trống đứng yên trong 5 phút 3. Nước ngừng cấp 4. Trống quay ngược và xuôi trong 15 phút 5. Nước xà phòng thoát ra thông qua ống thoát 6. Nước sạch được cấp lại 7. Trống tiếp tục quay ngược và xuôi 8. Nước ngừng cấp 9. Nước vắt thoát ra thông qua ống thoát 10. Trống quay 1 chiều nhanh dần trong vòng 5 phút 11. Trống ngừng quay và việc giặt hoàn tất. Hình 1.5 biểu diển sequence diagram ghi nhận các tương tác giữa cấp nước, trống giặt và ống thoát (biểu diễn bằng các hình chữ nhật phía trên) diễn ra theo thời gian. Thời gian trong diagram trôi theo chiều từ trên xuống. Hình 1.5 Sơ đồ trình tự của UML Trở lại ý tưởng về trạng thái, chúng ta có thể phân chia các bước 1 và 2 là trạng thái ngâm, các bước 3 và 4 là trạng thái giặt, các bước 5-7 là trạng thái giũ và bước 8-10 là trạng thái vắt. Sơ đồ hoạt động (Activity Diagram) Các hoạt động xuất hiện trong một use case hoặc trong một hành vi của object thường diễn ra theo một trình tự như 11 bước ở ví dụ trên. Hình 1.6 cho thấy cách sơ đồ hoạt động UML biểu diễn các bước 4-6 của trình tự. Hình 1.6 Sơ đồ hoạt động của UML Sơ đồ cộng tác (Collaboration Diagram) Các thành phần của hệ thống làm việc với nhau để hoàn thành mục tiêu đặt ra và một ngôn ngữ mô hình hóa cần có cách biểu diễn sự hợp tác này. Sơ đồ cộng tác UML được thiết kế cho mục tiêu trên, như hình 1.7. Ví dụ này thêm bộ đếm thời gian (internal timer) trong tập class tạo nên máy giặt. Sau một khoảng thời gian nhất định, timer dừng việc cấp nước và trống giặt xoay ngược xuôi. Hình 1.7 Sơ đồ cộng tác của UML Sơ đồ thành phần (Component Diagram) Sơ đồ này và tiếp theo thoát khỏi máy giặt bởi sơ đồ thành phần (component diagram) và sơ đồ triển khai (deployment diagram) hướng biểu diễn sang các hệ thống máy tính. Việc phát triển các phần mềm ngày nay tiến hành thông qua các thành phần phù hợp với cách thức lập trình theo nhóm. Hình 1.8 Sơ đồ thành phần của UML Sơ đồ triển khai (Deployment Diagram) Sơ đồ triển khai cho biết kiến trúc vật lý của một hệ thống dựa trên máy tính. Nó vẽ nên các máy tính và thiết bị, cho thấy các kết nối giữa chúng và cho biết phần mềm trên mỗi máy. Mỗi máy tính được biểu diễn bởi một khối lập phương với các đường nối giữa các máy tính. Hình 1.9 Sơ đồ triển khai của UML Một số tính năng khác UML cung cấp một số tính năng khác cho phép tổ chức và mở rộng các diagram Gói (package) Thuật ngữ: Khi cần tổ chức các thành phần của một diagram vào trong một nhóm (group), ta đưa chúng vào trong một package, biểu diễn như hình 1.10. Hình 1.10 Gói UML cho phép nhóm các thành phần của một diagram Ghi chú (Note) Thuật ngữ: Ghi chú (note) của UML giúp tránh một thành phần nào đó trong diagram bị hiểu nhầm. Hình 1.11 Trong bất cứ diagram nào, ta cũng có thể thêm các ghi chú Mẫu (Stereotype) Thuật ngữ: Mẫu (stereotype) cho phép dùng các thành phần UML sẵn có để chế biến ra những cái mới. Thuật ngữ: Khái niệm giao diện (interface) là một ví dụ tốt cho stereotype. Một interface là một class chỉ có operation mà không có attribute. Nó chính là một tập các hành vi mà ta muốn dùng lại nhiều lần trên khắp mô hình. Thay vì nghĩ ra một thành phần mới để biểu diễn một interface, ta có thể dùng một biểu tượng class với <<interface>> gắn phía trên tên class. Hình 1.12 Một stereotype cho phép tạo một thành phần mới từ những cái sẵn có. Tại sao cần thiết phải sử dụng nhiều loại diagram khác nhau? Thuật ngữ: Một hệ thống có nhiều người quan tâm với nhiều khía cạnh khác nhau, họ được gọi là stakeholder. Việc thiết kế hệ thống liên quan đến tất cả các khía cạnh (viewpoint) có thể có. Mỗi UML diagram cho ta một cách tạo nên một cái nhìn cụ thể nhằm thỏa mãn mỗi loại stakeholder. Tóm lược Việc phát triển hệ thống là một hoạt động mang tính con người. Nếu thiếu một hệ thống ký hiệu dễ hiểu thì quá trình phát triển dễ sinh lỗi. UML là một hệ thống ký hiệu đã trở thành một chuẩn trong việc phát triển hệ thống. Nó là phát minh của Grady Booch, James Rumbaugh và Ivar Jacobson. UML bao gồm một tập các diagram để cung cấp một chuẩn cho phép các phân tích viên hệ thống xây dựng một bản thiết kế đa diện dễ hiểu đối với khách hàng, lập trình viên hay bất cứ ai liên quan đến quá trình phát triển hệ thống. Lý do cần thiết có nhiều loại diagram khác nhau vì mỗi loại dành cho một stakeholder khác nhau trong hệ thống. Câu hỏi: 1. Tại sao cần thiết phải có nhiều diagram khi mô hình hóa một hệ thống? 2. Những diagram nào cung cấp các nhìn tĩnh (static view) về hệ thống? 3. Những diagram nào cung cấp các nhìn động (dynamic view) về hệ thống (biểu diễn sự thay đổi theo thời gian)? Bài tập: 1. Giả sử bạn đang xây dựng một chương trình máy tính chơi cờ vui với người. Các sơ đồ UML nào cần thiết trong quá trình thiết kế? Vì sao? 2. Đối với hệ thống ở bài tập trên, liệt kê các câu hỏi mà bạn sẽ đặt ra với những người cần thiết và tại sao bạn lại hỏi họ. . BÀI 1: GIỚI THIỆU UML UML là viết tắt của Unified Modeling Language (ngôn ngữ mô hình. Nội dung chính trong bài học: + Tại sao UML là cần thiết + UML hình thành như thế nào + Các loại sơ đồ (diagram) khác nhau của UML + Tại sao cần thiết