Giáo trình phân tích hệ thống hướng đối tượng pptx

Các từ khóa Đề nghị cung cấp 10 từ khóa để tra cứu: trường hợp sử dụng, lớp, đối tượng, thuộc tính, phương thức, liên kết, bản số, tương tác, sơ đồ tuần tự, thông báo, Yêu cầu kiến thức

TRƯỜNG ĐẠI HỌC CẦN THƠ KHOA CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

THÔNG TIN VỀ TÁC GIẢ PHẠM VI VÀ ĐỐI TƯỢNG SỬ DỤNG

CỦA GIÁO TRÌNH

1 THÔNG TIN VỀ TÁC GIẢ

Họ và tên: Phạm Thị Xuân Lộc Sinh năm: 1961

Cơ quan công tác:

Bộ môn: Hệ thống thông tin- Toán ứng dụng Khoa: Công nghệ thông tin- Truyền thông Trường: Đại học Cần thơ

Địa chỉ Email để liên hệ: ptxloc@cit.ctu.edu.vn

2 PHẠM VI VÀ ĐỐI TƯỢNG SỬ DỤNG

Giáo trình có thể dùng tham khảo cho những ngành nào: Tin học

Có thể dùng cho các trường nào: các trường có đào tạo chuyên ngành Hệ thống thông tin Các từ khóa (Đề nghị cung cấp 10 từ khóa để tra cứu): trường hợp sử dụng, lớp, đối tượng, thuộc tính, phương thức, liên kết, bản số, tương tác, sơ đồ tuần tự, thông báo,

Yêu cầu kiến thức trước khi học môn này: Cơ sở dữ liệu, Lập trình hướng đối tượng

Đã xuất bản in chưa, nếu có thì Nhà xuất bản nào: chưa

Phân tích hệ thống

hướng đối tượng

Tài liệu tham khảo

Thiery-Mieg, NXB Pearson Education France, 2005.

de cas et exercices corrigés

của Pascal Roques, XB lần 2, NXB Eyrolles, 2001

của Đặng Văn Đức, NXB Giáo dục, 2002

lần 2, NXB Eyrolles, 2004

2002

UML

9 The object-oriented development

process

của Tom Rowlett, NXB Prentice Hall PTR, 2001

10 A introducton to object-oriented

analysis- Objects in plain English

của David Willia Brown, NXB John Wileys

& Sons, 2002

11 Objects¸ components and

frameworks with UML

của Desmond Francis D’Souza, Alan Cameron Wills, NXB Addison – Wesley, 1999

12 Software reuse- Domain analysis

and design process

của Jag Sodhi, Prince Sodhi, NXB Hill, 1999

McGraw-13 La démarche objet- Concepts et

outils

của Max Bouché, NXB Afnor, 1994

14 Object models- strategies, patterns

& applications

của Peter Coad, NXB Prentice-Hall, 1997

15 Modern system analysis & design của Jeffrey Hoffer, Joey F.George, Joseph S

Valacich, NXB Prentice-Hall, 2002

I.1 Phân tích hệ thống

hướng đối tượng

• Cách tiếp cận hướng đối tượng là tất yếu, để phát triển các hệ thống phần mềm:

– phức tạp,

– theo kịp đà phát triển không ngừng của công

nghệ và các nhu cầu ứng dụng trong thực tế.

I.1 Phân tích hệ thống hướng đối tượng (2)

• Tuy nhiên, lập trình hướng đối

tượng lại ít trực quan, ít tự nhiên hơn lập trình theo chức năng.

⇒ Đòi hỏi phải mô hình hóa hướng đối tượng trước thật tốt.

I.1 Phân tích hệ thống hướng đối tượng (3)

ƒ Giúp hiểu tốt hơn thực tế và so

sánh tốt hơn các giải pháp thiết kế trước khi lập trình.

ƒ Dựa trên các ngôn ngữ mô hình

hóa.

I.2 UML

• UML (Unified Modeling Language) là một

ngôn ngữ để mô hình hóa với các ký hiệu sinh động,

I.2 UML (2)

• Từ năm 1993, được hình thành từ sự hợp nhất các phương pháp:

– Booch của Grady Booch ở Rational Software

Corporation,

– OMT (Object Modeling Technology) của

James Rumbaugh,

– OOSE (Object Oriented Software

Engineering) của Ivar Jacobson.

I.2 UML (3)

• Khởi đầu từ tên Unified Method

• Đổi tên thành UML từ 1996

• Được chuyển cho OMG (Object

Management Group) từ 1997, với version 1.1 được phát hành như một chuẩn

• Hiện đang ở version 2.0 với nhiều cải tiến

về mô hình hóa hành xử, về liên quan giữa các mô hình về cấu trúc và hành xử.

I.3 Các loại sơ đồ trong UML 2.0

Object diagram

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

Composite structure diagram

Sơ đồ đóng gói

Package diagram

Sơ đồ triển khai

Deployment diagram

Sơ đồ thành tố

Component diagram

Sơ đồ về

Hành xử

Behavior diagrams

Sơ đồ hoạt vụ

Use case diagram

Sơ đồ hoạt động

Activity diagram

Sơ đồ trạng thái

State diagram

Sơ đồ về tuơng tác Interaction diagrams

Sơ đồ tổng thể về tương tác

Interaction overview

diagram

Sơ đồ tuần tự

Sequence diagram

Sơ đồ truyền thông

Communication diagram

Sơ đồ thời gian

Timing diagram

Chương II: Sơ đồ hoạt vụ

(use case diagram)

Chương II: Sơ đồ hoạt vụ 1

II.1 MỤC ĐÍCH CỦA TRƯỜNG HỢP SỬ DỤNG: 2

II.2 ĐỊNH NGHĨA VÀ KÝ HIỆU: 2

II.2.1 Định nghĩa: 2

II.2.2 Ký hiệu: 2

II.3 MÔ TẢ SƠ ĐỒ HOẠT VỤ: 3

II.3.1 Các quan điểm mô tả sơ đồ hoạt vụ: 3

II.3.2 Quan hệ giữa các trường hợp sử dụng trong một sơ đồ hoạt vụ: 3

II.4 QUAN HỆ GIỮA CÁC TÁC NHÂN: 5

II.5 MỘT VÀI NGUYÊN TẮC MÔ TẢ SƠ ĐỒ HOẠT VỤ: 6

II.5.1 Xác định các tác nhân: 6

II.5.2 Gom lại các trường hợp sử dụng: 6

II.6 MÔ TẢ BẰNG VĂN BẢN CÁC TRƯỜNG HỢP SỬ DỤNG: 7

II.6.1 Đinh danh: 7

II.6.2 Chuỗi hành vi: 7

II.6.3 Các mục bổ sung tùy ý : 7

II.7 ĐÓNG GÓI CÁC TRƯỜNG HỢP SỬ DỤNG: 9

II.7.1 Ngữ cảnh: 9

II.7.2 Đinh nghĩa: 10

II.1 MỤC ĐÍCH CỦA TRƯỜNG HỢP SỬ DỤNG:

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

Trường hợp sử dụng là một tập hợp bao gồm các thao tác được kích họat bởi một tác

nhân bên ngoài và tạo ra một kết quả xác định được (identifiable), quan sát được (observable)

Việc nhóm lại các thao tác này không tương ứng với các cấu trúc đã cài đặt sẵn hoặc để

cài đặt trực tiếp, ngắn hạn trước mắt Nó tương ứng sát hơn với một chuỗi thao tác như một logic

cảm nhận được từ người sử dụng

II.2 ĐỊNH NGHĨA VÀ KÝ HIỆU:

II.2.1 Định nghĩa:

Các trường hợp sử dụng được gom lại trong các sơ đồ họat vụ, nhằm chỉ ra mối liên hệ

giữa các trường hợp sử dụng và các tác nhân Những sơ đồ này cũng cho phép biểu diễn sự phụ

thuộc:

- giữa các trường hợp sử dụng lẫn nhau

- giữa các tác nhân lẫn nhau

không phải là người)

<<actor>>

Trường hợp sử dụng

(tác nhân kích hoạt trường hợp sử dụng)

Quan hệ giữa các trường hợp sử dụng

Đường biên hệ thống (tùy ý)

II.3 MÔ TẢ SƠ ĐỒ HOẠT VỤ:

II.3.1 Các quan điểm mô tả sơ đồ hoạt vụ:

Mỗi trường hợp sử dụng được mô tả bằng một định nghĩa tổng quát và bằng một kịch bản (script) với các định nghĩa được minh họa cụ thể Một trường hợp sử dụng có thể có mặt trong nhiều sơ đồ hoạt vụ

Có 2 quan điểm biểu diễn mô tả sơ đồ họat vụ:

a Thực hiện một sơ đồ họat vụ cho một tác nhân

b Thực hiện một sơ đồ họat vụ cho nhiều tác nhân, trong đó có một tác nhân chính kích hoạt sơ đồ hoạt vụ và các tác nhân phụ có tham gia vào các trường hợp sử dụng trong

sơ đồ hoạt vụ

II.3.2 Quan hệ giữa các trường hợp sử dụng trong một sơ đồ hoạt vụ:

II.3.2.1 Quan hệ “bao hàm” (inclusion):

Trường hợp sử dụng B được coi là “bao hàm” trường hợp sử dụng A nếu hành vi mô tả B bao hàm hành vi mô tả A

Ta nói B phụ thuôc vào A

II.3.2.2 Quan hệ “mở rộng” (extension):

Nếu hành vi của trường hợp sử dụng B có thể được mở rộng bởi hành vi của trường hợp

Hoặc

extends

BA

Ví dụ :

mở rộng

Nhận giấy báo cước

Thanh toán cước

II.3.2.3 Quan hệ “tổng quát hóa” (generalization):

Một trường hợp sử dụng A là một sự tổng quát hóa trường hợp sử dụng B nếu B là một trường hợp đặc biệt của A

Mối quan hệ « tổng quát hóa sẽ được diễn dịch thành khái niệm « thừa kế» trong các ngôn ngữ hướng đối tượng

Ký hiệu : biểu diễn bằng mũi tên khối rỗng về trường hợp sử dụng tổng quát hơn

Ví dụ :

Thanh toán bằng tiền

mặt Thanh toán bằng thẻ

Thanh toán

II.4 QUAN HỆ GIỮA CÁC TÁC NHÂN:

Mối quan hệ duy nhất có thể có giữa các tác nhân là sự 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 mọi trường hợp sử dụng (chiều ngược lại không đúng)

nap tien cho the

chon thuc an << include >>

chon thuc an theo yeu cau

<< extends >>

chon trong luong yc

<< extends >>

chon gia yeu cau

chon thuc an dong goi san

- Ngoài ra, tác nhân có thể là :

+ Các thiết bị ngoại vi sử dụng bởi hệ thống (máy in, robot, …)

+ Các phần mềm đã sẵn sàng để được tích hợp vào hệ thống

+ Các hệ thống tin học nằm ngoài nhưng có tương tác với hệ thống đang xét

Để dễ tìm các tác nhân, nên hình dung ra trước các biến của hệ thống Tất cả những ai, những gì sử dụng HT và có tương tác với HT là một tác nhân

Một trường hợp sử dụng luôn có ít nhất:

- 1 tác nhân chính kích hoạt trường hợp sử dụng bằng yêu cầu của mình và HT sẽ sinh

ra một kết quả quan sát được cho tác nhân đó

- và thường có các tác nhân phụ khác

II.5.2 Gom lại các trường hợp sử dụng:

- Không có nguyên tắc duy nhất

- Cần đứng trên quan điểm người sử dụng và xác định:

+ tác nhân đó được HT phục vụ thế nào

+ trong trường hợp nào tác nhân đó sử dụng HT

+ chức năng nào của HT mà tác nhân đó truy cập đến

- Cần tránh sự dư thừa, và cần có trừu tượng hóa hợp lý để giam bớt số trường hợp, ví

dụ không nên cho 1 trường hợp sử dụng chỉ có 1 thao tác

II.6 MÔ TẢ BẰNG VĂN BẢN CÁC TRƯỜNG HỢP SỬ DỤNG:

Gồm có 3 phần: định danh, mô tả chuỗi hành vi và các mục bổ sung tùy ý:

II.6.1 Đinh danh:

II.6.2 Chuỗi hành vi:

- mô tả tổng quát chuỗi

- điều kiện đầu (pre-cond)

- chuỗi liên kết các thông báo (messages)

- điều kiện cuối (post-cond)

- xử lý các ngoại lệ

II.6.3 Các mục bổ sung tùy ý :

II.6.3.1 Ràng buộc phi chức năng :

- tính tin cậy (confidentiality)

II.6.3.2 Ràng buộc về giao diện người-máy :

Màu sắc, vị trí các mục, theo qui định của ngành dọc (ngành tài chính, ngân hàng…)

Ví dụ 1: use case « Đăng nhập”:

Định danh:

- Tên: Đăng nhập

- Mục tiêu (tóm tắt): Use case này mô tả cách một người dùng đăng nhập vào Hệ thống

đăng ký học phần

- Tác nhân chính: Sinh viên

- Ngày tạo và ngày cập nhật mới nhất: 26/1/08

- Người tạo: Nhóm 10- HK 2 2007-2008

- Phiên bản (version): 3

Chuỗi hành vi:

- Mô tả tổng quát chuỗi: Use case này bắt đầu khi một actor muốn đăng nhập vào Hệ

thống đăng ký học phần

- Điều kiện đầu (pre-cond) : không có

- Chuỗi liên kết các thông báo (messages) :

1 Hệ thống yêu cầu actor nhập tên và mật khẩu

2 Actor nhập tên và mật khẩu

3 Hệ thống kiểm chứng tên và mật khẩu được nhập và cho phép actor đăng nhập vào hệ thống

- Điều kiện cuối (post-cond) : Nếu use case thành công, actor lúc này đã đăng nhập vào

hệ thống Nếu không trạng thái hệ thống không thay đổi

- Xử lý ngoại lệ:

Nếu actor nhập sai tên hoặc mật khẩu, hệ thống sẽ hiển thị một thông báo lỗi Actor có thể chọn trở về đăng nhập lại hoặc hủy bỏ việc đăng nhập, lúc này use case kết thúc

Nếu actor nhập sai :

+ Username : sẽ hiển thị thông báo không tồn tại username

+ Password : sẽ hiển thị thông báo yêu cầu nhập đúng mật khẩu

Ví dụ 2: use case « Quản lý số lượng hàng tồn kho 1 ngành hàng”:

a Định danh:

- Tên: Quản lý số lượng hàng tồn kho 1 ngành hàng

- Mục tiêu (tóm tắt): Tránh thất thoát, giải phóng hàng tồn

- Các tác nhân (chính + phụ): Nhân viên quản lý kho (phụ), Nhân viên quản lý ngành

hàng (chính)

- Ngày tạo và ngày cập nhật mới nhất: 21/11/2008

- Người tạo: Nhóm 5: Hồ Bửu Thiện, Nguyễn Phương Bình, Trần Duy Phương, lớp

Tin học Cần thơ 2004

- Phiên bản (version): 1.0

b Chuỗi hành vi:

- Mô tả tổng quát chuỗi: kiểm tra số lượng xuất hàng, nhập hàng

- Điều kiện đầu (pre-cond) : có bảng thống kê hàng tồn của định kỳ trước, phiếu nhập,

phiếu xuất, danh sách hàng thất thoát do hư hao (tất cả lưu trên cơ sở dữ liệu), danh mục ngành hàng

- Chuỗi liên kết các thông báo (messages) :

+ Hệ thống hiển thị danh mục ngành hàng

+ Nhân viên quản lý kho chọn ngành hàng (mã) + Nhân viên quản lý kho ghi ngày, giờ kiểm tra hàng tồn theo định kỳ + Nhân viên quản lý kho truy xuất mã ngành hàng, mặt hàng để kiểm tra theo từng mặt hàng

+ Hệ thống (hoặc do phương thức của một lớp) tính số lượng tồn cuối cho từng mặt hàng từ bảng thống kê hàng tồn của định kỳ trước, phiếu nhập, phiếu xuất, danh sách hàng thất thoát do hư hao, và lưu kết quả bảng vào cơ sở dữ liệu Công thức tinh:

TỒN CUỐI=TỒN ĐẦU+ NHẬP - XUẤT + Nhân viên quản lý kho kiểm tra số lượng hiện tại trong kho

+ Nhân viên quản lý kho đối chiếu số lượng hàng tồn trên thực tế và số liệu tồn cuối tính được

+ Nhân viên quản lý kho nhập số lượng hàng tồn trên thực tế, số lượng chênh lệch, lưu vào CSDL và in ra

+ Nhân viên quản lý kho in bảng thống kê số lượng hàng tồn theo định kỳ

- Điều kiện cuối (post-cond) : Lưu vào cơ sở dữ liệu và in ra:

o bảng thống kê số lượng hàng tồn của từng mặt hàng,

o bảng thống kê số lượng chênh lệch của từng mặt hàng

o Nếu số lượng xuất lớn hơn số lượng nhập thì yêu cầu nhập lại

o Nếu số lượng âm thì yêu cầu nhập lại

c Các mục bổ sung tùy ý :

ƒ Ràng buộc phi chức năng(non-functional constraints) :

- Tính tin cậy (confidentiality): chính xác theo phiếu nhập và phiếu xuất

- Tính bảo mật (security): Nhân viên quản lý kho, nhân viên quản lý ngành hàng, ban giám đốc

- Tính sẵn sàng (disponiblity): giờ đóng cửa siêu thị, hoặc khi có yêu cầu từ lãnh đạo

- Tính cạnh tranh (concurrence) : không cho phép nhiều người cùng kiểm tra 1 kho

- Thời gian đáp ứng (response time):

o tính số lượng tồn cuối: <=1’

o tính số liệu chênh lệch: 6 giờ

II.7 ĐÓNG GÓI CÁC TRƯỜNG HỢP SỬ DỤNG:

- Tác nhân: Thủ kho, Kế toán, Thu ngân, …

- Lĩnh vực chức năng: Quản lý kho, Quản lý nhân sự, …

- Đối tượng cần quản lý (thường nhập chung với cách phân chia gói theo lĩnh vực chưc năng): Hàng, Nhân viên, Cửa hàng

- Vị trí địa lý: Đồng bằng sông Cửu long, Nam Trung bộ, …

- Thời gian thực hiện: Thu mua, Nhập kho, Trưng bày, Bán hàng, Giao hàng, Bảo hành, …

- Quyền truy xuất: Chỉ đọc, Chỉ thêm, …

Một sơ đồ hoạt vụ có thể có chứa nhiều gói và một gói có thể được chứa trong gói khác

Ví dụ: A::B (gói A chứa gói B)

A::B::C (gói A chứa gói B, gói B chứa class C)

II.7.2 Đinh nghĩa:

Một gói cho phép tổ chức các thành phần để mô hình hóa thành nhóm Một gói có thể chứa các lớp, các trường hợp sử dụng, các giao diện …

Chương III: Sơ đồ lớp

Chương III: Sơ đồ lớp 1 III.1 MỤC ĐÍCH CỦA SƠ ĐỒ LỚP : 2 III.2 LỚP vÀ CÁC KHÁI NIỆM LIÊN QUAN: 2 III.2.1 Lớp: 2 III.2.2 Phương thức trừu tượng và lớp trừu tượng: 3 III.2.3 Sự bao gói (encapsulation) và mức độ hiển thị (visibility): 3 III.2.4 Thuộc tính (attribute): 4 III.2.5 Phương thức (method): 5 III.3 GIAO DIỆN (INTERFACE): 5 III.4 QUAN HỆ GIỮA CÁC LỚP: 5 III.4.1 Liên kết (association): 5 III.4.2 Tính bội (multiplicity) : 6 III.4.3 Liên kết có ràng buộc (association with constraint): 6 III.4.4 Lớp-liên kết (association class) : 6 III.4.5 Liên kết do suy diễn: 7 III.4.6 Liên kết có thẩm định (qualified association): 8 III.4.7 Liên kết nhiều chiều: 8 III.4.8 Quan hệ kết tập (aggregation relation) : 10 III.4.9 Quan hệ cấu thành (composition) : 11 III.4.10 Quan hệ phụ thuộc (dependancy): 11 III.4.11 Quan hệ thừa kế : 11 III.5 RÀNG BUỘC : 12 III.6 XÂY DỰNG MỘT SƠ ĐỒ LỚP : 12 III.6.1 Các quan điểm mô hình hóa : 12 III.6.2 Các bước xây dựng : 12

1

III.1 MỤC ĐÍCH CỦA SƠ ĐỒ LỚP :

- Được xem là mô hình quan trọng nhất trong phân tích hệ thống hướng đối tượng

- Dùng để mô tả cấu trúc bên trong, tĩnh của hệ thống

- Không dùng để chỉ ra cách thức làm thế nào sử dung các tác tử (operation) Trách nhiệm đó sẽ do sơ đồ tương tác

III.2 LỚP vÀ CÁC KHÁI NIỆM LIÊN QUAN:

Danh sách các thuộc tính

Tên lớp

- Tên lớp : phải có nghĩa và bắt đầu bằng chữ hoa Nếu nó được đóng gói, cần đặc tả tất cả các gói chứa nó theo thứ tự từ lớn đến nhỏ và cách bởi 2 dấu hai chấm ( :: )

Ví dụ : java ::lang ::Object

- Mỗi thuộc tính (attribute) được mô tả bằng tên và kiểu Tên của thuộc tính phải duy nhất trong lớp

- Mỗi phương thức (method) được mô tả kiểu trả về, danh sách các đối số và kiểu tương ứng của mỗi đối số

Ví dụ :

đkýMôn(m: String);

đkýNhóm(): Integer;

họ: String tên: String ngày_sinh: Date phái: {‘M’, ‘F’}

lớp: String Sinh_viên

2

III.2.2 Phương thức trừu tượng và lớp trừu tượng:

Một phương thức được gọi là trừu tượng nếu người ta biết được phần mô tả đầu của nó (header / entête / signature ) nhưng không biết cách thức nó có thể được thực hiện như thế nào

Một lớp được gọi là trừu tượng nếu nó định nghĩa ít nhất một phương thức trừu tượng hoặc khi một lớp cha chứa một phương thức trừu tượng chưa được thực hiện

III.2.3 Sự bao gói (encapsulation) và mức độ hiển thị (visibility):

Một lớp hoặc thành phần của lớp (chẳng hạn thuộc tính) có nhiều mức độ được nhìn thấy tùy theo ký tự đứng trước nếu có:

- Có từ khóa public hoặc dấu + đứng trước : được nhìn thấy từ bên ngoài

- Không có ký tự nào đứng trước : chỉ được nhìn thấy từ trong gói chứa lớp đang xét

- Có từ khóa protected hoặc dấu # đứng trước : được nhìn thấy từ trong

lớp đang xét hoặc các lớp con cháu của lớp đó

- Có từ khóa private hoặc dấu - đứng trước : chỉ được nhìn thấy từ trong

lớp đang xét

3