Phân Tích & Thiết KếHướng Đối Tượng Sử Dụng UML

• UML quy định một loạt các ký hiệu và quy tắc để mô hình hoá các pha trong quá trình phát triển phần mềm hướng đối tượng dưới dạng các biểu đồ 5 KHOA CÔNG NGHỆ THÔNG TIN TRƯỜNG CAO Đ

Trang 1

Phân Tích & Thiết Kế Hướng Đối Tượng Sử Dụng UML

1

KHOA CÔNG NGHỆ THÔNG TIN

TRƯỜNG CAO ĐẲNG CÔNG NGHỆ THÔNG TIN

Kỷ luật - Chất lượng – Sáng tạo

UML VÀ CÔNG CỤ PHÁT TRIỂN HỆ

THỐNG

• Giới thiệu UML

• Các biểu đồ trong UML

• Các bước phân tích thiết kế hướng đối

tượng sử dụng UML

Trang 2

GIỚI THIỆU VỀ UML

• Các ngôn ngữ hướng đối tượng ra đời

khá sớm, ví dụ như Simula-67 (năm

1967), Smalltalk (đầu những năm 1980),

C++, CLOS (giữa những năm 1980):thì

những phương pháp luận cho phát triển

hướng đối tượng lại ra đời khá muộn

• Năm 1997: tập đoàn Rational xây dựng

bản 1.0 của UML, Phần mềm Rational

Rose

3

UML – Ngôn ngữ mô hình hoá hướng

đối tượng

• UML (Unified Modelling Language) là ngôn ngữ mô

hình hoá tổng quát được xây dựng để đặc tả, phát

triển và viết tài liệu cho các khía cạnh trong phát triển

phần mềm hướng đối tượng UML giúp người phát

triển hiểu rõ và ra quyết định liên quan đến phần

mềm cần xây dựng UML bao gồm một tập các khái

niệm, các ký hiệu, các biểu đồ và hướng dẫn.

• UML hỗ trợ xây dựng hệ thống hướng đối tượng dựa

trên việc nắm bắt khía cạnh cấu trúc tĩnh và các

hành vi động của hệ thống.

– Các cấu trúc tĩnh định nghĩa các kiểu đối tượng quan

trọng của hệ thống, nhằm cài đặt và chỉ ra mối quan hệ

giữa các đối tượng đó.

– Các hành vi động (dynamic behavior) định nghĩa các

hoạt động của các đối tượng theo thời gian và tương tác

giữa các đối tượng hướng tới đích.

4

Trang 3

UML – Ngôn ngữ mô hình hoá hướng

đối tượng

• Các mục đích của ngôn ngữ mô hình hoá thống

nhất UML:

– Mô hình hoá các hệ thống sử dụng các khái niệm

hướng đối tượng.

– Thiết lập sự liên hệ từ nhận thức của con người đến

các sự kiện cần mô hình hoá.

– Giải quyết vấn đề về mức độ thừa kế trong các hệ

thống phức tạp với nhiều ràng buộc khác nhau.

– Tạo một ngôn ngữ mô hình hoá có thể sử dụng

được bởi người và máy.

• UML quy định một loạt các ký hiệu và quy tắc để

mô hình hoá các pha trong quá trình phát triển

phần mềm hướng đối tượng dưới dạng các biểu

đồ

5

Các khái niệm cơ bản trong UML

• Khái niệm mô hình

– Mô hình là một biểu diễn của sự vật hay một tập các sự vật

trong một lĩnh vực áp dụng nào đó theo một cách khác Mô

hình nhằm nắm bắt các khía cạnh quan trọng của sự vật, bỏ

qua các khía cạnh không quan trọng và biểu diễn theo một tập

ký hiệu và quy tắc nào đó Các mô hình thường được xây

dựng sao cho có thể vẽ được thành các biểu đồ dựa trên tập

ký hiệu và quy tắc đã cho

• Khi xây dựng các hệ thống, mô hình được sử dụng nhằm

thoả mãn các mục đích sau:

– Nắm bắt chính xác yêu cầu và tri thức miền mà hệ thống cần

phát triển

– Thể hịên tư duy về thiết kế hệ thống

– Trợ giúp ra quyết định thiết kế dựa trên việc phân tích yêu cầu

– Tổ chức, tìm kiếm, lọc, kiểm tra và sửa đổi thông tin về các hệ

thống lớn

– Làm chủ được các hệ thống phức tạp

Trang 4

• Khái quát

– Phân tích và thiết kế hướng đối tượng (Object Oriented

Analysis and Design: OOAD)

• Mô tả hệ thống gồm những đối tượng sống trong đó và sự

tương tác của chúng với nhau

– UML (Unified Modeling Language)

• UML là ngôn ngữ mô hình hóa hợp nhất dùng để biểu diễn hệ

thống Nói một cách đơn giản là nó dùng để tạo ra các bản vẽ

nhằm mô tả thiết kế hệ thống Các bản vẽ này được sử dụng

để các nhóm thiết kế trao đổi với nhau cũng như dùng để thi

công hệ thống (phát triển), thuyết phục khách hàng, các nhà

đầu tư v.v

– Tại sao lại là OOAD và UML?

• OOAD cần các bản vẽ để mô tả hệ thống được thiết kế, còn

UML là ngôn ngữ mô tả các bản vẽ nên cần nội dung thể hiện

Do vậy, chúng ta phân tích và thiết kế theo hướng đối tượng

và sử dụng UML để biểu diễn các thiết kế đó nên chúng

thường đi đôi với nhau

7

Operations

ComponentPackage

Trang 5

• Hướng nhìn (view): Là tập con các biểu đồ UML

được xây dựng để biểu diễn một khía cạnh nào

Khía cạnh động

State machine view State diagram Trạng thái, sự kiện,:

Activity view Activity diagam Trạng thái, sự kiện,:

Interaction view

Sequence diagram Tương tác, thông điệp, Collaboration diagram Cộng tác, thông điệp,

9

• Hướng nhìn (view) :

Trang 6

• Hướng nhìn (view):

– Use Case View: cung cấp góc nhìn về các ca sử dụng giúp

chúng ta hiểu hệ thống có gì? ai dùng và dùng nó như thế

nào

– Logical View: cung cấp góc nhìn về cấu trúc hệ thống, xem

nó được tổ chức như thế nào Bên trong nó có gì

– Process View: cung cấp góc nhìn động về hệ thống, xem

các thành phần trong hệ thống tương tác với nhau như thế

nào

– Component View: Cũng là một góc nhìn về cấu trúc giúp

chúng ta hiểu cách phân bổ và sử dụng lại các thành phần

trong hệ thống ra sao

– Deployment View: cung cấp góc nhìn về triển khai hệ thống,

nó cũng ảnh hưởng lớn đến kiến trúc hệ thống

– Tập hợp các góc nhìn này sẽ giúp chúng ta hiểu rõ hệ

thống cần phân tích, thiết kế Góc nhìn Use Case View nằm

ở giữa và chi phối tất cả các góc nhìn còn lại

11

• Các loại sơ đồ trong UML

12

Trang 7

• Diagrams:

– Use Case Diagram:

• bản vẽ mô tả về ca sử dụng của hệ thống Bản vẽ này sẽ giúp chúng ta biết

được ai sử dụng hệ thống, hệ thống có những chức năng gì Lập được bản vẽ

này bạn sẽ hiểu được yêu cầu của hệ thống cần xây dựng.

– Class Diagram:

• bản vẽ này mô tả cấu trúc của hệ thống, tức hệ thống được cấu tạo từ những

thành phần nào Nó mô tả khía cạnh tĩnh của hệ thống.

– Object Diagram:

• Tương tự như Class Diagram nhưng nó mô tả đến đối tượng thay vì lớp

(Class).

– Sequence Diagarm:

• là bản vẽ mô tả sự tương tác của các đối tượng trong hệ thống với nhau được

mô tả tuần tự các bước tương tác theo thời gian.

13

• Diagrams:

– Collaboration Diagram:

• tương tự như sequence Diagram nhưng nhấn mạnh về sự tương tác thay vì

tuần tự theo thời gian.

– State Diagram:

• bản vẽ mô tả sự thay đổi trạng thái của một đối tượng Nó được dùng để theo

dõi các đối tượng có trạng thái thay đổi nhiều trong hệ thống.

Trang 8

• Các loại sơ đồ trong UML

15

Object diagram

Sơ đồ cấu trúc phức

Composite structure diagram

Sơ đồ đóng gói

Package diagram

Sơ đồ triển khai

Trang 9

Biểu đồ tương tác dạng cộng tác

Biểu đồ trạng thái

Biểu đồ

use case

17

• Sơ đồ lớp (class diagram)

– Chỉ ra các lớp đối tượng

trong hệ thống

– Các thuộc tính và phương

thức của từng lớp

– Mối quan hệ giữa các lớp

• Sơ đồ đối tượng (object

– Một sơ đồ đối tượng vì

vậy là một ví dụ của sơ

đồ lớp, chỉ ra một bức

tranh mà hệ thống có

thể có tại một thời điểm

nào đó

Trang 10

• Sơ đồ cấu trúc phức (Composite structure diagram)

– Chỉ ra cấu trúc nội tại của một lớp

– Các cộng tác có thể có

19

• Sơ đồ đóng gói (Package diagram)

– Là cách tổ chức các phần tử mô hình hóa vào một nhóm

– Có thể áp dụng cho bất kỳ loại sơ đồ UML nào

– Thường dùng để đóng gói cho sơ đồ lớp và sơ đồ use case

20

Trang 11

Use case diagram

• Mục đích

– Trường hợp sử dụng là một kỹ thuật mô tả hệ

thống dựa trên quan điểm người sử dụng Mỗi

trường hợp sử dụng là một cách thức riêng biệt

để sử dụng hệ thống.

– Những chức năng mà hệ thống cung cấp sẽ

được mô tả trong sơ đồ hoạt vụ.

– Là sưu liệu cho việc kiểm thử hệ thống

– Việc mô tả bao gồm

• Mô tả các chức năng (các trường hợp sử dụng – use

case)

• Các tác nhân bên ngoài (actor)

• Mối quan hệ giữa tác nhân và các trường hợp sử

dụng

21

• Mục đích

– Sơ đồ hoạt vụ phục vụ cho mục đích

• Trao đổi thông tin giữa

– Khách hàng – người sử dụng hệ thống trong tương lai– Những người phát triển hệ thống

• Biến đổi yêu cầu về mặt nghiệp vụ của khách

hàng thành yêu cầu cụ thể mà lập trình viên có

thể nắm bắt.

• Là phương tiện đối sánh yêu cầu về mặt nghiệp

vụ và các lớp cũng như phương thức của hệ

thống

Trang 12

• Trường hợp sử dụng và yêu cầu NSD

– Yêu cầu người dùng là cái mà hệ thống phải

làm Trường hợp sử dụng là thao tác người

dùng sẽ thực hiện và kết quả mà hệ thống sẽ

sinh ra.

– Trường hợp sử dụng đôi khi lại là phương tiện

khơi gợi nên yêu cầu của người dùng.

– Yêu cầu người dùng đôi khi có tác dụng sưu

liệu như là trường hợp sử dụng

• Người dùng dễ dàng kiểm thử các yêu cầu chức

năng

• Cấu trúc tài liệu hướng dẫn sử dụng

• Công cụ giúp phát hiện các lớp

23

• Trường hợp sử dụng và yêu cầu NSD

– Yêu cầu người dùng là cái mà hệ thống phải làm

Trường hợp sử dụng là thao tác người dùng sẽ thực

hiện và kết quả mà hệ thống sẽ sinh ra.

– Trường hợp sử dụng đôi khi lại là phương tiện khơi

gợi nên yêu cầu của người dùng.

– Yêu cầu người dùng đôi khi có tác dụng sưu liệu

như là trường hợp sử dụng

• Người dùng dễ dàng kiểm thử các yêu cầu chức năng

• Cấu trúc tài liệu hướng dẫn sử dụng

• Công cụ giúp phát hiện các lớp

– Trường hợp sử dụng vì thế được xem là một thành

phần của đặc tả yêu cầu người dùng

24

Trang 13

• Một sơ đồ hoạt vụ mô tả

Trang 14

• Tác nhân

– Không phải là thành phần của hệ thống

– Là người hay hệ thống khác tương tác với hệ thống

– Tương tác

• Nhận thông tin từ hệ thống

• Gửi thông tin cho hệ thống

• Nhận và gửi thông tin với hệ thống

– Một tác nhân là một dạng thực thể (một lớp), chứ không

phải một thực thể Tác nhân mô tả và đại diện cho một vai

trò, chứ không phải là một người sử dụng thật sự và cụ thể

của hệ thống

• Một người dùng cụ thể có thể đóng nhiều vai trò

27

Trang 15

• Hệ thống

– Là một thành phần của sơ đồ hoạt vụ trong đó ranh giới của hệ

thống phát triển cần phải định nghĩa rõ

– Hệ thống không nhất thiết là phần mềm, có thể là một thiết bị, một

tổ chức nào đó

– Việc định nghĩa ranh giới, phạm vi của hệ thống không là

công việc đơn giản

• Tác vụ nào tự động, tác vụ nào thực hiện thủ công

• Tác vụ nào do hệ thống khác thực hiện

Tên hệ thống

29

• Các mối quan hệ

– Relationship hay còn gọi là conntector được sử dụng

để kết nối giữa các đối tượng với nhau tạo nên bản vẽ

Use Case Có các kiểu quan hệ cơ bản sau:

• Association

• Generalization

• Include

• Extend

Trang 16

• Các mối quan hệ

– Relationship hay còn gọi là conntector được sử dụng

để kết nối giữa các đối tượng với nhau tạo nên bản vẽ

Use Case Có các kiểu quan hệ cơ bản sau:

• Association (kết hợp):

– thường được dùng để mô tả mối quan hệ giữa

Actor và Use Case và giữa các Use Case với

nhau

32

Trang 17

• Generalization (Khái quát – tổng quát hóa):

– thường được sử dụng để thể hiện quan hệ

thừa kế giữa các Actor hoặc giữa các Use

Case với nhau

33

• Include (bao gồm):

– là quan hệ giữa các Use Case với nhau, nó

mô tả việc một Use Case lớn được chia ra

thành các Use Case nhỏ để dễ cài đặt

(module hóa) hoặc thể hiện sự dùng lại

Trang 18

• Include (bao gồm):

– là quan hệ giữa các Use Case với nhau, nó mô tả việc một

Use Case lớn được chia ra thành các Use Case nhỏ để dễ cài

đặt (module hóa) hoặc thể hiện sự dùng lại

– Use Case “Verify Password” có thể gộp chung vào Use Case

Login nhưng ở đây tách ra để cho các Use Case khác sử dụng

hoặc để module hóa cho dễ hiểu, dễ cài đặt

35

• Extend (Mở rộng):

– mô tả quan hệ giữa 2 Use Case Quan hệ Extend được sử dụng khi

có một Use Case được tạo ra để bổ sung chức năng cho một Use

Case có sẵn và được sử dụng trong một điều kiện nhất định nào đó

“Open Account” là Use Case cơ sở để

cho khách hàng mở tài khoản Tuy

nhiên, có thêm một điều kiện là nếu

khách hàng là công ty thì có thể thêm

người sở hữu lên tài khoản này Add

Account Holder là chức năng mở rộng

của Use Case “Open Account” cho

trường hợp cụ thể nếu Actor là Công ty

nên quan hệ của nó là quan hệ Extend

36

Trang 19

• Quan hệ giữa các tác nhân

– Giữa các tác nhân chỉ tồn tại

duy nhất một quan hệ - quan

hệ tổng quát hóa.

– Một tác nhân A là một sự

tổng quát hóa của B nếu A có

thể được thay thế bởi B trong

• Các bước xây dựng Use Case Diagram

– Bước 1: Tìm các Actor

• Trả lời các câu hỏi sau để xác định Actor cho hệ thống:

– Ai sử dụng hệ thống này?

– Hệ thống nào tương tác với hệ thống này?

• Xem xét ví dụ về ATM ở trên chúng ta thấy:

– Ai sử dụng hệ thống? -> Customer, ATM Technician – Hệ thống nào tương tác với hệ thống này? -> Bank – Như vậy có 03 Actor: Customer, ATM Technician và Bank

– Bước 2: Tìm các Use Case

• Trả lời câu hỏi các Actor sử dụng chức năng gì trong hệ thống?

• Xem xét ví dụ ở trên ta thấy:

– Customer sử dụng các chức năng: Check Balance, Deposit, Withdraw và Transfer

– ATM technician sử dụng: Maintenance và Repair – Bank tương tác với tất cả các chức năng trên.

– Bước 3: Xác định các quan hệ

• Phân tích và các định các quan loại hệ giữa các Actor và Use Case,

giữa các Actor với nhau, giữa các Use Case với nhau sau đó nối

chúng lại chúng ta sẽ được bản vẽ Use Case.

Trang 20

• Tìm tác nhân

– Đối với một vấn đề cụ thể nào đó thì ai là người quan tâm?

– Ai sẽ cần sự hỗ trợ của hệ thống để thực hiện những tác vụ

hàng ngày của họ?

– Ai là người sử dụng thông tin của hệ thống?

– Ai là người cung cấp thông tin cho hệ thống?

– Ai là người quản trị, bảo trì, giữ cho hệ thống luôn hoạt

• Tìm trường hợp sử dụng

– Với mỗi một tác nhân đã tìm thấy ở bước trước, cần

xác định:

• Những chức năng tác nhân cần hệ thống cung cấp?

• Tác nhân có cần phải đọc, phải tạo, phải hủy bỏ, phải sửa

chữa, hay là lưu trữ một loại thông tin nào đó trong hệ

thống?

• Tác nhân có cần phải báo cho hệ thống biết về những sự

kiện nào đó? Những sự kiện như thế sẽ đại diện cho

những chức năng nào?

• Công việc hàng ngày của tác nhân có thể được đơn giản

hóa hoặc hữu hiệu hóa qua các chức năng mới cung cấp

bởi hệ thống (thường đây là những chức năng tiêu biểu

chưa được tự động hóa trong hệ thống)?

40

Định dạng
Số trang	29
Dung lượng	2,39 MB