Tài liệu BÀI 1: GIỚI THIỆU UML ppt

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

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ọ