MÔ HÌNH HÓA ĐỐI TƯỢNG– CLASS DIAGRAM ĐIỂM CAO

Kỹ Thuật - Công Nghệ - Khoa học xã hội - Quản trị kinh doanh Mô hình hóa đối tượngMô hình hóa đối tượng Nội dung trước Mô hình hóa yêu cầu: Lược đồ Use-case Khái niệm Actor và Usecase Ví dụ Mô hình hóa các dòng dữ liệu của mỗi Use-case 4 – Mô hình hóa đối tượng– Class Diagram 2 Mô hình hóa các dòng dữ liệu của mỗi Use-case Giới thiệu Mô hình DFD Sử dụng mô hình DFD để mô hình hóa yêu cầu lưu trữ, tra cứu, tính toán, kết xuất Nội dung Quản lý yêu cầu: Giới thiệu Chi tiết quản lý yêu cầu Các kỹ năng 4 – Mô hình hóa đối tượng– Class Diagram 3 Các kỹ năng Mô hình hoá đối tượng Class Class Diagram Giới thiệu Một trong những hoạt động đầu tiên Mục tiêu: tìm cái cần xây dựng Giao tiếp giữa người dùng và người phát triển, vì vậy Không có ký hiệu phức tạp (ngoại trừ trong lĩnh vực chuyên môn) Thường dùng ngôn ngữ tự nhiên Hợp đồng 4 – Mô hình hóa đối tượng– Class Diagram Hợp đồng Các cách thức để xác định yêu cầu Các cách thức để chuẩn hóa yêu cầu Scenarios, Use Cases, Mockups Prototypes, Feature, Lists Stakeholders Những người quan tâm đến sản phẩm 4 Thế nào là quản trị yêu cầu Là tiến trình tìm hiểu, sưu liệu và quản lý các yêu cầu. Sử dụng những kỹ thuật mang tính hệ 4 – Mô hình hóa đối tượng– Class Diagram thống để đảm bảo yêu cầu: Complete (đầy đủ) Consistent (nhất quán) Relevant (thích đáng) 5 Thế nào là quản trị yêu cầu Diễn tả bằng văn xuôi, Tìm hiểu cái người dùng muốn Tổ chức thông tin này lại Sưu liệu thông tin này 4 – Mô hình hóa đối tượng– Class Diagram Sưu liệu thông tin này Theo vết thay đổi thông tin này Quản lý tất cả thay đổi Đáp ứng nhu cầu người dùng cuối Thiết lập quy trình và thực hiện theo nó 6 Thế nào là quản trị yêu cầu Hầu hết các tổ chức phát triển phần mềm đều làm việc này theo những cách thức khác nhau. Nhưng thường chúng không mang tính hình thức và mang tính không thống nhất từ dự án này qua dự án khác 4 – Mô hình hóa đối tượng– Class Diagram CMM Level 1 vs. CMM Level 2 = Định nghĩa được tiến trình quản lý yêu câu 7 Thế nào là một yêu cầu Là một khả năng của phần mềm được người dùng yêu cầu, để giải quyết một vấn đề nhằm đạt một mục tiêu nào đó 4 – Mô hình hóa đối tượng– Class Diagram Thành công của dự án = thoả mãn các yêu cầu 8 Nguồn yêu cầu: Khách hàng Phỏng vấn khách hàng Người trả tiền cho chúng ta Những stakeholders Người sử dụng Người quản lý Vấn đề: Khách hàng có thể không biết họ muốn gì 4 – Mô hình hóa đối tượng– Class Diagram Khách hàng có thể không biết họ muốn gì Phần mềm là một khái niệm trừu tượng và phức tạp KH có thể thay đổi ý kiến KH không có khả năng diễn tả nhu cầu theo những thuật ngữ chuyên môn Giao tiếp giữa người chuyên làm p.mềm người bình thường Các kỹ thuật Giao diện Hệ thống đã tồn tại 9 Nguồn yêu cầu: thị trường Đánh giá các sản phẩm cạnh tranh Những gì trước đây đã thực hiện? Nơi nào là nơi thích hợp cho chúng ta Lưu ý vấn đề bản quyền, thương hiệu sáng chế Tự đánh giá khả năng của chúng ta 4 – Mô hình hóa đối tượng– Class Diagram Tự đánh giá khả năng của chúng ta Chúng ta có thể làm gì tốt hơn đối thủ cạnh tranh Những kiến thức, kỹ năng, ý tưởng mà chúng ta có 10 Nguồn yêu cầu: thị trường Khảo sát thị trường Phỏng vấn khách hàng (cũ, tiềm năng, …) Lưy ý tới những quảng cáo, tạo nhu cầu thị trường Quan tâm tới xu hướng phát triển của thị trường 4 – Mô hình hóa đối tượng– Class Diagram Quan tâm tới xu hướng phát triển của thị trường Vấn đề Người ta không biết người ta muốn gì? Thị trường thay đổi rất nhanh Bảo mật ý tường ??? 11 Nguồn các yêu cầu: các chuẩn Các chuẩn và các hệ thống chuyển đổi System standard, file formats, network protocols Usability standards Domain standards Official standards written by a standards body 4 – Mô hình hóa đối tượng– Class Diagram written by a standards body ANSI ISO (e.g. Unicode) IEEE (e.g. Posix) Industry standards Java, Dot-Net Wimp user interface WAMP, LAMP 12 Các loại yêu cầu Chức năng Features User interface InputOutput Phi chức năng 4 – Mô hình hóa đối tượng– Class Diagram Phi chức năng Hướng người dùng Performance, Precision, Reliability Hướng người phát triển Maintainability, Reusability, Interoperability 13 Những vấn đề quản trị yêu cầu Nhiều hệ thống thường Chuyền giao trễ và vượt ngân sách cho phép Không đáp ứng đầy đủ yêu cầu người dùng Không hoạt động hiệu quả Bước đầu tiên để giải quyết vấn đề 4 – Mô hình hóa đối tượng– Class Diagram Bước đầu tiên để giải quyết vấn đề xác định nguyên nhân cốt lõi Ví dụ về những nguyên nhân cốt lõi Thiếu dữ liệu người dùng Yêu cầu đặc tả không đầy đủ Yêu cầu và đặc tả thay đổi 14 Tăng chi phí do yêu cầu sai hoặc thiếu sót 0.1 0.5 1 Requirements Design Coding 4 – Mô hình hóa đối tượng– Class Diagram 2 5 20 15 Tỷ lệ chi phí để sửa chữa theo từng giai đoạn Unit testing Acceptance - testing Maintenance Thế nào là quản trị yêu cầu tốt Ngăn: Vượt chi phí và thời gian Huỷ dự án Một dự án thành công cần các yếu tố: Sự quan tâm của người dùng 4 – Mô hình hóa đối tượng– Class Diagram Sự quan tâm của người dùng Hỗ trợ của người quản lý Yêu cầu rõ ràng 16 Chất lượng của yêu cầu: tính ổn định Ổn định Không có mâu thuẫn Chương trình sẽ không thể hoạt động nếu yêu cầ u mâu thuẫn Khó đảm báo vì 4 – Mô hình hóa đối tượng– Class Diagram Số lượng yêu cầu lớn Mâu thuẫn tiềm ẩn Bản chất VĐ: mâu thuẫn có thể dẫn đến mọi thứ … Vấn đề Khó giải thích mâu thuẫn cho khách hàng Khách hàng muốn những thứ không thể 17 Chất lượng yêu cầu: có thể quản lý được Tài nguyên phải có thể đáp ứng các yêu cầu Có thể làm đúng thời gian Với chi phí cho phép Trong khả năng (kỹ năng) có thể? Quản lý rủi ro Xếp độ ưu tiên các yêu cầu 4 – Mô hình hóa đối tượng– Class Diagram Xếp độ ưu tiên các yêu cầu Phải có thay thế nếu cái chính không hoạt động Mở ra những vấn đề không thể để nói đến những yêu cầ u có thể làm Quản lý độ phức tạp Đừng làm mọi thứ cùng một lúc Qui trình lặp Prototyping 18 Chất lượng yêu cầu: sự đặc tả Càng chính xác và chi tiết càng tốt Không tốt “program shall be fast” “it takes a number as input” Tốt “program shall give a response in less than 1s” 4 – Mô hình hóa đối tượng– Class Diagram “program shall give a response in less than 1s” “it takes a 16-bit signed integer as input” Những định nghĩa Luôn là những ý tưởng tốt Vd: “by ''''Number'''', we always mean a 16-bit signed integer” Qui tắc định nghĩa Không định nghĩa xoay vòng (phụ thuộc) 19 Chất lượng yêu cầu không thiên về cài đặt Thiên về cài đặt: Đưa thông tin thiết kế Đưa thông tin về mã nguồn Sử dụng những thuật ngữ chuyên môn Không dùng từ ngữ chuyên môn kỹ thuật Bạn muốn tập trung vài CÁI GÌ 4 – Mô hình hóa đối tượng– Class Diagram Bạn muốn tập trung vài CÁI GÌ Bỏ LÀM THẾ NÀO lại phần sau Ví dụ không tốt “store the checked-out books in an array” “calculate the square root with Newton''''s algorithm” Ví dụ tốt “the library knows which books are checked out” “return the square root with 5-digit precision” 20 Đội ngũ phát triển phần mềm Quản lý yêu cầu đụng đến từng cá nhân trong đội ngũ phát triển Nếu nhóm xác định yêu cầu làm việc tốt 4 – Mô hình hóa đối tượng– Class Diagram ảnh hưởng tốt đến kết quả của toàn nhóm phát triển dự án 21 Những kỹ năng xác định yêu cầu 6 kỹ năng cần thiết Phân tích vấn đề Hiểu nhu cầu người dùng 4 – Mô hình hóa đối tượng– Class Diagram Định nghĩa được hệ thống Quản lý được phạm vi Tinh lọc được hệ thống Xây dựng đúng hệ thống cần thiết 22 Kỹ năng làm việc Cũng cần phải có Giao tiếp Phân tích và suy nghĩ 4 – Mô hình hóa đối tượng– Class Diagram Diễn giải Lập báo cáo Trình diễn 23 Chi phí cho việc xác định yêu cầu Chi phí: Chiếm từ 15 đến 30 kinh phí toàn dự án Khi bỏ ra càng nhiều thời gian cho công đoạn xác định yêu cầu, chúng ta sẽ càng 4 – Mô hình hóa đối tượng– Class Diagram đoạn xác định yêu cầu, chúng ta sẽ càng tiết thời gian cho: Thiết kế Triển khai Kiểm chứng 24 Qui trình lấy yêu cầu Requirememts eliciation Requirememts Analysis Negotiation Requirememts documentation Requirememts validation 4 – Mô hình hóa đối tượng– Class Diagram 25 Requirememts document System specification User needs domain information, existing system information, regulations, standards, etc. Agreed Requirements Phân tích kiến trúc trong ngữ cảnh 4 – Mô hình hóa đối tượng– Class Diagram 26 Tổng quan về phân tích 4 – Mô hình hóa đối tượng– Class Diagram 27 Mô hình “4+1 View” 4 – Mô hình hóa đối tượng– Class Diagram 28 UML trong mô hình 4+1 view Use case View: đây là hướng nhìn chỉ ra khía cạnh chức năng của một hệ thống, nhìn từ hướng tác nhân bên ngoài. Use case Diagrams Logical View: chỉ ra chức năng sẽ được thiết kế bên 4 – Mô hình hóa đối tượng– Class Diagram Logical View: chỉ ra chức năng sẽ được thiết kế bên trong hệ thống như thế nào Class Diagrams Object Diagrams Package Diagrams Composite Structure Diagrams State Machine Diagrams 29 UML trong mô hình 4+1 view Process View: chỉ ra sự tồn tại song song trùng hợp trong hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong hệ thống. Sequence Diagrams Communication Diagrams Activity Diagrams 4 – Mô hình hóa đối tượng– Class Diagram Activity Diagrams Timing Diagrams Interaction Overview Diagrams 30 Implementation View Development View: chỉ ra khía cạnh tổ chức của các thành phần code. Component Diagrams Deployment View Physical View: chỉ ra khía cạnh triển khai hệ thống vào các kiến trúc vật lý (các máy tính UML trong mô hình 4+1 view 4 – Mô hình hóa đối tượng– Class Diagram triển khai hệ thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm công tác). Deployment Diagrams 31 Class Diagram Class Diagram là sơ đồ mô tả các lớp, các giao diện (interface) và các mối liên hệ giữa chúng, cho ta một khung nhìn tĩnh của các lớp trong mô hình. 4 – Mô hình hóa đối tượng– Class Diagram 32 Ví dụ 4 – Mô hình hóa đối tượng– Class Diagram 33 Object Class Class (Lớp) Là 1 nhóm Object chung thuộc tính và hành vi Chung mối quan hệ và chung ngữ nghĩa Là khuôn mẫu để tạo ra đối tượng Object (Đối tượng): là thể hiện thực tế của 1 4 – Mô hình hóa đối tượng– Class Diagram Object (Đối tượng): là thể hiện thực tế của 1 lớp Ví dụ: Lớp Sinh viên có thể tạo ra 2 đối tượ ng là sinh viên A và sinh viên B. 34 Analysis Class Bước đầu cho một hệ thống có khả năng thực thi 4 – Mô hình hóa đối tượng– Class Diagram 35 Tìm các class từ Use Case Behavior Toàn bộ hành vi của Use Case phải được phân bổ về cho các analysis class 4 – Mô hình hóa đối tượng– Class Diagram 36 Các Stereotyle của lớp Trong biểu đồ lớp, stereotype là cơ chế để phân lớp. Có 3 loại lớp phân tích: 4 – Mô hình hóa đối tượng– Class Diagram 37 Boundary Class Là lớp trung gian thể hiện sự tương tác giữa hệ thống và những gì bên ngoài hệ thống Các lớp biên: Lớp giao diện giữa người dùng và hệ thống Lớp giữa hệ thống và các hệ thống bên ngoài 4 – Mô hình hóa đối tượng– Class Diagram 38 Lớp giữa hệ thống và các hệ thống bên ngoài Ví dụ giao dịch với “Hệ thống tài vụ” Lớp giữa hệ thống và thiết bị ngoại vi Ví dụ “Thiết bị giải mã vạch” Với mỗi cặp ActorUse-Case bao giờ c...

Trang 1

Mô hình hóa đối tượng

Trang 2

Nội dung trước

Mô hình hóa yêu cầu:

L ượ c đồ Use-case Khái ni ệ m Actor và Usecase

Ví d ụ

Mô hình hóa các dòng dữ liệu của mỗi Use-case

Gi ớ i thi ệ u Mô hình DFD

S ử d ụ ng mô hình DFD để mô hình hóa yêu

c ầ u l ư u tr ữ , tra c ứ u, tính toán, k ế t xu ấ t

Trang 3

Nội dung

Quản lý yêu cầu:

Gi ớ i thi ệ u Chi ti ế t qu ả n lý yêu c ầ u Các k ỹ n ă ng

Các k ỹ n ă ng

Mô hình hoá đối tượng

Class & Class Diagram

Trang 4

Giới thiệu

Một trong những hoạt động đầu tiên

Mục tiêu: tìm cái cần xây dựng

Giao tiếp giữa người dùng và người phát triển, vì vậy

Không có ký hi ệ u ph ứ c t ạ p (ngo ạ i tr ừ trong l ĩ nh v ự c chuyên môn)

Th ườ ng dùng ngôn ng ữ t ự nhiên

H ợ p đồ ng

Các cách thức để xác định yêu cầu

Các cách thức để chuẩn hóa yêu cầu

Scenarios, Use Cases, Mockups / Prototypes, Feature, Lists

Stakeholders

Nh ữ ng ng ườ i quan tâm đế n s ả n ph ẩ m

Trang 5

Thế nào là quản trị yêu cầu

Là tiến trình tìm hiểu, sưu liệu và quản lý các yêu cầu.

Sử dụng những kỹ thuật mang tính hệ thống để đảm bảo yêu cầu:

Complete ( đầ y đủ ) Consistent (nh ấ t quán)

đ

Trang 6

Diễn tả bằng văn xuôi,

Tìm hi ể u cái ng ườ i dùng mu ố n

T ổ ch ứ c thông tin này l ạ i

S ư u li ệ u thông tin này

S ư u li ệ u thông tin này Theo v ế t thay đổ i thông tin này

Qu ả n lý t ấ t c ả thay đổ i

Đ áp ứ ng nhu c ầ u ng ườ i dùng cu ố i

Thiết lập quy trình và thực hiện theo nó

Trang 7

Hầu hết các tổ chức phát triển phần mềm đều làm việc này theo những cách thức khác nhau.

Nhưng thường chúng không mang tính hình thức và mang tính không thống nhất từ dự án này qua dự án khác

CMM Level 1 vs CMM Level 2

= Định nghĩa được tiến trình quản lý yêu câu

Trang 8

Thế nào là một yêu cầu

Là một khả năng của phần mềm được người dùng yêu cầu, để giải quyết một

vấn đề nhằm đạt một mục tiêu nào đó

Thành công của dự án = thoả mãn các

yêu cầu

Trang 9

Nguồn yêu cầu: Khách hàng

Trang 10

Nguồn yêu cầu: thị trường

Đánh giá các sản phẩm cạnh tranh

Những gì trước đây đã thực hiện?

Nơi nào là nơi thích hợp cho chúng ta

Lưu ý vấn đề bản quyền, thương hiệu sáng chế

Tự đánh giá khả năng của chúng ta

Chúng ta có thể làm gì tốt hơn đối thủ cạnh tranh

Những kiến thức, kỹ năng, ý tưởng mà chúng ta có

Trang 11

Nguồn yêu cầu: thị trường

Khảo sát thị trường

Ph ỏ ng v ấ n khách hàng (c ũ , ti ề m n ă ng, …)

L ư y ý t ớ i nh ữ ng qu ả ng cáo, t ạ o nhu c ầ u th ị tr ườ ng Quan tâm t ớ i xu h ướ ng phát tri ể n c ủ a th ị tr ườ ng Quan tâm t ớ i xu h ướ ng phát tri ể n c ủ a th ị tr ườ ng

Vấn đề

Ng ườ i ta không bi ế t ng ườ i ta mu ố n gì?

Th ị tr ườ ng thay đổ i r ấ t nhanh

Trang 12

Nguồn các yêu cầu: các chuẩn

Các chuẩn và các hệ thống chuyển đổi

System standard, file formats, network protocols Usability standards

• ISO (e.g Unicode)

• IEEE (e.g Posix)

Industry standards

Java, Dot-Net Wimp user interface WAMP, LAMP

Trang 13

Các loại yêu cầu

Chức năng

Features User interface Input/Output

Phi chức năng

H ướ ng ng ườ i dùng

• Performance, Precision, Reliability

H ướ ng ng ườ i phát tri ể n

• Maintainability, Reusability, Interoperability

Trang 14

Những vấn đề quản trị yêu cầu

Nhiều hệ thống thường

Chuy ề n giao tr ễ và v ượ t ngân sách cho phép Không đ áp ứ ng đầ y đủ yêu c ầ u ng ườ i dùng Không ho ạ t độ ng hi ệ u qu ả

Bước đầu tiên để giải quyết vấn đề

xác đị nh nguyên nhân c ố t lõi

Ví dụ về những nguyên nhân cốt lõi

Thi ế u d ữ li ệ u ng ườ i dùng Yêu c ầ u đặ c t ả không đầ y đủ

Yêu c ầ u và đặ c t ả thay đổ i

Trang 15

Tăng chi phí do yêu cầu sai hoặc thiếu sót

Trang 16

Thế nào là quản trị yêu cầu tốt

Ngăn:

V ượ t chi phí và th ờ i gian

Hu ỷ d ự án

Một dự án thành công cần các yếu tố:

S ự quan tâm c ủ a ng ườ i dùng

H ỗ tr ợ c ủ a ng ườ i qu ả n lý Yêu c ầ u rõ ràng

Trang 17

Chất lượng của yêu cầu: tính ổn định

Ổn định

Không có mâu thu ẫ n

Ch ươ ng trình s ẽ không th ể ho ạ t độ ng n ế u yêu c ầ u mâu thu ẫ n

Khó đảm báo vì

S ố l ượ ng yêu c ầ u l ớ n Mâu thu ẫ n ti ề m ẩ n

Bản chất VĐ: mâu thuẫn có thể dẫn đến mọi thứ …

Vấn đề

Khó gi ả i thích mâu thu ẫ n cho khách hàng

Trang 18

Chất lượng yêu cầu: có thể quản lý được

Tài nguyên phải có thể đáp ứng các yêu cầu

Ph ả i có thay th ế n ế u cái chính không ho ạ t độ ng

M ở ra nh ữ ng v ấ n đề không th ể để nói đế n nh ữ ng yêu c ầ u có

Trang 19

Chất lượng yêu cầu: sự đặc tả

Càng chính xác và chi tiết càng tốt

Không tốt

“program shall be fast”

“it takes a number as input”

Tốt

“program shall give a response in less than 1s”

“it takes a 16-bit signed integer as input”

Những định nghĩa

Luôn là nh ữ ng ý t ưở ng t ố t Vd: “by 'Number', we always mean a 16-bit signed integer”

Trang 20

Chất lượng yêu cầu không thiên về cài đặt

Thiên về cài đặt:

Đư a thông tin thi ế t k ế

Đư a thông tin v ề mã ngu ồ n

Sử dụng những thuật ngữ chuyên môn

Không dùng t ừ ng ữ chuyên môn k ỹ thu ậ t

B ạ n mu ố n t ậ p trung vài CÁI GÌ

B ỏ LÀM TH Ế NÀO l ạ i ph ầ n sau

Ví dụ không tốt

“store the checked-out books in an array”

“calculate the square root with Newton's algorithm”

Ví dụ tốt

•“the library knows which books are checked out”

“return the square root with 5-digit precision”

Trang 21

Đội ngũ phát triển phần mềm

Quản lý yêu cầu đụng đến từng cá nhân

trong đội ngũ phát triển

Nếu nhóm xác định yêu cầu làm việc tốt

ảnh hưởng tốt đến kết quả của toàn nhóm phát triển dự án

Trang 22

Những kỹ năng xác định yêu cầu

6 kỹ năng cần thiết

Phân tích vấn đề Hiểu nhu cầu người dùng Định nghĩa được hệ thống Quản lý được phạm vi

Tinh lọc được hệ thống Xây dựng đúng hệ thống cần thiết

Trang 24

Chi phí cho việc xác định yêu cầu

Chi phí:

Chi ế m t ừ 15% đế n 30% kinh phí toàn d ự án

Khi bỏ ra càng nhiều thời gian cho công đoạn xác định yêu cầu, chúng ta sẽ càng

đoạn xác định yêu cầu, chúng ta sẽ càng tiết thời gian cho:

Thi ế t k ế

Tri ể n khai

Ki ể m ch ứ ng

Trang 25

Qui trình lấy yêu cầu

Requirememts

eliciation

Requirememts Analysis &

Negotiation

Requirememts documentation

Requirememts validation

Requirememts document

Trang 26

Phân tích kiến trúc trong ngữ cảnh

Trang 27

Tổng quan về phân tích

Trang 28

Mô hình “4+1 View”

Trang 29

UML trong mô hình 4+1 view

Use case View: đây là hướng nhìn chỉ ra khía cạnh chức

năng của một hệ thống, nhìn từ hướng tác nhân bên

ngoài.

Use case Diagrams

Logical View: chỉ ra chức năng sẽ được thiết kế bên

trong hệ thống như thế nào

Class Diagrams Object Diagrams Package Diagrams Composite Structure Diagrams

Trang 30

Process View: chỉ ra sự tồn tại song song/ trùng hợp trong

hệ thống, hướng đến vấn đề giao tiếp và đồng bộ hóa trong

hệ thống.

Sequence Diagrams Communication Diagrams Activity Diagrams

Activity Diagrams Timing Diagrams Interaction Overview Diagrams

Trang 31

Implementation View/ Development View: chỉ ra

khía cạnh tổ chức của các thành phần code.

Component Diagrams

Deployment View/ Physical View: chỉ ra khía cạnh

triển khai hệ thống vào các kiến trúc vật lý (các máy tính

triển khai hệ thống vào các kiến trúc vật lý (các máy tính hay trang thiết bị được coi là trạm công tác).

Deployment Diagrams

Trang 32

Class Diagram

Class Diagram là sơ đồ mô tả các lớp, các giao

diện (interface) và các mối liên hệ giữa chúng, cho

ta một khung nhìn tĩnh của các lớp trong mô hình.

Trang 33

Ví dụ

Trang 34

Object & Class

Class (Lớp)

Là 1 nhóm Object chung thu ộ c tính và hành vi Chung m ố i quan h ệ và chung ng ữ ngh ĩ a

Là khuôn m ẫ u để t ạ o ra đố i t ượ ng

Object (Đối tượng): là th ể hi ệ n th ự c t ế c ủ a 1

l ớ p

Ví d ụ : L ớ p Sinh viên có th ể t ạ o ra 2 đố i t ượ ng là

sinh viên A và sinh viên B.

Trang 35

Analysis Class

Bước đầu cho một hệ thống có khả năng thực thi

Trang 36

Tìm các class từ Use Case Behavior

Toàn bộ hành vi của Use Case phải được phân bổ về cho các analysis class

Trang 37

Các Stereotyle của lớp

Trong biểu đồ lớp, stereotype là cơ chế để phân lớp Có

3 loại lớp phân tích:

Trang 39

Boundary Class

Mô hình hoá sự tương tác giữa hệ thống và môi trường

Trang 40

Entity Class

Là các lớp mô tả những thực thể chính xuất hiện trong hệ thống

Thực thể là những thông tin tồn tại và được lưu

trữ lâu dài trong hệ thống

Chỉ mô tả ở mức trừu tượng, không mô tả quá

chi tiết các thuộc tính của thực thể này

Trang 41

Entity Class

Trang 42

Tìm kiếm Entity Class

Nguồn thông tin có thể tìm Entity Class:

Các Use case Các yêu c ầ u Nghiên c ứ u h ệ th ố ng t ươ ng t ự đ ã có

S ự tr ợ giúp c ủ a các chuyên gia ứ ng d ụ ng

Trang 43

Tìm kiếm Entity Class

Sử dụng luồng sự kiện của Use-Case là đầu vào

Ngoài ra, c ầ n nghiên c ứ u:

Các danh t ừ trong yêu c ầ u

Ki ế n th ứ c chuyên ngành thu ộ c ph ạ m vi bài toán Xem xét các h ệ th ố ng t ươ ng t ự

Trang 44

Loại bỏ các Entity Class không thích hợp

Lớp dư thừa: định nghĩa cùng 1 thực thể

Lớp không thích hợp: không liên quan đến vấn đề hiện tại

Lớp không rõ ràng: không có chức năng cụ thể

Các lớp chỉ vai trò (Roles) đối với 1 lớp khác cũng được Các lớp chỉ vai trò (Roles) đối với 1 lớp khác cũng được lọc để giữ lại lớp chính

Trang 45

Banks: Thông tin ngân hàng bạn đang giao dịch, nếu có nhiều nhà

Bank tham gia vào hệ thống bạn phải quản lý nó Lúc đó Bank trở

thành đối tượng bạn phải quản lý.

ATM: Thông tin ATM bạn sẽ giao dịch Nó cũng được quản lý tương

Trang 46

Ví dụ

Ví dụ: Đặc tả uscase đăng ký môn học

Trang 47

Lưu ý

Cần phân biệt giữa khái niệm và thuộc

tính.

Ví dụ: Cần xây dựng phần mềm quản lý

các chuyến bay Đích đến của chuyến bay

là thuộc tính của chuyến bay hay một lớp

khác?

Trang 49

Control Class

Thể hiện hành động, chức năng của từng Use Case

Trang 50

Tóm tắt các Stereotyle của class

Trang 51

Trách nhiệm của các lớp phân tích

Lớp biên (Boundary Class)

Ch ị u trách nhi ệ m th ể hi ệ n s ự t ươ ng tác gi ữ a h ệ th ố ng

và tác nhân bên ngoài

Ch ị u trách nhi ệ m ki ể m tra d ữ li ệ u qua l ạ i trong quá trình

t ươ ng tác

Lớp thực thể (Entity Class)

Ch ị u trách nhi ệ m qu ả n lý thông tin c ủ a nó

Đ óng gói thông tin, và thay đổ i tr ạ ng thái c ủ a nó

Lớp điều khiển (Control Class)

Ch ị u trách nhi ệ m chính cho m ộ t Use Case nào đ ó Tránh để l ớ p đ i ề u khi ể n làm quá ít vi ệ c

Trang 52

Class trong Class Diagram

Class là thành phần chính của bản vẽ Class Diagram Class

mô tả về một nhóm đối tượng có cùng tính chất, hành động

trong hệ thống. Class Name

Attributes

Operations

Class Name: là tên của lớp.

Attributes (thuộc tính): mô tả tính chất của các đối tượng Ví

dụ như khách hàng có Mã khách hàng, Tên khách hàng, Địa

Trang 53

Biểu diễn thuộc tính

Chỉ ra tên, kiểu và giá trị mặc định nếu có

AttributeName : Type = Default Tuân theo quy ước đặt tên của ngôn ngữ cài đặt và của

dự án.

Kiểu (type) nên là kiểu dữ liệu cơ bản trong ngôn ngữ

Kiểu (type) nên là kiểu dữ liệu cơ bản trong ngôn ngữ thực thi

Kiểu dữ liệu có sẵn, kiểu dữ liệu người dùng định nghĩa, hoặc lớp tự định nghĩa.

Trang 55

Gói (Package)

Một cơ chế chung để tổ chức các phần tử thành nhóm Một phần tử trong mô hình có thể chứa các phần tử

khác.

Vd: Registration Package

Trang 56

Phạm vi truy cập (Visibility)

Phạm vi truy cập được sử dụng để thực hiện khả

năng đóng gói

Trang 57

Phạm vi (Scope)

Xác định số lượng thể hiện của thuộc tính/thao tác:

– Instance: Một thể hiện cho mỗi thể hiện của mỗi lớp

– Classifier: Một thể hiện chung cho tất cả các thể hiện của lớp (static)

Phạm vi Classifier được ký hiệu bằng cách gạch dưới tên

thuộc tính/thao tác.

Trang 59

Class Diagram -Khung t ĩ nh cho h ệ th ố ng

Ví dụ

Trang 60

Relationships (Mối quan hệ giữa các lớp)

Association (Kết hợp) – Bản số và chiều

Aggregation (Thu n ạ p): toàn th ể và b ộ ph ậ n Composition (C ấ u thành)

Dependency (Phụ thuộc)

Generalization (Tổng quát hóa) Đơn/Đa kế thừa

Realization (Hiện thực hoá)

Trang 62

Bội số quan hệ (Multiplicity)

Bội số quan hệ là số lượng thể hiện của một lớp liên

quan tới MỘT thể hiện của lớp khác.

Với mỗi liên kết, có hai bội số quan hệ cho hai đầu của

liên kết.

– Với mỗi đối tượng của Professor, có nhiều Course

Offerings có thể được dạy.

– Với mỗi đối tượng của Course Offering, có thể có 1 hoặc

0 Professor giảng dạy.

Trang 63

Biểu diễn bội số quan hệ

Trang 64

Ví dụ

Trang 65

Là một dạng đặc biệt của liên kết mô hình hóa mối quan hệ toàn thể-bộ phận (whole-part) giữa đối tượng toàn thể và các

bộ phận của nó.

– Thu nạp là mối quan hệ “là một phần” (“is a part-of”).

Bội số quan hệ được biểu diễn giống như các liên kết khác

Trang 66

Ví dụ

Trang 67

Association hay Aggregation

Trang 68

Cấu thành (Composition)

Một dạng của kết tập với quyền sở hữu mạnh và các vòng đời trùng khớp giữa hai lớp

– Whole sở hữu Part, tạo và hủy Part.

– Part bị bỏ đi khi Whole bị bỏ, Part không thể tồn tại nếu Whole không tồn tại.

Trang 69

Association, Aggregation and Composition

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

(relationship)

Liên k ế t (Association)

• S ử d ụ ng (use-a) Thu n ạ p (Aggregation) Thu n ạ p (Aggregation)

• Strong association

• has-a/is-a-part

H ợ p thành (Composition)

Trang 70

Tổng quát hóa (Generalization)

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

Xác định sự phân cấp về mức độ trừu tượng hóa trong đó lớp con kế thừa từ một hoặc nhiều lớp

trong đó lớp con kế thừa từ một hoặc nhiều lớp cha

– Đơn kế thừa (Single inheritance)

– Đa kế thừa (Multiple inheritance)

Là mối liên hệ “là một loại” (“is a kind of”)

Trang 71

Abstract and Concrete Class

Ch ứ a ph ươ ng th ứ c tr ừ u t ượ ng

Ch ữ nghiêng

Trang 72

Đơn kế thừa

Một lớp kế thừa từ MỘT lớp khác

Trang 74

Đa kế thừa

Phụ thuộc vào ngôn ngữ lập trình

Kế thừa lặp lại

Trang 75

Đa hình (Polymorphism)

Khả năng che giấu các thực thi khác nhau dưới

một giao diện duy nhất.

Trang 76

Ví dụ

Trang 77

Ví dụ

Trang 78

Xây dựng Class Diagram cần chú ý

Quản lý sự toàn vẹn (xét theo trình tự)

Trang 79

Checkpoints: Analysis Classes

với nhau về mặt chức năng không?

Class có cung cấp các hành vi được yêu cầu?

Tất cả các yêu cầu cụ thể đã được thể hiện trên

class chưa?

Trang 80

Tham khảo

Tham khảo: GeekCorps 2004

IBM - RUP

Introduction to Rational Rose 98i

Bài giảng: Công cụ và môi trường phát triển phần mềm – ĐHKHTN

Bài giảng: OOLT, Ms.Trang, Vietnam &

Japan Joint ICT HRD Program.

Trang 81

Thực hành

Định dạng
Số trang	83
Dung lượng	4,21 MB