1. Trang chủ
  2. » Công Nghệ Thông Tin

UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx

36 381 3

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 36
Dung lượng 643,44 KB

Nội dung

ở góc độ mô hình hóa, các phần tử UML có thể phân chia làm ba loại là các phần tử mô hình hóa tĩnh, các phần tử mô hình hóa tương tác và các phần tử quan hệ có chức năng liên kết giữa ha

Trang 1

siêu mô hình UML bao gồm các phần tử và một số quy tắc về cú pháp Ngoài việc phần tử UML mang một ý nghĩa xác định, cú pháp UML còn mô tả cách liên kết những phần tử nào với nhau để tạo ra ý nghĩa nào đó ở góc độ mô hình hóa, các phần tử UML có thể phân chia làm ba loại là các phần tử mô hình hóa tĩnh, các phần tử mô hình hóa tương tác và các phần tử quan hệ có chức năng liên kết giữa hai phần tử trên với nhau siêu mô hình UML giữ vai trò hướng dẫn người sử dụng UML về cú pháp trong mô hình hóa Ngoài ra, siêu mô hình UML còn được sử dụng bởi các nhà phát triển CASE tool để mô hình hóa dữ liệu cho một CASE tool hỗ trợ UML Mô hình dữ liệu này sử dụng lại định nghĩa phần tử UML để thiết kế các lớp cơ bản và bổ sung thêm các lớp mới tùy theo chức năng CASE tool cung cấp cho người sử dụng

Mô hình UML là biểu diễn ký hiệu của các phần tử UML đồng thời cung cấp cho người sử dụng các biểu đồ UML cụ thể để mô hình hóa cũng như làm ngôn ngữ giao tiếp giữa các thành viên của nhóm trong quá trình phát triển phần mềm Nói cách khác, các biểu đồ trong Mô hình UML là thể hiện của các cú pháp tương ứng trong siêu mô hình UML siêu mô hình UML được chia thành nhiều gói thành phần (package) dựa trên ý nghĩa của cú pháp được mô tả Mỗi gói định nghĩa các phần tử khác nhau và mô tả một nhóm cú pháp dựa trên các phần tử này Trong mỗi gói lại có thể bao gồm các gói con Việc phân chia này giúp cho

định nghĩa của siêu mô hình UML rõ ràng hơn, chỉ quan tâm đến các phần tử trong gói và loại bỏ các phần tử không cần thiết vượt ra khỏi phạm vi ngữ nghĩa cần mô tả của gói Gói được biểu diễn như sau

T ê n g ó i

Hình 2.1 Ký hiệu gói

2.2 Tổng quan về các loại quan hệ giữa các phần tử

Trong quá trình định nghĩa phần tử cần phải mô tả các mối liên hệ giữa phần

tử này với các phần tử khác nên UML sử dụng một tập hợp các quan hệ Mỗi

Trang 2

quan hệ có một ý nghĩa xác định Các quan hệ này bao gồm quan hệ tổng quát hóa (generalization), quan hệ kết hợp (association), quan hệ phụ thuộc (dependency)

Mỗi phần tử đều có ngữ nghĩa riêng Để biểu diễn phần tử và quan hệ giữa các phần tử, UML sử dụng các ký hiệu riêng Một phần tử có ký hiệu như sau:

T ê n p h ầ n tử

C á c th u ộ c tín h

Hình 2.2 Ký hiệu phần tử

Phần sau trình bày sơ lược các loại quan hệ Chi tiết về các loại quan hệ giữa

các phần tử được trình bày trong chương sau

2.2.1 Quan hệ tổng quát hoá (generalization)

Quan hệ tổng quát hoá là quan hệ giữa một phần tử tổng quát hơn và một phần tử đặc biệt hơn Phần tử đặc biệt hơn chứa đầy đủ các đặc điểm của phần tử tổng quát hơn và ngoài ra còn có những thông tin riêg Quan hệ tổng quát hóa có

và quan hệ kết tập (aggregation) Quan hệ ngữ nghĩa thông thường

Hình 2.4 Ký hiệu quan hệ kết hợp

Quan hệ kết tập: phần tử này chứa phần tử kia theo nghĩa vật lý

Trang 3

Hình 2.5 Ký hiệu quan hệ kết tập

2.2.3 Quan hệ phụ thuộc (dependency)

Quan hệ phụ thuộc thể hiện sự phụ thuộc chức năng của một hay nhiều phần

tử nhận vào một hay nhiều phần tử cho Quan hệ phụ thuộc kém chi tiết về mức

độ ngữ nghĩa hơn quan hệ kết hợp và thường sử dụng để mô tả sự phụ thuộc lẫn nhau giữa các gói

Hình 2.6 Ký hiệu quan hệ phụ thuộc

2.3 Tổng quan về các phần tử và cấu trúc siêu mô hình UML

2.3.1 Phân loại phần tử trong siêu mô hình UML

ở góc độ định nghĩa, các phần tử trong UML có thể được chia làm hai loại là phần tử trừu tượng và phần tử cụ thể Các phần tử trừu tượng có tính tổng quát cao giữ chức năng tham gia vào định nghĩa các phần tử khác Các phần tử cụ thể thường có quan hệ tổng quát hóa qua nhiều tầng với các phần tử trừu tượng, ngoài ra còn có các quan hệ kết hợp (association) với các phần tử khác Chỉ các phần tử cụ thể mới có ký hiệu trong Mô hình UML và được sử dụng trong mô hình hóa

2.3.2 Cấu trúc siêu mô hình UML

Siêu mô hình UML bao gồm ba gói chính như sau

Foundation

M odel M anagement Behavioral

Elements

Hình 2.7 Các gói chính của UML

Trang 4

Foundation Package (Gói nền tảng) là gói bao gồm phần lớn các phần tử trừu tượng và một số phần tử cụ thể mang tính chất cơ bản Các phần tử trong gói này

được sử dụng bởi hai gói là BehavioralElements Package (gói phần tử hành vi) và

tả quá trình vận động của một phần tử hay tương tác giữa các phần tử trong thế giới thực

người sử dụng

2.4 Package Foundation Package (gói nền tảng)

hệ và đa số là ở mức trừu tượng Extension Mechanism Package định nghĩa cơ chế

mở rộng cho các phần tử UML để bổ sung các phần tử mới Data Types Package

định nghĩa các kiểu dữ liệu được sử dụng trong siêu mô hình UML Các thuộc tính của các phần tử trong siêu mô hình UML có kiểu dữ liệu thuộc về Data Types

2.4.1 Core Package (gói cơ bản)

pháp cho mô hình hóa tĩnh, không quan tâm đến quá trình vận động và tương tác giữa các đối tượng trong thế giới thực

Trang 5

Parameter defaultValue: Expression kind: ParameterDirectionKind

Constraint body: BooleanExpression

Attribute

initialvalue: Expression

O peration concurency:CallConcurencyKind isRoot:Boolean

isLeaf:Boolean isAbstract:boolean specification: String

Method body: ProcedureExpresstion

+ ow nedElement + nameSpace

*

0 1

+ constraintElement

+ constraint 1 *

*

{ordered}

*

0 1 + feature

đóng vai trò tổng quát hóa trực tiếp của phần lớn các phần tử cụ thể khác Ngoài

ra, các phần tử cơ bản của UML được định nghĩa trong Core bao gồm attribute

(thuộc tính), operation (hoạt động) và method (phương thức), parameter (tham số)

quát nhất trong các phần tử UML

trong mô hình và là tổng quát hóa cấp cao nhất thứ hai cho các phần tử khác sau

hợp các phần tử ModelElement với điều kiện định danh của một ModelElement

trong một Namespace là duy nhất

phần tử chứa trong Namspace (không gian các phần tử) ElementOwnership quy

định tầm vực của một phần tử được giới hạn trong Namespace (chỉ có thể được

tham chiếu bởi các phần tử trong Namespace) hay vượt khỏi Namespace (có thể

được tham chiếu bởi các phần tử ngoài Namespace)

Trang 6

GeneralizableElement (phần tử có thể tổng quát hóa hay đặc biệt hóa):

hay đặc biệt hóa Do đó một GeneralizableElement có thể là tổng quát hóa hay đặc biệt hóa của một GeneralizableElement khác

(visibility) của đặc tính Tầm vực này xác định một đặc tính của Classifier có thể

được tham chiếu bởi các Classifier khác hay chỉ được sử dụng bởi chính Classifier

chứa đặc tính đó

này có thể thay đổi hay cố định qua thuộc tính changeability của StructuralFeature

đặc tính về mặt hành vi của một Classifier đồng thời mô tả đặc tính hành vi này có

ảnh hưởng lên trạng thái của Classifier hay không qua thuộc tính isQuery

thức) Ngoài ra, mô hình Backbone còn định nghĩa các phần tử cụ thể đóng vai trò quan trọng bậc nhất là Attribute (thuộc tính), Method (phương thức), Operation (mô tả phương thức), Parameter (tham số) và Constraint (ràng buộc)

dụng để thể hiện trạng thái Attribute có các thuộc tính chính là name (tên), initial

từ một Classifier chứa Operation để tác động lên Classifier này Operation có quan hệ kết hợp (association) với Parameter (tham số) nghĩa là Operation sử dụng một tập tham số để khởi đầu cho việc thi hành Một Operation có thể được kế thừa từ các

phương thức) mô tả cụ thể cách thức thực hiện một phương thức bao gồm các quy trình và các thuật toán Method có tác động đến kết quả của phương thức

tiếp với nó Parameter được sử dụng trong Operation (mô tả phương thức),

giới hạn cho một phần tử, có thể diễn tả ở dạng văn bản hay một biểu thức logic của một ngôn ngữ mô tả ràng buộc Ngoài việc định nghĩa phần tử ràng buộc

ràng buộc đối tượng(Object Constraint Language) Giữa các Classifier có quan hệ tổng quát hóa Do Classifier là phần tử trừu tượng nên tất cả các phần tử thừa kế

2.4.1.2 Mô hình Relationships (các quan hệ)

Trang 7

AsosicationEnd isNavigable: Boolean ordering: OrderingKind aggregation:AggregationKind multiplicity: Multiplicity changeability:ChangeableKind visibility: VisibilityKind

Model Element name :Name

Relationship

isRoot:Boolean isLeaf:Boolean isAbstract:boolean

Asosication body: BooleanExpression Classifier

Class isActive: Boolean

Assosication Class

Generalization dicrimonator: Name

Attribute initialvalue: Expression

Trang 8

Mô hình Relationships định nghĩa các quan hệ giữa các phần tử UML bao gồm hai loại quan hệ cơ bản là generalization (quan hệ tổng quát hóa), association

(quan hệ kết hợp)

biệt hơn gọi là phần tử con (child) và phần tử tổng quát hơn là phần tử cha (parent)

mô tả sự liên hệ về ngữ nghĩa giữa các Classifier

tính riêng đặc trưng cho quan hệ giữa các classifier này

Nhân sự

Tiền lương Nhân sự 1 *

Công ty

0 *

Hình 2.11 Ví dụ lớp kết hợp

2.4.1.3 Mô hình Classifiers (các đặc biệt hóa của classifiers)

Mô hình Classifiers mô tả các đặc biệt hóa của Classifier bao gồm các phần tử

Trang 9

isActive: Boolean

visibility: VisibilityKind Element

Hình 2.12 Các lớp đặc biệt của Classifier

Class (lớp)

nghĩa Một Class có thể là trừu t−ợng (abstract) nghĩa là không có thể hiện (đối t−ợng) nào đ−ợc tạo ra trực tiếp từ nó Class là phần tử cụ thể có biểu diễn ký hiệu trên Mô hình UML Là đặc biệt hóa của Classifier, Class bao gồm các

có quan hệ tổng quát hóa, quan hệ kết hợp

Th− ký

Kế toán viên Công việc

Phòng ban

Tên nhân viên Nhân viên

Lấy thông tin nhân viên() Thực hiện

Hình 2.13 Ví dụ về lớp và quan hệ giữa các lớp

Trang 10

Interface (giao diện)

cung cấp một dịch vụ của Classifier bao gồm một nhóm các operation có quan hệ

DataType (kiểu dữ liệu)

kiểu dữ liệu cụ thể Việc định nghĩa các kiểu dữ liệu của người sử dụng tùy thuộc vào môi trường phát triển phần mềm nên thường các CASE tool đảm nhận chức năng định nghĩa các kiểu dữ liệu này

Node (nút)

Node là phần tử đại diện cho một tài nguyên vật lý có bộ nhớ và khả năng

xử lý tính toán Các node thường đại diện cho các máy tính và mô tả việc phân

bố các máy tính trên mạng

Component (thành phần)

đóng gói các phương thức xử lý và cung cấp tập các dịch vụ xử lý này qua một

khác nhau để phục vụ cho một mục đích cụ thể Các phương thức có thể là các

đoạn mã thi hành được, các script hay lệnh Một component thường cung cấp nhiều loại dịch vụ khác nhau liên quan đến một đối tượng cụ thể

<<COM>>

MSBind DBindingColectionEvents Giao diện

Component DBindingColection

DBinding

Một MSBind là một component nối một control của Window với một recordset MSBind cung cấp nhiều dịch vụ, trong đó dịch

vụ gắn control vào recordset

là Bindding

Hình 2.14 Ví dụ về component và interface

Trang 11

2.4.1.4 Mô hình Dependencies (các quan hệ phụ thuộc)

phần nhận Thành phần cho đóng vai trò cung cấp dịch vụ cho thành phần nhận

cả các phần tử cụ thể thừa kế ModelElement đều có thể có quan hệ phụ thuộc Quan hệ phụ thuộc có các đặc biệt hóa là Binding (gắn), Abstraction (trừu t−ợng hóa), Usage (sử dụng) và Permisson (cho phép)

Abstraction (trừu t−ợng hóa)

khác nhau Ví dụ nh− chuyển một khái niệm ở mức phân tích sang mức thiết kế bằng quan hệ Abstraction

Trang 12

Usage (sử dụng)

của một phần tử ModelElement khác

Permisson (cho phép)

gian các phần tử) tham chiếu các phần tử khác trong Namespace Phần tử nhận

là một ModelElement phần tử cho bắt buộc là một Namespace

Template Parameter (tham số cho mẫu)

Tham số cho mẫu là tham số cho các phần tử Template Ví dụ như trong một môi trường ngôn ngữ lập trình hỗ trợ Template, ta có thể xây dựng lớp mới bằng cách cung cấp các lớp tham số cho Template TemplateParameter định nghĩa quan

Trang 13

hệ giữa một phần tử ModelElement với các tham số (các tham số này là các phần

Presentation Element (phần tử biểu diễn trực quan)

UML không định nghĩa cụ thể các thông tin này mà để cho các CASE tool tự do

định nghĩa

2.4.2 Package Extension Mechanisms (gói kỹ thuật mở rộng)

2.4.2.1 Khái quát

cách đưa ra cơ chế bổ sung các phần tử với ngữ nghĩa mới Package này định nghĩa Stereotypes, Constraint (ràng buộc) và Tagged Value (thẻ giá trị) là ba cơ chế mở rộng của UML

UML cung cấp cơ chế mở rộng để thêm các phần tử mới cho các lĩnh vực

đặc biệt mà UML chuẩn không định nghĩa Các lĩnh vực cần các khái niệm mới

có thể tự định nghĩa các khái niệm này qua cơ chế mở rộng UML

Việc mở rộng này không đơn giản là gắn tên Stereotypes vào phần tử và quy

định ngữ nghĩa mới do đôi khi còn có các ràng buộc ngữ nghĩa trong thế giới thực Do đó các stereotype thường chứa các ràng buộc và các giá trị thẻ Mỗi

động Phần tử được tác động này là các phần tử trong siêu mô hình UML ví dụ

được phần tử mới thừa kế phần tử cũ và có tên của stereotype Ví dụ như

Component có các stereotype là " document ”," executable ”," table” Các stereotype

này bản chất cũng là component nhưng " document " là một thành phần

(component) chứa các sưu liệu, " executable " là thành phần chứa các dịch vụ xử

lý còn " table " chứa các bảng trong một cơ sở dữ liệu

Trang 14

ModelElement (from Core)

Constraint (from Core)

Là các ràng buộc ngữ nghĩa được gắn với một phần tử cần mở rộng để áp

đặt các điều kiện lên phần tử này và có tác dụng thay đổi hay giới hạn ngữ nghĩa Phần tử mở rộng phải thỏa mãn các ràng buộc này để đảm bảo sự chính xác về ngữ nghĩa Constraint cũng có thể được gắn với stereotypes để tác động lên các phần tử có quan hệ với stereotypes này

2.4.2.3 Stereotype

Là cơ chế phân loại một phần tử theo quan hệ kết hợp của phần tử này với

phần tử cũ ngoài ra có thêm các thông riêng Stereotype chính là sự khác nhau

về ngữ nghĩa của hai phần tử cùng cấu trúc Ví dụ như trong quy trình phát triển phần mềm Rational Unified Process, các stereotype cho phần tử Class được định nghĩa thêm trong đó có stereotype "boundary” Stereotype này là một Class đóng vai trò giao tiếp với các tương tác bên ngoài hệ thống Mục đích của mở rộng này là phân loại các Class theo chức năng phục vụ cho quá trình phân tích

Trang 15

Class với stereotype là

"boundary"

Giao diện người sử dụng

Giao diện người sử dụng

Phân tích

Hình 2.18 Ví dụ Stereotype

2.4.2.4 Tagged Value (thẻ giá trị)

Là các thuộc tính đính kèm cho một phần tử mở rộng Tagged Value có thể chứa những thông tin bất kỳ cần thiết bổ sung cho một phần tử mới

2.4.3 Các kiểu dữ liệu trong siêu mô hình UML (Data Types)

2.4.3.1 Khái quát

nghĩa là thuộc tính của các phần tử trong siêu mô hình UML có các kiểu dữ liệu trong Data Types Data Types cần thiết cho sự tham khảo sâu hơn về các thuộc tính và ý nghĩa mỗi thuộc tính của một phần tử trong siêu mô hình UML

Data Types không phải là kiểu dữ liệu của người sử dụng Kiểu dữ liệu của người sử dụng UML được định nghĩa bởi DataType là đặc biệt hóa của Classifiers trong Core Data Types không định nghĩa cú pháp nào cho người sử dụng

2.4.3.2 Các kiểu dữ liệu trong Data Types

Các giá trị này xác định loại Association.

Boolean : kiểu liệt kê bao gồm hai giá trị false và true

CallConcurrencyKind : kiểu liệt kê bao gồm các giá trị sequential, guarded, concurrent

Trang 16

EnumerationLiteral : định nghĩa một giá trị thuộc một kiểu liệt kê

hay được cung cấp bởi một Classifier bao gồm các giá trị provide và require

ParameterDirectionKind : kiểu liệt kê bao gồm các giá trị in, inout, outreturn

ProcedureExpression : biểu thức trả về một Procedure

PseudostateKind : kiểu liệt kê bao gồm các giá trị initial, deepHistory, shallowHistory, join, fork, branch, junction và final

VisibilityKind : kiểu liệt kê bao gồm các giá trị public, protectedprivate

2.5 Behavioural Elements Package (gói phần tử hành vi)

hóa hành vi và tương tác BehavioralElements bao gồm năm gói là Common

hình chức năng), State Machines (mô hình trạng thái) và Activity Graphs (mô hình hành động)

Trang 17

Activity Graphs

State Machines Use Cases

Collaboration

Common Behavior

Hình 2.19 Behavioural Elements Package

các phần tử để thực hiện một tác vụ cụ thể

loại người sử dụng Use Cases giữ vai trò định nghĩa cho biểu đồ Use Case ở Mô hình UML

trạng thái của một phần tử StateMachine định nghĩa biểu đồ StateChart trong Mô hình UML

2.5.1 Package Common Behavior (gói hành vi tổng quát)

động), Instances and Links (thể hiện và liên kết)

Trang 18

Classifier (from Core)

Signal

Exception

BehavioralFeature (from Core)

specification:String isRoot:Boolean isLeaf:Boolean isAbstract:Boolean Stereotype +signal

0 *

+reception

*

+context +raisedSignal

Hình 2.20 Mô hình Signals

2.5.1.1 Mô hình Signals (tín hiệu)

Mô hình này chủ yếu định nghĩa phần tử Signal (tín hiệu) Tín hiệu đ−ợc tạo

ra từ một BehavioralFeature (đặc điểm hành vi) của classifier này và gủi đến một phần tử Reception (nhận tín hiệu)của một classifier khác

Reception (phần tử nhận tín hiệu)

các hành động (bằng chuỗi văn bản) của tín hiệu đến classifier nhận

Signal (tín hiệu)

lập với các classifier Signal đ−ợc tạo ra do các BehavioralFeature (đặc điểm hành vi) của các classifier này và gửi đến các classifier khác Do BehavioralFeature là phần tử hành vi trừu t−ợng nên tất cả các phần tử hành vi thừa kế

signal

Ngày đăng: 13/08/2014, 06:22

HÌNH ẢNH LIÊN QUAN

Hình 2.5 Ký hiệu quan hệ kết tập - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.5 Ký hiệu quan hệ kết tập (Trang 3)
Hình 2.9. Mô hình BackBone - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.9. Mô hình BackBone (Trang 5)
Hình 2.10. Mô hình Relationships - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.10. Mô hình Relationships (Trang 7)
Hình 2.11. Ví dụ lớp kết hợp - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.11. Ví dụ lớp kết hợp (Trang 8)
Hình 2.13. Ví dụ về lớp và quan hệ giữa các lớp - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.13. Ví dụ về lớp và quan hệ giữa các lớp (Trang 9)
Hình 2.12. Các lớp đặc biệt của Classifier - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.12. Các lớp đặc biệt của Classifier (Trang 9)
Hình 2.14. Ví dụ về  component  và  interface - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.14. Ví dụ về component và interface (Trang 10)
Hình 2.15. Mô hình Dependence - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.15. Mô hình Dependence (Trang 11)
Hình 2.16. Mô hình AuxiliaryElements - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.16. Mô hình AuxiliaryElements (Trang 12)
Hình 2.17. Mô hình  Extension Mechanisms - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.17. Mô hình Extension Mechanisms (Trang 14)
Hình 2.20. Mô hình  Signals - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.20. Mô hình Signals (Trang 18)
Hình 2.21. Mô hình Action - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.21. Mô hình Action (Trang 19)
Hình 2.24. Ví dụ sự hợp tác - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.24. Ví dụ sự hợp tác (Trang 26)
Hình là  Main  (chủ yếu) và  Events  (sự kiện).  Main  mô tả  State  (trạng thái) và - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình l à Main (chủ yếu) và Events (sự kiện). Main mô tả State (trạng thái) và (Trang 29)
Hình 2.29. Ví dụ về trạng thái giả và trạng thái kếp hợp - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.29. Ví dụ về trạng thái giả và trạng thái kếp hợp (Trang 31)
Hình 2.30. Mô hình Event - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.30. Mô hình Event (Trang 32)
Hình 2.31. Mô hình Activity Graphs - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 2.31. Mô hình Activity Graphs (Trang 33)
Hình 5.32. Ví dụ về biểu đồ hoạt động - UML – OOAD phân tích thiết kế phần mềm - Chương 2 docx
Hình 5.32. Ví dụ về biểu đồ hoạt động (Trang 34)

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w