27/08/2012

1

TIN4122

1. Giới thiệu môn học

2. Các nguyên tắc Mô hình hóa trực quan

3. Các khái niệm của Hướng đối tượng, lớp & biểu đồ lớp

4. Mô hình hóa Use-Case

5. Các biểu đồ tương tác

6. Các biểu đồ UML khác

2

Phần 0

3

Giảng viênNguyễn Văn Trung

Môn họcGiới thiệu môn họcBạn trông đợi điều gì ở môn học này?

Trước khi đến với môn học này, bạn mô tả một hệ thống như thế nào?

4

Sau khi hoàn tất chương trình, bạn có thể:

Biết được UML là gì

Sử dụng UML mô hình hoá một hệ thống

đặc tả mã nguồn

mô tả yêu cầu người dùng

mô tả nghiệp vụ

mô tả kiến trúc hệ thống

mô tả triển khai hệ thống

5

Lý thuyết/Thực hành/Tự học: 16/8/8

Cách tính điểmChuyên cần Bài tập Tiểu luận Thi kết thúc HP

10% 30% 60%

6

27/08/2012

2

Phần 1

7

Định nghĩa kỹ thuật đối tượng (object technology) và sức mạnh của nó

Giới thiệu lịch sử của kỹ thuật đối tượng

Thảo luận về cách áp dụng kỹ thuật đối tượng trong giai đoạn hiện nay

8

Một tập các nguyên lý (trừu tượng hóa, bao gói, đa hình) hướng dẫn xây dựng phần mềm, cùng với các NNLT, CSDL, và các công cụ hỗ trợ các nguyên lý đó

(Object Technology – A Manager’s Guide, Taylor, 1997)

9

OT được sử dụng để tạo ra các mô hình (model) phản ánh một lĩnh vực (domain) cụ thể theo thuật ngữ của lĩnh vực đó

Các mô hình được tạo ra bằng OT phải dễ tạo, dễ thay đổi, mở rộng, kiểm định

10

Các hệ thống được xây dựng bằng OT có thể thay đổi linh động, có kiến trúc tốt, và có cơ hội để tạo và thi công/cài đặt dưới dạng các thành phần tái sử dụng

OT không chỉ là lý thuyết mà là công nghệ đã được kiểm chứng trong rất nhiều dự án xây dựng nhiều loại hệ thống khác nhau

Để thực hiện OT, cần một phương pháp tích hợp một quy trình phát triển và một ngôn ngữ mô hình hóa với các kỹ thuật và công cụ xây dựng thích hợp

11

Phản ánh một thuyết đơn nhất (single paradigm)

Tạo điều kiện để tái sử dụng kiến trúc và mã lệnh

Phản ánh đúng các mô hình thế giới thực

Xây dựng hệ thống ổn định

Xây dựng hệ thống thích nghi với sự thay đổi

12

27/08/2012

3

Các mốc chính

13

Hệ thống Client/Server và phát triển web: Kỹ thuật đối tượng cho phép đóng gói thông tin nghiệp vụ thành các đối tượng qua đó có thể xử lý phân tán trên Internet hoặc trên mạng

14

Hệ thống Thời gian – thực: Kỹ thuật đối tượng cho phép xây dựng các hệ thống thời gian – thực chất lượng cao và linh hoạt

15

Thiết kế hướng đối tượng (Object-Orientation, OO)

Kết hợp dữ liệu và quy trình xử lý dữ liệu sớm trong chu trình phát triển

Có mức bao gói cao

Thúc đẩy tái sử dụng mã lệnh ở mức cao

Cho phép mở rộng phần mềm

16

17

Định nghĩa dữ liệu & cách thức xử lý dữ liệu tách biệt nhau

18

Định nghĩa dữ liệu & cách thức xử lý dữ liệu gắn liền với nhau

Khai báo kiểu dữ liệuSử dụng trong thực tế

27/08/2012

4

Bạn hiểu thế nào về kỹ thuật đối tượng, điểm mạnh của nó, điểm yếu của nó?

Vì sao bạn cần chuyển qua sử dụng kỹ thuật đối tượng?

19

Phần 2

20

Tầm quan trọng của mô hình hóa trực quan

4 nguyên lý mô hình hóa trực quan

Giới thiệu UML

Các kiểu quy trình liên quan với UML

21

Mô hình là đơn giản hóa cái có thật

22

Mô hình hóa nhắm đến 4 mục đích:

Giúp trực quan hóa hệ thống bạn muốn tìm hiểu

Cho phép đặc tả cấu trúc và hành vi của một hệ thống

Đưa ra mẫu để hướng dẫn xây dựng hệ thống

Lập tài liệu về các quyết định đã đưa raXây dựng các mô hình của hệ thống phức tạp khi:

không thể hiểu một cách toàn diện hệ thống đó,

cần hiểu hơn nữa về hệ thống muốn xây dựng

23 24

Ít quan trọng hơn Quan trọng hơn

27/08/2012

5

Nhiều đội phần mềm thường xây dựng ứng dụng theo kiểu tiếp cận vấn đề giống như gấp máy bay giấyBắt đầu lập trình từ các yêu cầu của dự án

→ Tốn nhiều thời gian và mã lệnhBỏ qua việc xây dựng kiến trúc

→ Dễ dẫn đến thất bại

Mô hình hóa là con đường chung nhất để đem đến thành công cho dự án

25

1.Mô hình bạn tạo ra sẽ ảnh hưởng đến cách bạn giải quyết vấn đề

2.Mỗi mô hình có thể được diễn đạt theo nhiều mức độ chính xác khác nhau

3.Mô hình tốt nhất là mô hình liên hệ với thực tế nhất

4.Một mô hình là chưa đủ. Đối với một hệ thống không đơn giản, tốt nhất là nên được tiếp cận qua một số mô hình độc lập nhau

26

Mô hình bạn tạo ra sẽ ảnh hưởng sâu sắc đến cách giải quyết vấn đề và định hình giải pháp

Trong phần mềm, các mô hình bạn chọn ảnh hướng lớn theo cách nhìn của bạn

Mỗi cách nhìn sẽ dẫn đến một loại hệ thống khác nhau

27

Mỗi mô hình có thể được diễn đạt ở nhiều mức chính xác khác nhau

Các loại mô hình tốt nhất sẽ cho phép bạn chọn mức độ chi tiết, tùy thuộc vào:▪Ai xem mô hình?

▪Vì sao họ lại cần xem mô hình?Ví dụ:

Mô hình phác thảo GUI của hệ thống

Mô hình dữ liệu của hệ thống

28

Mọi mô hình đều đơn giản hóa cái có thực

Một mô hình tốt sẽ làm lộ rõ những đặc trưng quan trọng, những sai lầm tiềm tàng trong thiết kế

29

Không có mô hình nào là đầy đủ cả. Với mỗi hệ thống không tầm thường, tốt nhất là nên tiếp cận bằng một tập các mô hình gần như là độc lập nhauTạo ra các mô hình có thể được xây dựng và nghiên cứu

một cách riêng rẽ, nhưng chúng vẫn sẽ có liên quan với nhau

30

27/08/2012

6

31

UML (Unified Modelling Language) là ngôn ngữ dùng để

trực quan hóa (visualizing)

đặc tả (specifying)

xây dựng (constructing)

lập tài liệu (documenting)

các kết quả (artifact) của hệ thống cần đến phần mềm (software-intensive system)

32

Việc truyền đạt các mô hình khái niệm với nhau có thể gây lỗi trừ khi mọi người đều nói chung một ngôn ngữ

Có nhiều thứ trong hệ thống phần mềm mà bạn không thể hiểu được trừ khi xây dựng mô hình

Một mô hình tường minh sẽ tạo điều kiện cho việc truyền đạt dễ dàng

33 34

35 36

27/08/2012

7

UML xây dựng các mô hình chính xác, rõ ràng, và đầy đủ

37

Các mô hình UML có thể kết nối trực tiếp đến một số NNLT

Ánh xạ đến Java, C#, C++, VB, …

Các bảng trong CSDL quan hệ hoặc lưu trong CSDL HĐT

Cho phép xây dựng xuôi: sinh mã lệnh từ mô hình UML sang NNLT

Cho phép xây dựng ngược: cấu trúc lại một mô hình UML từ phần mã lệnh cài đặt

38

UML ghi lại tài liệu của kiến trúc hệ thống, yêu cầu, kiểm thử, kế hoạch dự án, và quản lý phiên bản phát hành

39 40

41

Chúng ta cần một quy trình phát triển hệ thống

42

27/08/2012

8

UML độc lập với nhiều quy trình phát triển phần mềm. Một quy trình hoàn toàn tận dụng được ưu thế của UML nếu:

Được định hướng theo Use-case

Tập trung kiến trúc (Architecture-centric)

Lặp và tăng dần (Iterative and incremental)

43

UC được định nghĩa cho hệ thống là cơ sở cho toàn bộ quá trình phát triển

Lợi ích của UC:

Chính xác, đơn giản, dễ hiểu cho nhiều stakeholders

Giúp đồng bộ hóa nội dung của nhiều mô hình khác nhau

44

Kiến trúc của hệ thống được sử dụng như là tài liệu chính để hình thành khái niệm, cấu trúc hóa, quản lý, và đưa ra hệ thống cần phát triển

Lợi ích

Kiểm soát dự án để có thể quản lý độ phức tạp và bảo đảm sự toàn vẹn hệ thống

Làm nền tảng hiệu quả cho việc tái sử dụng ở mức độ cao

Làm cơ sở cho việc quản lý dự án

Giúp phát triển hướng – thành phần (component-based development)

45

Các rủi ro chính sẽ được phân tích trước khi đầu tư lớn

Các bước lặp đầu sẽ cho phép nhận phản hồi sớm từ NSD

Việc kiểm thử và tích hợp sẽ được tiếp tục

Các mốc mục tiêu sẽ được tập trung trong thời gian ngắn

Tiến trình phát triển được đo bằng việc đánh giá các phần thi công

Các phần thi công một phần có thể được triển khai

46

Các vòng lặp sớm nhất sẽ xác định được các rủi ro lớn nhất

Mỗi vòng lặp sẽ đưa ra một phiên bản có thể thực thi, một bản bổ sung dần của hệ thống

Mỗi vòng lặp đều có tích hợp và kiểm thử

47

Mô hình là gì?

4 nguyên lý mô hình hóa là gì? Mô tả từng nguyên lý

UML là gì? Mô tả các lợi điểm của nó

Những đặc tính của quy trình phát triển phần mềm thích hợp nhất với UML là gì? Mô tả từng đặc tính

Thế nào là một vòng lặp?

48

27/08/2012

9

Phần 3

49

Mô tả tính trừu tượng, bao gói, module hóa, phân cấp

Mô tả cấu trúc vật lý của một lớp

Mô tả quan hệ giữa lớp và đối tượng

Định nghĩa đa hình và tổng quát hóa

Biểu đồ lớp trong UML & ứng dụng

50

Một cách không hình thức, một đối tượng biểu diễn một thực thể vật lý, khái niệm, hoặc phần mềm

Thực thể vật lý

Thực thể khái niệm

Thực thể phần mềm

51

Một đối tượng là một thực thể có ranh giới rõ ràng và có định danh, bao gói trạng thái và hành vi

Trạng thái được biểu diễn bằng các thuộc tính và các mối quan hệ Hành vi được biểu diễn bằng các thao tác, phương thức và các

máy trạng thái

52

Trạng thái (state) là điều kiện hoặc hoàn cảnh xuyên suốt chu trình sống của đối tượng, nhằm để phục vụ một số điều kiện, thực hiện một số hoạt động, hoặc chờ đợi một vài sự kiện nào đó

Trạng thái của đối tượng thường thay đổi theo thời gian

53

Hành vi quyết định cách thức đối tượng hành động và phản hồi các yêu cầu từ các đối tượng khác

Các hành vi được biểu diễn bằng các thao tác mà đối tượng có thể thực hiện được

54

27/08/2012

10

Mỗi đối tượng đều có một định danh duy nhất,ngay cả khi nó có cùng trạng thái với đối tượng khác

55

Hướng đối tượng

Bao

gói

Trừ

u tượ

ng h

óa

Phân

cấp

Môđ

un h

óa

56

Các đặc trưng cơ bản của một thực thể để phân biệt nó với các loại thực thể khác

Định nghĩa ranh giới theo quan điểm của người quan sát

Trừu tượng hóa không phải là một bản mô tả đầy đủ, nó chỉ ghi chú lại những ý niệm cơ bản của một điều gì đó

57 58

Che dấu cài đặt từ client

Client chỉ phụ thuộc vào giao diện

59

Tạo 1 class đếm số nguyên tố → PrimeCounter

Viết một chương trình sử dụng lớp PrimeCounter để đếm số nguyên tố

Cải tiến PrimeCounter

60

27/08/2012

11

Chia nhỏ một cái gì đó phức tạp thành nhiều phần nhỏ hơn, quản lý được

Giúp hiểu được hệ thống phức tạp

61

Chia nhỏ hệ thống thành nhiều mođun nhỏ hơn

62

Hệ thống Đăng ký Học phần

Hệ thống nộp học phí

Hệ thống quản lý Học phần

Hệ thống quản lý Sinh viên

63

TàiSản

BấtĐộngSảnChứngKhoánTàiKhoảnNgânHàng

CổPhiếu TráiKhoánTàiKhoảnTK

Các phần tử ở cùng cấp trên cây phân cấp thì nên ở cùng mức độ trừu tượng

Lớp (class) là mô tả của một tập các đối tượng có cùng thuộc tính, thao tác, mối quan hệ, và ngữ nghĩa

Đối tượng là một thể hiện (instance) của lớpMột lớp là một sự trừu tượng hóa mà trong đó, nó

nhấn mạnh các đặc tính có liên quan

bỏ qua các đặc tính khác

64

ClassLớpHọc

Thuộc tínhTên

Phòng họcSố buổi học

Số tiếtThời điểm bđầuThời điểm kthúc

Hành viThêm một SVXóa một SVXem TKB

65

Lớp được biểu diễn trong UML bằng một hình chữ nhật với các ngăn

66

27/08/2012

12

Một lớp có 3 phần

Tên lớp

Cấu trúc (các thuộc tính - attributes)

Hành vi (các thao tác - operations)

67

Lớp là định nghĩa trừu tượng của đối tượng

Lớp định nghĩa cấu trúc và hành vi của mỗi đối tượng thuộc về lớp

Lớp đóng vai trò như là mẫu để tạo ra đối tượng Lớp không phải là tập hợp các đối tượng

68

Thuộc tính là đặc tính có tên của lớp, mô tả dải giá trị mà đặc tính của đối tượng có thể có

Lớp có thể có 1, nhiều, hoặc không có thuộc tính nào

69 70

Một dịch vụ có thể được yêu cầu từ một đối tượng để tác động đến hành vi. Một thao tác có một ký hiệu để giới hạn các tham số có thể có

Một lớp có thể có 1, nhiều, hoặc không có thao tác nào

71

Có 4 mức:

+ public: dùng mọi nơi

~ package: dùng mọi nơi trong phạm vi gói

# protected: dùng trong định nghĩa lớp & lớp kế thừa

- private: chỉ được dùng trong định nghĩa lớp

72

27/08/2012

13

73 74

75 76

77 78

27/08/2012

14

79

gạch chân ở phía dưới thành phần static của lớp

Mối quan hệ tổng quát hoá (generalization)

Mối quan hệ kết hợp (association)

Mối quan hệ aggregation

Mối quan hệ composite

80

Class A phụ thuộc class B # các đối tượng của class A có thể làm việc với các đối tượng của class B, hoặc với class B

Mối quan hệ phụ thuộc thường được dùng khi bạn có 1 class cung cấp một số hàm tiện ích. Các class dùng các tiện ích này sẽ phụ thuộc vào class tiện ích đó.

81

Quan hệ ngữ nghĩa giữa 2 hay nhiều lớp cho biết kết nối giữa các thể hiện của các lớp này

Mối quan hệ cấu trúc cho biết các đối tượng thuộc lớp này được kết nối đến các đối tượng thuộc lớp khác

82

Association và mã nguồn tương ứng

83

Chiều mũi tên trong mối quan hệ

84

27/08/2012

15

Số lượng thể hiện của một lớp liên quan đến MỘT thể hiện thuộc về lớp khác)

Mỗi mối quan hệ kết hợp xác định 2 bản số (ở 2 đầu của mối quan hệ)Mỗi thể hiện của Professor có thể dạy nhiều Course

OfferingMỗi thể hiện của Course Offering, có thể không có hoặc

chỉ có 1 Proffessor nhận dạy

85 86

Thế nào là mô hình hóa 4 nguyên lý mô hình hóa UML Quy trình và mô hình hóa trực quan

87

Biểu diễn mối quan hệ toàn thể - bộ phận

Mức độ phụ thuộc của phía bộ phận và phía toàn thể

88

89

Một thành phần có thể được chứa trong tối đa là 1 composition tại cùng một thời điểm.

Nếu compostion bị xoá thì tất cả những phần tử của nó cũng bị xoá theo;

Một phần tử bộ phận có thể bị xoá riêng rẽ khỏi composition mà không cần phải xoá toàn bộ composition.

90

27/08/2012

16

Composition biểu diễn quan hệ contain-a (chứa một)

91

Mối quan hệ giữa các lớp mà trong đó, 1 lớp chia sẻ chung cấu trúc và/hoặc hành vi với 1/nhiều lớp khác

Định ra cây phân cấp của sự trừu tượng, trong đó lớp con kế thừa từ một hoặc nhiều lớp cha

Đơn kế thừa

Đa kế thừa Là mối quan hệ “is a kind of” (là một loại của)

92

93 94

Lớp con kế thừa từ lớp cha: thuộc tính, thao tác, và các mối quan hệ

Lớp con có thể

Bổ sung thêm các thuộc tính, thao tác, và các mối quan hệ

Định nghĩa lại các thao tác được kế thừaCác thuộc tính, thao tác, và/hoặc mối quan hệ

chung được biểu diễn ở mức áp dụng cao nhất trên cây phân cấp

Dùng tính kế thừa để mô tả sự tương tự giữa các lớp95

Khả năng che dấu nhiều cài đặt phức tạp đằng sau một giao diện chung

96

27/08/2012

17

layGiaTri()

Cổphiếu

+ layGiatri()

HợpĐồng BấtĐộngsản

+ layGiatri() + layGiatri()

97

Bài tập: Viết chương trình mô phỏng tính chất đa hình trong hướng đối tượng98

Abstract class: các class không được phép có thể hiện của nó, được tạo ra chỉ để kế thừa

99 100

101

1) Ôn tập các kiến thức về lập trình hướng đối tượng

2) Nắm thật kỹ cú pháp của 1 ngôn ngữ lập trình hướng đối tượng• C++• Java• C#

Kỹ thuật chung dùng để tổ chức các phần tử vào các nhóm

Một phần tử mô hình có thể chứa các phần tử mô hình khác

Một package có thể được dùng để:Tổ chức các mô hình đang phát triểnBiểu diễn đơn vị quản lý cấu hình tổ chức

102

27/08/2012

18

Package, University Artifacts, chứa 1 package và 5 lớp

103

Mô tả khung nhìn tĩnh của hệ thống (static view)

Từ vựng của một hệ thống

Sự cộng tác (collaboration)

Lược đồ CSDL logicBiểu diễn các yêu cầu của hệ thống

Minh họa cách đọc và diễn giải biểu đồ lớp

104

105

class Mô hình khái niệm

MụcDanhBạ

Người TổChức

ChủThể

DanhSáchEmail

DanhSáchSốĐiệnThoại

DanhSáchTag

Email

SốĐiệnThoại

Tag

DanhSáchMụcDanhBạ

Yêu cầu chức năng (Functional Requirement): Những chức năng mà hệ thống phải cung cấp

Ví dụ: Thêm, xóa, sửa Mục danh bạ, Sao lưu dữ liệu, …

Yêu cầu phi chức năng (Non-functional Requirement): Yêu cầu mang tính “tính năng”.

Ví dụ: yêu cầu về tốc độ truy cập dữ liệu, độ bảo mật, ngôn ngữ giao tiếp, tính dễ sử dụng, …

106

107

req Quản lý Danh bạ

In danh sách Danh bạ

Quản lý Danh sách số điện thoại của danh bạ

Quản lý Mục danh bạ

Quản lý danh sách Tag của Mục danh bạ

Quản lý danh sách địa chỉ email của danh bạ

Sửa danh bạ

Tìm kiếm Mục danh bạ

Tìm kiếm theo Tag

Tìm kiếm theo Họ tên

Tìm kiếm theo Số điện thoại

Tạo mới danh bạXem danh sách Danh bạ

Xóa danh bạ

108

Tìm các phần mềm hỗ trợ làm việc với UML VÀ 

học cách sử dụng nó

27/08/2012

19

Thế nào là đối tượng?Mô tả 4 nguyên lý hướng đối tượngThế nào là lớp? Mô tả quan hệ giữa lớp và đối

tượngThuộc tính là gì? Thao tác là gì?Định nghĩa tính đa hình. Cho một ví dụ về tính đa

hìnhThế nào là tổng quát hóa?Tại sao sử dụng package?

109

Phần 4

110

Mô tả hành vi của hệ thống và cách biểu diễn nó trong mô hình

Minh họa cách đọc và diễn giải:

Biểu đồ UC

Biểu đồ hoạt động (activity diagram)

111

Các khái niệm trong mô hình hóa Use-case Biểu đồ Use-case Biểu đồ hoạt động (Activity diagrams)

112

Hành vi hệ thống là cách hệ thống hoạt động (act) và phản hồi)

Hành vi hệ thống nhìn được từ bên ngoài và có thể kiểm tra hoạt động của hệ thống

Hành vi hệ thống được thể hiện trong các use case

Use cases mô tả hệ thống, môi trường của nó, và mối quan hệ giữa hệ thống và môi trường của nó

113

Mô hình Use Case là mô hình mô tả các yêu cầu chức năng của hệ thống (system’s functional requirement) bằng thuật ngữ Use Case

Mô hình hóa các chức năng dự kiến của hệ thống (các use case) và môi trường của nó (các actors)

114

27/08/2012

20

115

uc Bán hàng trực tuyến

KháchHàng

Xem danh sách SảnPhẩm

Xem chi tiết SảnPhẩm

Bổ sung SảnPhẩm v ào GiỏHàng

Xem nội dung GiỏHàngXóa SảnPhẩm khỏi

GiỏHàng

Chỉnh sửa số lượng SảnPhẩm trong GiỏHàng

Thanh toán

Danh sách các SảnPhẩm được liệt kê dưới dạng phân trang

«invokes»

«invokes»

«invokes»

«invokes»«invokes»

Truyền đạt với end user và domain expert Hiểu nhất quán các yêu cầu

Xác định các NSD hệ thống và hệ thống phải làm gì Yêu cầu về giao diện của hệ thống (system interface)

Verification Kiểm tra lại để bảo đảm mọi yêu cầu đều được nắm bắt

116

Actor biểu diễn bất kỳ cái gì có tương tác với hệ thống. Mô hình hóa Actor như là vai trò trong hệ thống.

Use case mô tả chuỗi sự kiện, được thực hiện bởi hệ thống, sinh ra kết quả quan sát được cho một Actor cụ thể

117

Actor biểu diễn vai trò mà NSD của hệ thống có thể đảm nhận

Có thể là người, máy, hoặc một hệ thống khác

Có thể trao đổi thông tin linh hoạt với hệ thống

Có thể là phía cho thông tin (giver of information)

Có thể là phía nhận thông tin thụ động (passive recipient of information)

Actor không phải là một phần của hệ thống

118

Định nghĩa một tập các thể hiện use-case, trong đó mỗi thể hiện là một chuỗi các hoạt động (action) mà hệ thống thực hiện để sinh ra một kết quả quan sát được cho một actor cụ thể

Một use case mô hình hóa một hội thoại giữa 1/nhiều actor với hệ thống

Một use case mô tả các hoạt động của hệ thống nhằm đưa lại giá trị gì đó cho actor

119

Một use case mô hình hóa một hội thoại giữa actor với hệ thống

Một use case được khởi hoạt bằng một actor để triệu gọi một chức năng cụ thể nào đó trong hệ thống

120

27/08/2012

21

Mối quan hệ <<include>>

Mối quan hệ <<extend>>

Mối quan hệ <<invoke>>

Mối quan hệ <<preceded>>

Mối quan hệ tổng quát hóa

Ví dụ về biểu đồ Use Case

121

The difference between “theory” and “practice” is that in theory there is no difference between theory and practice, but in practice, there is.

122

Biểu đồ hoạt động trong mô hình use-case dùng để thể hiện các hoạt động trong một use case

Bản chất là một flow chart, biểu diễn luồng điều khiển từ hoạt động này đến hoạt động khác

123

Biểu diễn hoạt động hay một bước trong luồng công việc (workflow)

Một hoạt động (activity) là một thao tác cần một khoảng thời gian nào đó để hoàn tất. Nó:

có thể có các phần bổ sung, chẳng hạn như entry action, và exit action

có thể có đặc tả các sub-machine

124

125

Các quá trình hoặc chuyển dịch cơ bản xuất hiện trong hệ thốngKhối chức năng cơ bản bên trong Biểu đồ hoạt độngLà con của các hoạt động

Cả Action và Activity đều biểu diễn cho các quá trình, nhưng Activity thì có thể chứa nhiều bước và có thể phân thành các quy trình, mỗi một quy trình như vậy có thể tương ứng thành Action

Action thì không thể phân nhỏ hơn. broken down or decomposed.

126

27/08/2012

22

Xem demo…

127 128

129 130

131 132

27/08/2012

23

133 134

135 136

137 138

27/08/2012

24

139

Thế nào là hành vi hệ thống?

Mô hình use-case là gì? Lợi ích của nó?

Actor là gì? Use case là gì?

Thế nào là biểu đồ hoạt động?

140

Cho:

Các use case, actor, và các mối kết hợp truyền thôngVẽ

Biểu đồ use caseCho

Các trạng thái hoạt động và các chuyền trạng thái (transition)

Vẽ

Biểu đồ hoạt động

141

Mô hình hoá Business UC

Mô hình hoá System UC

142

Phần 5

143

Mô tả hành vi động (dynamic behavior) và cách biểu diễn nó trong mô hình

Minh họa cách đọc và diễn giải:

Biểu đồ cộng tác (collaboration diagram)

Biểu đồ tuần tự (sequence diagram)

Diễn giải sự giống và khác nhau giữa biểu đồ cộng tác và biểu đồ tuần tự

144

27/08/2012

25

Các đối tượng hữu ích là đối tượng có thể cộng tác cùng nhau để giải quyết một vấn đề nào đó

Mỗi đối tượng chịu trách nhiệm cho các hành vi và trạng thái của nó

Các đối tượng tương tác với nhau như thế nào?

Thông qua các thông báo

145

Một thông báo biểu diễn cách mà một đối tượng yêu cầu đối tượng khác thực hiện một thao tác nào đó

146

Biểu đồ tương tác biểu diễn một tương tác mà trong đó chứa một tập các đối tượng và các mối quan hệ của chúng, bao gồm các thông báo có thể được giải quyết giữa chúng

Biểu đồ tương tác mô hình hóa khía cạnh động của hệ thống

147

Sequence diagrams

Collaboration diagrams

Interaction diagram comparison

148

Biểu đồ tuần tự tập trung vào thứ tự của các thông báo

Biểu đồ tuần tự biểu diễn:

Các đối tượng tham gia vào tương tác

Trình tự các thông báo được trao đổi

149 150

27/08/2012

26

151 152

153 154

Participant: một phần của hệ thống

Các participant tương tác với nhau trong một SD

155 156

attribute = message_name (arguments) : return_type

27/08/2012

27

157 158

159 160

161 162

27/08/2012

28

163 164

Biểu đồ cộng tác tập trung vào tổ chức của các phần tử tham gia vào quá trình tương tác

Biểu đồ cộng tác trình bày:

Các đối tượng tham gia vào quá trình tương tác.

Kết nối giữa các đối tượng.

Các thông điệp truyền giữa các đối tượng.

165 166

167 168

27/08/2012

29

169

Semantically equivalent

Can convert one diagram to the other without losing any information

Model the dynamic aspects of a system

Model a use-case scenario

170

Collaboration diagrams

Show relationships in addition to interactions

Better for visualizing patterns of collaboration

Better for visualizing all of the effects on a given object

Easier to use for brainstorming sessions

Sequence diagrams

Show the explicit sequence of messages

Show focus of control Better for visualizing

overall flow Better for real-time

specifications and for complex scenarios

171

What is the purpose of an interaction diagram?

What is a sequence diagram? A collaboration diagram?

What are the similarities between sequence and collaboration diagrams?

What are the differences between sequence and collaboration diagrams?

172

Given:

A set of objects and their links and messagesProduce:

A sequence diagram

A collaboration diagram

173 174

27/08/2012

30

Business Actor

Business Worker

Business Use case

175

Module 7

176

Demonstrate how to read and interpret a:

Statechart diagram

Deployment model

Component diagram

177

A statechart diagram shows a state machine.

It specifies the sequence of states that an object can be in:

The events and conditions that cause the object to reach those states

The actions that take place when those states are reached

178

A state is represented as a rounded rectangle on a statechart diagram.

As a comparison, note the subtle difference between a state and an activity.

179

The initial state is the state entered when an object is created.An initial state is mandatory.Only one initial state is permitted.The initial state is represented as a solid circle.

A final state indicates the end of life for an object.A final state is optional.A final state is indicated by a bull’s eye.More than one final state may exist.

180

27/08/2012

31

The deployment diagram shows:

Configuration of processing nodes at run-time

Communication links between these nodes

Component instances and objects that reside on them

181

A physical element that exists at run-time and represents a computational resource.

Types:

Processor Node▪Executes system software

Device Node▪Support device

▪Typically controlled by a processor

182

A connection represents a:

Communication mechanism▪Physical medium

▪Software protocol

183 184

A diagram that shows the organization of and the dependencies among a set of components.

185

A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.

It conforms to and provides the physical realization of a set of interfaces.

186

27/08/2012

32

UML 1.4 introduces concept of Artifacts: An Artifact represents a physical piece of information

that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files.

To distinguish between artifacts in general, and the artifacts that make up the implementation, we introduce a new term:

Implementation Element - the physical parts (UML artifacts) that make up an implementation, including software code files (source, binary or executable), and data files.

187

Component becomes similar to subsystem:can group classes to define a larger granularity units of a systemcan separate the visible interfaces from internal implementationcan have instances that execute at run-time

The distinction between "component" and "artifact" is new in UML 1.4.Many tools, profiles, and examples continue to use "component" to represent implementation elements

188

Define state. How do you determine the classes with significant state?

What is a statechart diagram?

Describe the different parts of the diagram.

How do statechart diagrams map to the rest of the world?

What is the purpose of a deployment diagram?

What is a component diagram?

189

Ánh xạ giữa các lớp thiết kế với CSDL của hệ thống

Các kỹ thuật

190